Mike-O-Matic

Something about programming leads us developers to come up with all-consuming ideologies about our craft.  Maybe its our built-in pattern detectors or well-tuned sense of structure and architecture.  Maybe it’s the hubris.  Who knows?

So as I was typing in my blog the other day, I tripped over the one true answer.  The development methodology to end them all.  Really.  Rather than just blurt it out, though, I’m going to try to milk it for a few blog articles.

Now, I won’t say that it is all new.  There are aspects of it that are currently part of agile development, and others that are part of programming by contract.  But those both are much more specific and operate on a lower level.  Maybe this new methodology is more of a meta-methodology.  Wouldn’t that be something?

Let’s get into it then.

Some Observations

I’ve been programming for a little while now and I’ve picked up on a couple things.

One, development tends not to scale too well as you add more people.  Fred Brooks had something to say about this when working at IBM, more specifically about how adding more programmers to a late project tended to make it later.  Having been involved from the beginning on several projects, I feel that his observation can be extended to pretty much any part of the development lifecycle.  There is always more friction with more team members.  Sometimes you disagree on technical issues, sometimes you have personality conflicts, sometimes you are dragging along dead weight.  There are always more meetings, and more overhead in general in integrating various viewpoints into a single codebase.

Two, programming is a “flow” activity that requires one to maintain a model of a complicated system in their head.  Joel mentioned the flow part and Paul talked about the mental part.  Each of these hints at another reason why development doesn’t scale across multiple brains so easily: Interactions with other people take you out of the flow state, and multiple developers mean that you need to figure out how other people do things and remember to switch to their mental model when working on different segments of the application.

Three, standardization is better than documentation.  I’ve been at many places that cling to documentation like a warm fuzzy blanket in February.  It absolutely has its place, I can’t deny that.  The bigger issue, though, is that unless you have standard components in code that you reuse throughout and don’t make everything a one-off, no amount of documentation will save you.  Developers need to understand what is going on simply though looking at the code itself, and nobody maintains documentation anyway.

Four, abstractions don’t mean s***.  I apologize to the sensitive people out there but it needs to be said.  Put another way, some developers tend to go into architecture mode and refuse to commit to a specific technical solution.  I remember a particularly humorous scenario where I was at a company who had purchased many $25,000 Oracle licenses and then tripped over themselves to make sure all their code used a database abstraction layer and dumbed-down SQL that didn’t use any of Oracle’s impressive features, like CONNECT BY.  Why?  So you can move to MySQL tomorrow?  “Sorry about the $200k, boss.  My bad.  Wah wuh.”  There is nothing wrong with committing to a particular platform, assuming it isn’t currently dead, dying, or a technical dead end.  Just be smart about it.  Besides, you’re eventually going to have to do it anyway.

Five, cross-platform is important.  Pretty much every development shop of any size has or will have multiple programming languages in use, at the same time, for developing software.  It’s inevitable and it’s real.  Application language frameworks are cool and handy, but they generally only work with one application language at a time and are therefore, by definition, only part of a solution.

Guiding Principles

Given these five things, the new methodology is organized along the following principles:

1. Minimize Developer Interactions
2. Encourage Developers to Do It Their Way
3. Value Standard Components Over Standard Documentation
   
4. Don’t Be Afraid of (Sensible) Commitments
5. Work Across Programming Languages/Environments

Now, there is that old “speed/quality/cost: choose two” thing that happens a lot with development teams.  While many methodologies (inaccurately) claim they can deliver all three, this methodology is honest.  It values speed and cost most, and tries to make quality predictable while not actively hurting it.  If you have a good team of coders who “do the right thing,” avoid hacks, and refactor when they need to, everything will be great.  Otherwise, well, you’re going to have low quality code anyway; the methodology just won’t stand in your way.

In the next installment I’ll dig into the details a little bit more.

Til next time.

Subscribe to this Blog!