- Introduction
- Dealing with Haste
- Dealing with Ignorance
- Quality by Design
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Dealing with Ignorance
Ignorance comes in two flavors: experienced ignorance and inexperienced ignorance. The way you can tell the two apart is that experienced ignorance readily admits to not knowing enough about a project, and keeps asking questions. Inexperienced ignorance says things like "This will be easy" and "I know how to do this." It has nothing to do with age or the number of years a person has been developing software; instead, it's all about how open and receptive a developer is to learning.
Experienced ignorance is easy to live with because the team realizes that during the course of any project, everyone is going to have to learn a lot about the tools, the problem domain, and the design that they're creating. As such, they're always open and receptive to learning.
Inexperienced ignorance, on the other hand, is not open to learning. The team is convinced that it knows the right way to develop the software, and you need a massive amount of reality to disturb the picture seen through their rose-tinted glasses. This is not to say that the team won't learn—just that the team is very resistant to the idea that it needs to learn anything.
All Teams Need Rapid Feedback
Short cycle, incremental development is a very good way to deal with both types of ignorance, since it gives a great reality check at the end of each increment. Every few weeks, the team gets some great binary feedback about their progress and the quality of the software they delivered.
Developers coming from experienced ignorance sometimes argue that the increments need to be longer because they need more time to get the design right. Although this argument sounds right in theory, it's precisely the wrong thing to do when the team needs to learn. Only by delivering the code and seeing the consequences can the team learn the true implications of their design choices.
To avoid rotten code, the team needs to take the time to implement each design idea as an integral part of the existing application. By integrating each new design idea as a seamless part of the whole, the team sets the foundation for software that can be maintained and extended for years to come. Integrating the new ideas into existing code often means that some of the old code has to be rewritten—or refactored, if that's more politically correct. Teams that omit this refactoring end up with rotten code, since each new idea is just tacked onto the existing code.
Developers who are afflicted with inexperienced ignorance usually accept a short increment length until near to the end of the first increment, when they realize that they won't be able to deliver as much as they originally thought. At this point you're likely to hear lots of excuses that attempt to divert attention away from the team and toward external influences. Learning occurs when the team starts to acknowledge that their behavior, rather than external influences, is the main factor that determines delivery.
Inexperienced ignorance has a very hard time with short-cycle incremental development, because it's very sobering to realize how little code can be delivered in just a few weeks. Yes, it's possible to deliver a lot of business value, but that doesn't depend on the amount of software that's delivered. Business value depends on whether the software that's delivered meets the real needs of the users and is delivered early enough for the users to benefit from it.