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
- March 31, 2010
- Rants
Back 25 years ago the way we started to write a new version of a successful product was that we deleted the previous version and started with a clean slate. Virtually all the code we wrote was thrown away and many new versions were started from scratch.
But we can’t do that today. The systems that we build today are much larger and far more comprehensive than anything that we did back then. It doesn’t make sense to start from scratch when we write a new version of an existing product and so we have to think about the software that we write differently.
Building architecture has come to realize the same thing. In the old days a house or store was built specifically and only for that one purpose but today we see suburban areas become urban areas. Houses become shops which become common spaces and so the way buildings are built today have to be more flexible and accommodating so that when neighborhoods change the buildings can be more easily repurposed. This implies a retraining of building architects and the practices that they use in order to construct these newer buildings.
The same thing is true in software development. If we want to start building software that is able to be repurposed then we have to rethink how we build software in the first place and we have to identify what makes software easy to change what makes software difficult change.
It turns out that the practices for making software easy to change our very straightforward and not hard to learn. I cover just a handful of these practices in my classes and although not exhaustive by any means they’re a great start and makes a huge difference when put into practice on a development team.
Previous Post: « The Limiting Factor
Next Post: Resistance to Change »