Thursday, August 16, 2012

Clean code, greenfield development, and the Developer Ache

Much has been written lately about "writing clean code".  Whether it's the "Uncle" Bob Martin books, or other similar books, there has been a lot said about writing code which is a joy to work in.

The alternative word to "clean", is "legacy", which means "a pile of crap that I hate working on".

I'd like to suggest that in fact, 99.99% of all the code that runs everything, including Windows, your bank machine, and the rest of your bank, the entire world banking system, the fuel injection computer in your car, the firmware for every system in every airplane currently in the air, and just about every piece of PC Windows, Linux, Mac, and  embedded system software in the world is "Legacy" software.

I'd like to suggest that clean code is an asymptotic desire of an insane mind. That programmers can become obsessed with code cleanliness to the point that they can place some aspects of clean code above the other more important aspects of clean code.  Of course the "clean code" people advise correctness, completeness, usefulness to the customer and the world, but I haven't seen them advance any ideas on how these ideals can be pursued in a manner that is sustainable, and which can balance pragmatism against idealism, such that the survival of the businesses and knowledge-based economies that live thanks to these systems is assured.

Sometimes we create amounts of technical debt which require not only technical solutions, they require mental conditioning to withstand working in the code. Sometimes a kind of zen quietness is needed more than a kind of ninja coding style.

Imagine, if you will, deep in the bowels of the Microsoft campus, lives a senior software developer who is responsible for the Windows Explorer Shell APIs and codebase.  Imagine it's 5 million lines of insane code.  He can't change any of it without breaking a million plugins or extensions, and he's still getting heat from managers who can't code, for the 57 serious bugs that shipped in Explorer.exe in the Vista RTM.  He dreams of a clean codebase, but he knows it can never happen.

There are just too many constraints on real useful software, to ever allow complete rewrites.

Now let's switch to Delphi programming.   What if 99% of the Delphi code out there is a Big Ball of Mud.   No encapsulation.  No abstraction.  No cohesion.  Plenty of bad stuff; Coupling ties everything to everything.   You can't bring one unit in from a project without pulling in 4.5 million lines of code via the snarled mess of uses-clauses that tie the whole unit to everything else in it.  Nothing is unit testable.  You can't rewrite it without killing your company and your main product.   Everyone wants an incremental addition here and there, but nobody has the patience to wait while you clean it up.

What do you do?   I would argue that everything that the clean-coding crew says you need is still true. But you need to turn down the volume dial on your own internal anxieties.  You need to give yourself the time, the imagination, and the freedom (internally) to imagine that these problems really can be solved, but that the solutions won't come in a complete form, but rather, incrementally, slowly, and that after a sustained effort, you might get cleaner code.  Never ever will you have clean code.

But maybe just maybe, you can make things better.  Just not perfect.   And that's the difference between insane, and sane.    Maybe some coders have undiagnosed Obsessive Compulsive Disorders.  So become more self aware, and become a better coder.


3 comments:

  1. I disagree with you on a few points.

    1. Wanting a clean code base is no more insane than wanting a clean house. The more cluttered your code is the slower you'll work so its natural to want to clean up messy code.

    2. In your example of the MS employee you make the assumption that the code cannot be changed without breaking functionality. Highly unlikely. If that were the case there would be no purpose in even attempting to fix those 57 bugs. In which case he's better off cleaning up the code than he would be just fixing the bugs and moving on. I mean if he's going to break code anyway may as well make it more maintainable and less brittle going forward.

    3. I've read Clean Code and it never suggests whole sale rewriting of large subsystems. On the contrary Martin prescribes exactly what you suggest. Steady, incremental improvement or an extended period of time.

    You are correct on one point though. Only the insane or the incredibly naive would consider a complete rewrite. I've been involved in a project that took this road before and I'm certain everyone was afflicted by both. That's akin to blowing up your house and rebuilding when you really just need put away your laundry and sweep the floor.

    Refactoring an existing function into a form that's easier to work with is no more difficult than fixing a bug or adding a new feature. If you limit your refactoring activity to only the code you are working on anyway the effort pays off immediately.

    I'd like to point out that good automated test coverage would help tremendously with ensuring structural changes haven't resulted in behavioral changes.

    ReplyDelete
  2. I'm not saying desiring something is insane. Thinking you can ever "arrive" and have 100% "clean code" is insane, or rather, depressing.

    W

    ReplyDelete
  3. I'm not saying desiring something is insane. Thinking you can ever "arrive" and have 100% "clean code" is insane, or rather, depressing.

    W

    ReplyDelete