-Jonathan

We must also admit that there is no silver bullet. As much as people write about processes that will “solve all problems” there is no way to do that, just as there is no one pair of pants that will fit every human on the planet. What we have instead is the ability to recognize when what we are doing, and what we have done in attempting to solve the real problem has failed. Regroup. Rethink. Rewrite.

Again, this can also be applied to how the software is developed. :)

Solve the whole problem.

This is the corollary to solve the real problem. If you are building a function, a class, a library, an application, or a system, by solving the real problem, you make sure you clearly delineate the areas of responsibility of yourself and others using a well-defined interfaces. By solving the whole problem, you ensure that the well-defined interface best represents the most appropriate division of responsibility. This idea can be represented by the notion that a system component should make the work it does significantly easier for clients if they use the component versus doing it themselves.

The implementation is more flexible than the interface.

If you have well-defined interfaces dividing areas of responsibility, then you “write to the interface”. Doing this properly and taking advantage of the abstraction requires designing the interface to match the division of responsibility (i.e. solving the whole problem) and then writing the code to implement as much of that interface as is necessary (maybe all of it). The wrong thing to do is to write an interface that matches (read “exposes”) your current implementation out of convenience and then be jailed to that implementation forever.

Never let perfect stand in the way of very good.

It may be tempting to wait until you have the time, the knowledge, or the inclination to design the “perfect” solution, especially if you aim to solve the real problem. However, you must temper this instinct with practicality. While it may look like you are holding out for “the perfect solution” (that solves the whole, real problem), what you are really doing is preventing “the very good solution” that can be applied in the interim. We must recognize that perfection can only be approached asymptotically through evolution of design and implementation: in essence by refining our deployed very good solutions to make them more perfect. Solving the real problem should be applied where scope allows and it should guide our path to tell us where perfect is, but we are allowed to get there in more than one step. Very good solutions have value, and value delayed is value lost.

This last principle developed out of seed ideas from David Trueman here at IIA and serves as an important balance to the other three. It represents the “real world pressures” and reminds us that the real goal is to produce something, after all.

This of course applies to both the software itself and the process used to build the software.

Solve The Real Problem. If you don’t, you will have to live with the consequences. The longer you wait, the harder it will be to un-fix all patches.