Error-driven software development
When developing software systems, there are a number of systems development types out there, e.g. test-driven development (focuses on making tests before implementing), and what might be called requirements-driven development (focus on finding all the requirements before implementing). Unfortunately, there is a type of development that I all too frequently come across, which I've come to call error-driven development.
Error-driven development is systems development, where everything is done in reaction to errors. In other words, the development is reactive, rather than proactive, and everybody is working hard, just to keep the project afloat, without any real progress being made.
I should probably clarify, that I am not speaking about the bug fixing phases, which occurs in every project, but rather the cases where the project seems to be nothing but bug-fixing (or change-requests, which is to my eyes is a different sort of bug reports), without any real progress being made.
Unsurprisingly, this is not very satisfactory for any of the people involved. What's more, it's often caused by deep, underlying problems, where the errors are just symptoms. Until these underlying problems are found, the project will never get on the right track, and will end up becoming a death march.
The type of underlying problems, which can cause error-driven development, could be things like:
There are of course many other candidates, and several of them can be in play at the same time, causing problems.
No matter what the underlying problems are, the fact is, that just focusing on fixing bugs and implementing change requests, won't help. Instead it's important to take a long hard look at the project, and see if the underlying problems can be found and addressed.
This seems trivial, but when you're in the middle of an error-driven development project, it's hard to step out and take an objective look at it. What's more, you might not be able to look objectively at the process. Often, it requires someone who hasn't been involved from the start, to come and look at things with fresh eyes.
As a consultant who often works on a time-material basis, I often get hired to work on error-driven development projects. The reason for this is simple: often it appears to the people involved, that the project just need a little more resources, so they can get over the hurdle of errors, and then it will be on the right track. When hired for such projects, I always try to see if there are some underlying problems which needs to be addressed, instead of just going ahead and fixing errors/implementing changes. Unsurprisingly there often are such problems.
Frequently these problems can be fixed fairly simply (reversing some old design decisions, expanding peoples' domain knowledge, get people to communicate better, implement a test strategy, use agile methods etc.), while at other times, they can't be fixed, only taken into consideration, allowing you to avoid the worst pitfalls.
So, my suggestion is, if you find yourself in a project which over time has turned into an error-driven development type project, try to take a long hard look at what has caused this, instead of just going ahead and try to fix all the errors/implement the changes. Error reports and change requests are just noisy symptoms in most cases, and will continue to appear as long as the real problems aren't addressed in one way or another.
Error-driven development is systems development, where everything is done in reaction to errors. In other words, the development is reactive, rather than proactive, and everybody is working hard, just to keep the project afloat, without any real progress being made.
I should probably clarify, that I am not speaking about the bug fixing phases, which occurs in every project, but rather the cases where the project seems to be nothing but bug-fixing (or change-requests, which is to my eyes is a different sort of bug reports), without any real progress being made.
Unsurprisingly, this is not very satisfactory for any of the people involved. What's more, it's often caused by deep, underlying problems, where the errors are just symptoms. Until these underlying problems are found, the project will never get on the right track, and will end up becoming a death march.
The type of underlying problems, which can cause error-driven development, could be things like:
- Different understanding of the requirements for the software among the people involved. Some times the people who make the requirements have an entirely different understanding of what the end system should be like than the end users.
- Internal politics. Some departments or employees might have different agendas, which might lead to less than optimal working conditions.
- Lack of domain knowledge among the people involved. If you're building e.g. a financial system, it helps if at least some of the people involved in the development have a basic idea of the domain you're working within.
- Bad design. Some times early design decisions will haunt you for the rest of the project.
- Unrealistic time constraints. If people don't have time to finish their things properly, they will need to spend more time on error fixing later.
There are of course many other candidates, and several of them can be in play at the same time, causing problems.
No matter what the underlying problems are, the fact is, that just focusing on fixing bugs and implementing change requests, won't help. Instead it's important to take a long hard look at the project, and see if the underlying problems can be found and addressed.
This seems trivial, but when you're in the middle of an error-driven development project, it's hard to step out and take an objective look at it. What's more, you might not be able to look objectively at the process. Often, it requires someone who hasn't been involved from the start, to come and look at things with fresh eyes.
As a consultant who often works on a time-material basis, I often get hired to work on error-driven development projects. The reason for this is simple: often it appears to the people involved, that the project just need a little more resources, so they can get over the hurdle of errors, and then it will be on the right track. When hired for such projects, I always try to see if there are some underlying problems which needs to be addressed, instead of just going ahead and fixing errors/implementing changes. Unsurprisingly there often are such problems.
Frequently these problems can be fixed fairly simply (reversing some old design decisions, expanding peoples' domain knowledge, get people to communicate better, implement a test strategy, use agile methods etc.), while at other times, they can't be fixed, only taken into consideration, allowing you to avoid the worst pitfalls.
So, my suggestion is, if you find yourself in a project which over time has turned into an error-driven development type project, try to take a long hard look at what has caused this, instead of just going ahead and try to fix all the errors/implement the changes. Error reports and change requests are just noisy symptoms in most cases, and will continue to appear as long as the real problems aren't addressed in one way or another.
Labels: IT consulting, programming, systems development
posted by Kristjan Wager at 8:04 AM
View blog reactions
3 Comments:
Nice write up man. I was wondering if anyone else coined the methodology "Error-Driven Development" and found you blog while doing a Google search.
Love the closing paragraph - and find that when you continually enhance a legacy product, instead of building new, as technology approaches change, and domain understanding evolves, you find your only development option is error-driven. Great article.
I agree with you, BUT:
To me its seems you cover only the downsides of error-driven software development here.
It is also done quite a lot of times when you lack certain code or have to implement required methods.
That often occurs when you create parts of a software from scratch, either to have one or more alternatives to the old implementation, or to implement a more efficient/compatible/up-to-date/state-of-the-art version from scratch.
While some of your problems still apply, especially the bad design, there is to say that as a software designer/developer you always have to weight "good design", "extendable design" and "can-do-in-time" versus each other.
I have done this method of developing on package/class level multiple times, meaning I had to "re"-construct complete packages. But I must say it gives you a way better starting point.
For example, going with Java+Eclipse, this is really easy, for Eclipse can create all the missing classes and their methods for you (as should any good IDE be able to).
It goes so far that, while developing any code, I intentionally set the wrong type for a variable ("int queue" instead of "LinkedBlockingDeque"), because I know that in the same line Java/Eclipse detects those errors and I can change the type by hitting just one key. This saves a lot of time. Thus being another type or an extension to auto completion.
(Well okay it's dependent on the language and its typing system, but nontheless quite present in the common IDEs)
So while error-driven development can be a pain in the ass, you can also use its advantages.
Post a Comment
<< Home