2025 Public Training Schedule
June 23 26, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions Online
July 22 – 25, 2025 – Agile Analysis and Design Patterns – Half-Day Sessions Online
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) 2025 To Be Agile
- March 21, 2018
- Say What, Why, and for Whom Before How
Our users are only human and its human nature not to always know exactly what we want. I realize that sometimes we have to build software on specifications and all the requirements are needed to be identified upfront. But statistically, it is rarely the case that all requirements are needed. It turns out that nearly half of all the features built are never actually used. We do this because we don’t have a really good sense of exactly what we want before it’s actually built, again because of human nature.
Once we build it we often learn a tremendous amount and when we get feedback from our users as to what’s working and what could be improved then we end up building something better than we originally conceived. To me, this is what Agile is all about.
One of the main tenets of Agile software development is having the opportunity for feedback because only through feedback can we really emerge a solution that fits well with the user’s needs. Feedback gives us an opportunity to learn and that’s critically important when building software.
The process of writing software is not some rote translation of a specification into code. The process of writing software is the codification of understanding. We understand the process and then embody that understanding in code. By doing this we make the code understandable to others. This is key because it doesn’t matter how well a design is if only the programmer who wrote it understands it and can extend it.
The software profession is in dire need of commonly agreed standards and practices. Those of us who are vocal in the Agile community are taking a stand for software quality because we know that in order to build a sustainable, reliable industry and one, by the way, that all other industries depend on, we have to have a common set of standards and practices that we can base our profession upon.
I’m a big advocate for code quality and Extreme Programming practices because I often end up with higher-quality software then if I were to follow a Waterfall software development process. And I tried to make Waterfall work for over a decade. It worked well on small projects, but it didn’t scale.
But it doesn’t matter how beautiful your code is or how maintainable it is if it doesn’t do the right thing in the first place. It’s far more important to “do the right thing” then it is to “do the thing right.” Fortunately, we don’t have to trade one for the other and we can decide to do both.
Feedback from our users helps us give them more of what they want. It also helps inspire us because we see how our work is used and how it helps other people. This is one of the most satisfying things about being a software developer. Seeing how people use the software that we create reminds us of the impact of our work and how it helps people.
Previous Post: « Aggregation or Composition
Next Post: Playing Dumb isn’t Agile »