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
- January 6, 2016
- Rants
People define success differently. This is not only true individually but we define the success of products or projects based on different criteria, too.
To the Standish Group, success is about predictability. They define the success of a software project as one that is delivered on time, on budget, and with all the features and function as originally specified. But this is not a meaningful definition of success. All it really measures is the project manager’s ability to guess how much a project will cost. For Standish it’s all about predictability but it excludes the possibility of coming up with a better idea along the way. Old definitions of success bind us to a particular implementation of success. If it doesn’t need that original vision in its entirety then it isn’t considered a success. But in Agile, our goal is to learn along the way so that we can come up with a better plan, a better execution than we had originally envisioned.
On the other hand, success cannot be solely defined by the success of a product in the marketplace. Of course, this is a huge part of what might be considered successful, but just having a financially successful product is by no means the only factor of true success. Consider Clipper, made by Nantucket Software, a database program that ran on desktop computers back in the day. It was wildly popular. The product made a fortune, but it was so full of technical debt and so difficult to work with, the developers couldn’t get out new releases fast enough and ultimately the company went under.
Code quality matters. And code quality is not the only thing that matters. If we don’t build the right things we’re done for. No matter how beautiful our code looks, if we don’t ultimately do what the user needs, we’ve wasted our rime. We must do the right thing!
But doing the right thing is not enough. We must also do the thing right and building the thing right means conforming to solid engineering principles and practices that support creating testable, maintainable software.
How do we know if we’re building the right things? Well, that’s easy. We can verify it with the customer. We can see how our software is used and measure the time the user had to wait until they received value from us. We can also measure if we built the thing right by looking at code metrics such as defect density and code quality, as well as technical debt.
Building the right thing and building the thing right are critical for success, but there are not equally viable in every context. In practice we often have to make compromises. How do you define successful software? Is your definition of success measurable?
Previous Post: « Just Telling Teams to Self-Organize Doesn’t Work
Next Post: Why I Wrote Beyond Legacy Code »