2024 Public Training Schedule
December 9 – 12, 2024 – Agile Analysis and Design Patterns – Half-Day Sessions
2025 Public Training Schedule
January 14 – 17, 2025 – 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
- May 8, 2009
- Rants
Last month I wrote an “Agile Tip of the Month” for the Agile University Newsletter sent out on 4/2/09. For those who don’t read the newsletter I thought I’d post it here:
People have said that architecture and design is unnecessary in an agile software development process. This is simply untrue.
Short iterations and ongoing customer involvement in agility means software needs to change frequently. This makes architecture and design even more important. Without paying attention to how software is constructed, the agile process of iterative development can soon degrade code into a maintenance nightmare.
In order for agile projects to thrive they must embrace constant change by building software that is resilient to change. But what makes software easy to change?
First and foremost, software must be understandable. This means that teams model the software as closely as possible to the problem it is addressing. Writing software is based on understanding the world through language so it is vital to pick the right metaphors and concepts to express systems, not for the computer’s sake but because we realize that humans must maintain the software. All symbols in code should use intention revealing names so that it is clear what they are about without having to rely on excessive comments in the code.
Teams should adopt standards for consistency. I don’t care if you put the curly bracket on the same line as the “if” statement or on the next line. What I care about is if we are working on the same team, we all do it the same way.
In my developer classes, I often ask students if they prefer writing new code or maintaining existing code. Most developers prefer writing new code, not just because green field development is more exciting but we know from experience that changing existing code can introduce unexpected bugs.
This is the essence of the Open-Closed Principle that Bertram Meyers defines as “Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.” In other words, let’s write software so that when requirements change we are maximally adding new code and minimally changing existing code.
This turns out to be easy to do if we pay attention to code quality while employing a few key principles and simple practices. Once we understand some of the impediments to writing changeable code and get into the habit of following a handful of techniques that work for us then we can rapidly crank out quality code that can easily be extended in the future.
Want to learn more about creating quality software that can easily change in an agile environment? Join me in my upcoming class Agile Architecture and Development: Essential Patterns and Practices on June 30 and July 1 at the SeaTac Area Courtyard by Marriott.
Previous Post: « Is Your Legacy Code Rotting?
Next Post: Webinar: Writing Quality Software – June 3rd, 2009 »