27 June 2009

Heroes and Monoliths

I'm sure it's no surprise to anyone, but huge, monolithic software is extremely hard to ship.

It used to be that when I encountered a particularly complex software problem, I would work at mastering the complexity until (by hook or by crook) I figured it out. Then I would proclaim myself victor. It was often the case that people were waiting for me to figure out the hard problem, and would congratulate me on a successful resolution.

However, those congratulations feel empty to me now. I think I can finally appreciate what Dijkstra meant in The Humble Programmer (and here), argument #6:
... the only problems we can really solve in a satisfactory manner are those that finally admit a nicely factored solution. ... By the time that we are sufficiently modest to try factored solutions only, because the other efforts escape our intellectual grip, we shall do our utmost best to avoid all those interfaces impairing our ability to factor the system in a helpful way. And I cannot but expect that this will repeatedly lead to the discovery that an initially untractable problem can be factored after all.
Now I remain unsatisfied until I've solved that problem at hand "in a satisfactory manner", i.e. in a manner that is tractable to read, understand, and change in the future. Not just for me, but for any other competent software developer that comes behind me.

I think this links to the IEEE Code of Ethics, items #5 and #6, in which computing professionals agree:
5. to improve the understanding of technology, its appropriate application, and potential consequences;

6. to maintain and improve our technical competence and to undertake technological tasks for others only if qualified by training or experience, or after full disclosure of pertinent limitations;
While I was writing this, someone came over and asked me a question about complex software I wrote part of, and I helped him. And I laughed at myself for being unsatisfied about helping him. :)

No comments:

Post a Comment