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
- December 15, 2010
- Rants
One of the biggest challenges I’ve had in my career as a developer was over-design. I used to just dive in and code on projects but soon afterwords I would end up stuck. To compensate I would spend a lot of time in the design phase only to discover later that most of my concerns never needed to be addressed and so my effort were wasted.
How much design is too much design? I’ve often asked this question and came to various conclusions in my 30 year career as a developer.
Today, most of the people I work with know me as a patterns guy. Design patterns are one of the most powerful tools I’ve come across and I use them a lot. I’m a big believer in patterns so this may come as a surprise but the more development I do the less (up front) design I do.
I still do design but I just do it as I go so that my designs can emerge. I know it must be a bit unnerving for people to talk about emergent design if you’ve never experienced it. Software development is expensive and error prone so I wouldn’t like the idea of putting off important decisions until later if I also had to pay a big price later. But knowing how and what to defer so that I don’t have to do a lot of reworking later can be a valuable practice.
It turns out that most design details do not need to be worked out up front and if we try to work them out up front we often end up locking ourselves in to a particular implementation that may make it difficult to change later. These tend to be poor decisions because they are often made in isolation from the rest of the system, plus we may not know enough yet to make the right choice.
Using risk mitigation techniques and some basic practices of encapsulation we can hide important decisions so we can resolve them later without a lot of rework. I teach several of these techniques in my training because they are some of the most important skills for an agile developer. They allow you to eliminate external dependencies and let you hide your thorniest issues behind a well define interface so they they can be changed later without impacting other parts of the system.
Previous Post: « Aggregation verses Composition
Next Post: The TDD Zealot »