M^3

For a long time now I've been following a software development methodology with no name. A few months ago a colleague and I were discussing such things and he challenged me to formalize my thoughts. I present it to you, today for comment and consideration.

The Three M's (or M-cubed or M^3 or, if you like, The M-Factor) are (or is) quite simple:

• Make it Work
• Make it Better
• Make it Right

There is nothing intricate, mysterious or complex here. It is just as you read it. In fact, most of you reading are probably responding with "well, duh" or something similar. And so you should. Any develompent methodology should be simple and non-intrusive and I believe that M^3 captures that sentiment.

Make it Work

Many teams fall into an analysis paralysis. You've heard the term. We've all been guilty of it at some point. The spirit of Make it Work is to put all of that aside and just get something done. Do whatever it takes to have something you can touch and see. At this point I don't care if you have scriptlets in your JSPs or hard-coded magic values in your Java classes. Just get something (anything) done so that what you have in your head can be shared with others. In some cases you may find that what the feature you're working on isn't needed at all or may be needed in a different way than you imagined. Best to find that out early, after a quick hack than later after a lengthy, yet perfect, implementation.

The challenge, of course, is to not stop at Make it Work. Too many times we see junior (and not so junior) developers quite satisfied with solutions at this phase. Resist the urge to move on to the next thing before ensuring that the current thing is done correctly.

Make it Better

This is where you'll spend most of your time in the process. Revise your Make it Work results to get rid of the truly embarrasing things first (e.g. -- scriptlets, hard-coded values and whatever else). If you're not following Test Driven Design then now is the time to start writting those unit tests. (If you are doing TDD then you already have at least a scaffold of tests as a result of Make it Work and I applaud you.) Next look for opportunities for pluggable strategies. Then consider repackaging for reuse. Apply design patterns. Etc... In other words, iterate through Make it Better as many times as necessary to reach a point of "good enough". The challenge, of course, is knowing when enough is enough.

Many people will get hung up in Make it Better. How many times have we seen the tinkerer refactor the same bit of code so many times that the end result looks nearly exactly like the original? Coding in circles isn't very productive... Refactoring is a good thing. A very good thing. Just don't get caught up in the excitement of it all and loose track of the fact that you have to deliver something eventually.

Make it Better is also the place where you will respond to changes in your requirements. Not wholesale changes along the lines of "you're building a house but we want a boat" but those "oh, it works *that* way..." kinds of changes. In Make it Better your code is fluid and can easily respond to small to middlin' changes that are, themselves, responses to the evolution of the solution.

Make it Right

Once you have finally satisfied yourself that the result is good enough (or when someone tells you to quit refactoring for refactoring's sake) you have reached Make it Right. This is the exact opposite of our initial Make it Work. Now we want to do one last pass over the many iterations of our second phase to make sure that we have taken every reasonable (though not every possible) opportunity to make our solution "right". Is it as extensible as it should be? Is it pluggable where appropriate? Etc...

It is important to realize that Make it Right is not the same as Make it Perfect. There is no such thing as perfect software. Your Make it Better iterations will eventually reach a point where further refinement adds no benefit. At that point you're ready to enter Make it Right where you can "dot the I's and cross the T's".


Does M^3 fit with other methodologies? Of course it does. At its heart M^3 is about agility. It is about getting something done as quickly as possible, improving and adapting and putting a nice shine on the final solution.

So, there you have it; the methodology I've been following without realizing it for probably twenty years or so. In a lot of ways M^3 mirrors our natural learning process. Since much of development is the process of learning what the customer really wants it only makes sense that our development process follow a similar approach.

(Thanks goes to Scott, my friend and co-worker, who challenged me to actually think this through and formalize my thoughts.)