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
- December 8, 2021
- Say What, Why, and for Whom Before How
Continuing my series of posts based on Seven Strategies for Writing Better Stories from my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software, here is the next strategy.
Another great aspect of using stories to drive Agile software development is that we can start with simple stories that create a minimal viable feature and then enhance that feature in subsequent stories. This allows us to build the most valuable parts of a feature and find out from the user if more is needed.
When I built a feature, I usually start with the happy path. In other words, I don’t think about what could go wrong, I just think about what could go right. This approach gives me a good sense of what I want to build without worrying about all the things that could cause what I want to do to fail and of the error conditions that could occur. I’ll get to them but first I’ll focus on the happy path.
This is a more efficient and effective way of building software than taking the opposite, more paranoid approach of constantly thinking about what could go wrong. We want to take that perspective as well but it’s better to take the critical perspective in a second pass as an afterthought rather than to start out with that perspective.
This is often reflected in the way I build a feature by starting with the happy path and then peeling off exceptions. Sometimes I take the opposite approach by first writing tests for the exceptions and driving to the happy path.
Note that all of my features and my stories and my acceptance tests are all based upon behaviors that I want to create in the system. Agile software development strongly encourages the notion of creating behaviors because behaviors are testable and they’re also understandable, we can reason about them and talk about them.
Very often when we start with a simple design, that’s all we really need, and we can move on to other things. When we do need more of a design, it’s often because we come across a second situation that’s similar to something that we did before and when we encounter that situation, we can address it and generalize it then.
This is the notion behind doing emergent design or evolutionary design. I was skeptical when I first heard about this idea because it’s difficult to visualize a design emerging on its own, just like it’s difficult to visualize the process of biological evolution. You can’t see biological evolution in action, it takes place over hundreds of millions of years.
Evolutionary design in software happens much more quickly but, in many ways, just as unexpectedly. I end up with designs that I don’t think I’d ever come up with on my own and far better than I would’ve ever come up with on my own.
I don’t know how it happens but using the simple process of test-first development and refactoring to patterns, I’ve discovered elegant solutions effortlessly and I know other developers who have done the same things with the techniques that I’ve been using.
Agile stories and emergent design go hand-in-hand. It’s a powerful and productive way of building software that I highly recommend experiencing for yourself.
Previous Post: « Know Why a Feature is Wanted
Next Post: Think About Edge Cases »