2024 Public Training Schedule
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, 2011
- Rants
I remember a poster at my college that said “All great minds don’t think alike but they do make connections.” I think this is especially true in software development where we are all largely self-taught.
When I ask my students what the most valuable thing they got from my training was, I get a lot of different answers such as the design techniques, the different yet highly valuable way of understanding patterns, the focus on quality, but one of the most valuable things developers tell me is the ability to form a common language for design so they can communication with their team mates in higher fidelity.
We desperately need ways to communicate better in software development. Language is vague and the software we write needs to be precise. It is often a challenge to express our design ideas to others and so they are not given the best opportunity.
I think we sometimes get caught in the fear that makes us worry about several things at once. When we have a conversation about multiple things at once it is easy to get lost. I see this sometimes, developers will jump from topic to topic, not really addressing any one of them so no real progress is made. By contrast, when we stay focused and work through each issue, one at a time, we can make a great deal more progress.
When we have disagreements on design approaches it is rarely about the current requirement and almost always about what could happen. But that is anyone’s guess. I try not to engage in what could happen because it is often just speculation. Instead, I draw on good development practices to help mitigate the risk of changing my design later and just focus on implementing the task at hand.
Of course, if I know a feature will be needed soon and it is easy to accommodate it now, I will go ahead and do it, or at least write my code in such a way so it is easy to add later. Remember, Kent Beck says, “Do the simplest thing possible, not the stupidest.”
When I do get into an argument with another developer I apply what I call the ten minute rule. If I can’t convince them of my approach in ten minutes I usually give in to their way. This is because I know it is usually easy to change a design from their way to my way if it becomes apparent that it is better to do so.
Changing a design to accommodate a new feature doesn’t always have to be a huge undertaking, especially if we have unit tests that cover our code, and we build software using Agile practices. I find building software in this way is far more successful and less stressful than trying to anticipate what the customer might want in the future. When we get good at refactoring and see that going from one design to another in many situations can be easy to do, a lot of the fear of having to get it right the first time goes away and development becomes much more fun!
Previous Post: « Become a Better Problem-Solver
Next Post: Techniques of Design Has Become To Be Agile »