Though seriously nobody should really apologize for a witty remark. It has a long history. Nobody ever apologizes for burying you in molasses-like courtesy.

I think where snarkiness becomes obnoxious is when its repeated over and over again, especially when its not even that creative. Cue the sweatervests!

That was over ten years ago, and I’ve found 2 particular writers that I still feel deeply connected to (and in one case I was actually connected to, in a six degrees of separation kind of way).

The first one, and the one I have a slight connection to, is Michael Porter. If you’re talking about formulating strategy, I’ve always found his “five forces” model and the 3 generic strategies to be deeply resonant. I probably picked up my interest in him as part of my 2nd year MBA course in Strategy, but read all his books in the years thereafter. My connection to him is that he was actually on the board of the company I worked for in Barcelona. Unfortunately while I would have loved to meet him, I was just a coder, and thus not included in the schmoozing that happened when he came to visit.

The second big influence, and the one I’m really interested in pushing forward here, is Eliyahu M. Goldratt. I did a teaching apprenticeship as part of my doctoral studies, and in particular I taught a single section of “Production and Operations Management” under the supervision of Ron McLachlin. There was a bunch of material in that course, but I could tell that Professor McLachlin had a real love for Goldratt and the Theory of Constraints that is the centerpiece of his work. Essentially TOC says that CPM and PERT, so beloved by project managers worldwide, are not very good for project management because of the problems of “statistical fluctuations” and “dependent events.” Basically small variations in performance multiply together, resulting in large variability in schedules, and end up making schedules useless. Instead he proposes (in The Goal) a simple 5 step approach to scheduling and project management. Those steps are:

1. Identify the biggest constraint
2. Decide how to exploit the constraint (by exploit he means blow it away)
3. Subordinate and synchronize everything else to the above decisions
4. Elevate the performance of the constraint
5. If, in any of the above steps the constraint has shifted, go back to Step 1

I believe that the same approach can be used for software development, and that it fits well with the idea of “good agile” as expressed by Steve Yegge.

My version of this, for the management of the software development process goes something like this.

1. Identify your biggest risk
2. Put your best people on it. Leave them on it until its no longer your biggest risk, and then a little bit longer than it takes to just solve the problem, so that its absolutely never going to be your biggest risk again, and in fact becomes an asset. (this is equivalent to steps 2, 3 and 4 above)
3. Go to 1

Some people might object to this on the grounds that it doesn’t address overall system design, breaking stuff into parts, assigning work, etc. But, in fact, at some point, that’s going to become your biggest risk, and at that point you deal with it.

Anyway, Porter and Goldratt, my heroes.