2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- November 18, 2015
- Rants
Clearly, the success rate of Agile projects is higher on average than Waterfall projects. I propose that we can trace some of this success back to technical practices. In Waterfall development, there was no incentive to write good code. Developers got once chance to write a feature and once it works the feature was never revisited so developers don’t see a need to focus on code quality. They may never see the code again.
But in iterative development, developers often have to go back into code they wrote in the last iteration to enhance code they wrote previously. There’s nothing more embarrassing than criticizing poorly written code only to realize that I was the one who wrote it. Going back into code we wrote is a good incentive to make the code understandable and I believe this is one of the major factors leading to a higher success rate in Agile.
Software development is a technical activity and to do it well requires technical skills. Most developers are not taught about Agile in school, so they often struggle to do Agile correctly. And some who are new to Agile see it as an undisciplined approach. Nothing could be farther from the truth.
Agile presupposes disciplined, high-quality software development that focuses on maintainability. If we allow technical debt to accumulate then it will prevent us from moving fast. It’s not enough to get feedback, we have to do something about it.
If developers apply the same poor quality practices to Agile that they do to Waterfall then their project is at a severe disadvantage. Even if they can deliver something it’s generally of such low quality that it costs a fortune to maintain.
Instead, we must keep code quality high as we continue to enhance our software. That’s the only way to make significant gains in Agile development. Adopting practices that support building quality code, such as TDD and refactoring, are core practices of the most productive Agile teams.
Previous Post: « Go Deep Rather than Wide
Next Post: Don’t Test Private Methods »