On good design and defining success
This is for the most part a reaction to conversations on design:
Believe it or not, I largely agree with all of these posts. The conversation originally started around TypeMock (and IoC before that).
Missing from all these discussions, and hidden in the intent of comments, is the real discussion: defining and creating success.
Defining success
The traditional definition for success in the software space is:
Completed on time, on budget, with all features and functions as originally specified
Variations of this definition exist, mostly around “on time and under budget”. But anyone in the software in any length of time has seen far different definitions of success. An on-time project never used is not very successful. A late project that users love is very successful. Defining success strictly in terms time-to-market and functionality delivered as promised still won’t lead to happy users. Sounds like our definition of success is a little off.
I personally like James Shore’s definition of success, with three facets:
- Personal success
- Technical success
- Organizational success
Total success is achieved by delivering value in these three areas. If we achieve organizational success but lose our minds in the process in an arcane system, we’ve missed complete success. Not all projects are capable of complete success, but Agile methodologies focus on striving for these three facets of success. Namely:
- Delivering what the customer wants and needs
- Creating software that’s both fun to write and fun to work with
- Creating an inclusive, collaborative, and exciting atmosphere where individuals feel free to question and contribute
That isn’t to say that these aspects don’t come without Agile methodologies, but that Agile is intended to deliver this type of success.
On an old team of mine, a team member got an email that some error count exceeded its limit. It was some throwaway application that they wrote years ago, but was still providing value. As no one maintained it, no one asked to change it, but it still did its job and created its little pocket of success (that not many would have predicted).
Organizational value is defined by the business, and includes increased revenue, decrease costs, and many other items that can’t be measured as directly as dollars and cents. Sometimes the value needed is a small application, but sometimes value and success requires something else.
So where does good design come into play into all of this?
Enabling success
Good design such as those espoused in the SOLID principles and reinforced through TDD, as well as the other XP practices, can enable success on certain projects. In other projects, as Jacob pointed out, these principles don’t matter as much. The problem is where to know when to make the transition to “good design” from “good enough” design.
In our projects, prototyping and “spiking” is common. This is where we throw out any design principles and try to prove a concept. Once we’re done from a time-boxed episode, we’ll take what we learn (throw it away Pragmatic Programmer-style), and incorporate the concepts into our project, using the principles and values we normally follow. What we do the second time around invariably improves on the original throwaway concept, but gave us a more complete knowledge.
As we design, we’re always mindful of creating success. I create success by trying to create a sustainable software ecosystem, where the rate of change stays high and level, ready to move in the face of changing business conditions and new information. However, I’m on projects where I don’t know the end state, ideal for Agile, and I optimize for change. Software ecosystems that aren’t optimized for change resist it at every turn. Such projects are easy the first release, but every release after delivers less and less.
This isn’t “ivory tower”, but a recognition of a simple fact: change is inevitable. Unless it isn’t. But as software professionals, we have to recognize when the application transitions from simple to complex, and change our tactics as necessary.
In the end, users don’t care about design directly. They want value, they want success. Good design can enable success, as it allows us to change software more quickly and easily than otherwise. For complex or changing systems, users care about design, they just might not know it.