00:49 November 30, 2011

clean house vs. dirty house

I'm a developer. Given that software development is in a state of burgeoning growth and has not solidified on a methodology (contrast 3rd world factory workers, where their operating methodologies have become science), organization are often inconsistent on how development is done. This is great as a means of self expression, as I as a developer may behave as a craftsman, even an artist, claiming my methodology may make a mark upon the work. But it is bad in the sense of inconsistency, in the same sense whereby artists, being less inclined to survive in primordial culture, are bullied and not favored unless they cater to the powers that be.

So there are essentially two opposing development methodologies:

  1. Pick up as you go, keep code clean, try to maximize sanity and minimize chaos towards eventual concurency
  2. Ignore any part of the code that does not directly affect your task at hand

Both sides have upsides and downsides. It is worth noting that with an ideal API, both sides are exactly the same. If you start with a clean code base, and you have positive changes, you end up with a clean code base. However, this is almost never reality.

The actual effect is that programmers that affect methodology 1. are penalized for their efforts whereas programmers that do not clean up after themselves (re: methodology 2.) are rewarded. How can this be?

Development processes are never light-weight. At least, I have never encountered any that are. Given that, type-1 programmers are weighed down by the effort of making shared code bases cleaner for everyone. OTOH, outcome is measure in short-term incremental goals. Abstract notions like down the road extensibility are ignored. So, by following methodology 2., you are guaranteed a good report card.

I feel like I say this over and over, but if you ignore the crap and hack your shit in and probably make worse crap because you have to work around the crap already there, you achieve "results" and are lauded for it. Mark that these are short term results, the terms defined by those setting the goals and not necessarily for the survival of the organism that is the software you are developing. Whereas if you try to make things better for everyone, you will be laden with the burden of proof, the burden of showing that your provide any value, questioning doubts, and if anything you do, even rightly so, breaks something because of other bad behaviour, you will be crucified for it.

So enters the rock star programmer and his kin. A software project is hard to maintain. Well, yes, legacy is expensive. Even clean legacy and no one has clean legacy. So the common reaction is to abandon legacy and start anew. Why? Two reasons:

A. By starting something new you are no longer bogged down by the decisions, good or bad in the context, of yesteryear B. And by starting something new, you can say that you worked on something new

Do not underestimate B.! The hidden factor that should be considered before you do this is that you throw away the entire knowledge base of a project when starting something new! Take Fennec on nightly. I can no longer give feedback in the app, because there are (evidently, putting on my user hat) no addons. If I can't report bugs, something is wrong. I realize that my primary position is not reporting Fennec bugs. But I used to, because it was easy. And now I can't. OTOH, I get to see that my browser is refreshing on my phone at 60fps. Native UI is speedy, but...

Another classic example is Firefox vs. Chrome. Google was Firefox's partner. Google made some noise when we made a deal with Microsoft and Bing but the fact is we had a browser that complied with their purported ethics and instead of helping develop it they forked it!. Now Chrome has a legacy, and all the smart kids at Google are beginning to see what a pain in the ass it is to have a legacy.

Being a nascent field, software development has many aspects that have long ago been dealt with in other fields, such as the debate whether it is better to keep a clean house or a dirty house. In more mature fields, only in dysfunctional -- and desparate -- situations do you see the logic applied of applying disproportionate effort to work around a problem vs. solving a problem. If you have a clean house, it is easy to keep it clean. If you have a dirty house, less so. But the dysfunctionality comes in several sayings in the software industry on why it is justified to keep a dirty house:

Note that none of these address the issue or tell how to make it better. They're just excuses. But somehow they're believed. They're not taken to be the kindergarten logic they are. If you're a for-profit company and show me a spreadsheet of (untainted) time estimates, I'll buy it. But mostly I feel the same about these as when I hear a review of a movie that's "the best movie of this or any year".

If you ran a house this way, you would never clean anything. You would have a house that got dirtier and dirtier until it was almost unlivable and then you would move. Really. We can do better than that.