Is Software Handmade?
My last post stirred up a lot of interesting feedback; some folks thought calling yourself a Software Artisan was pretentious (which is true, used in general conversation), some people thought it was a reasonable term, and some thought of other even more pretentious terms (My favorite: Software Auteur. It would be an amusing world where you could break the ice telling someone you were a Software Auteur.)
And some folks denied that software is handmade at all.
This is, to me, baffling. I’ve remodeled homes, moved bathrooms, built decks, made furniture, restored old hand-tools, assembled computers, jury-rigged a paint shed, and bought a ton of stuff at the hardware store destined not to be used for its nominal purpose.
I’ve know professional wood-workers who could make a chair so pretty you would cry to see it, and no two they made were exactly identical.
My experiences are not much different from many of you, I expect.
I am astonished anyone could think software creation was anything but handmade.
Look, you’ve heard the old saw that if you give ten good programmers the same task, they’ll write ten different solutions, all of which meet the task. I’d go further: If you gave me the same task ten times throughout the year, I’d be likely to build ten fairly different solutions.
If you gave me the same task ten times across a few years, the ten solutions would bear little-to-no resemblance to each other at all.
Why the differences? Greater experience, use of whatever tools which were at the top of the heap at the moment, my mood, whether I had chai this morning or Coke, and a hundred other factors.
Fred Brooks in the Mythical Man Month talked about the need “Plan To Throw One Away” — the hindsight you have after building the first implementation drives the improved second implementation. With compilers and IDE’s today, the reality is every interesting program is written and rewritten tens if not hundreds of times before you even call it done the first time.
It is strange that people who work with an entirely logical medium — software developers — continually want to pretend they are ‘artists’, ‘craftspeople’, ‘artisans’, ‘writers’, ‘performers’ even. It is some kind of delusion. If you design systems by some logical understanding of their component properties, and some experiment where things are incompletely known, then you are doing engineering. And there is nothing wrong with that! It does not mean the job is automatable or predictable — engineering requires insight, judgement, and creativity. — comment on Hacker News
Without commenting the use of ‘delusion’, I will point out one core difference between software creation and other sorts of engineering: malleability.
malleable: Capable of being shaped or formed, as by hammering or pressure
Is there an engineering discipline where the product you create is anywhere near as subject to change during the development process as software? And when I say subject to change, I am talking about change driven by the designer, not by PHBs.
I’ve worked with electrical engineers; guys designing and testing circuit boards. The spin cycle (edit/compile/test/debug) on interesting Verilog designs is large. For really useful pieces of IP like a PCI Bus implementation the simulations may take hours , if not much longer, to complete.
Software guys have no patience for that; it drove me nuts to burn an hour playing basketball between tests of my embedded code. And the engineer in question is a really smart guy.
In a two-week cycle of development for a new feature I will rewrite, improve, destroy, re-frame, and generally fold, spindle and mutilate my implementation. Yes, not every task gets this treatment, but if it is an interesting, important part of the code, you can’t just shoot out your first cut and be done.
In this, software seems to be fundamentally different from other traditional engineering disciplines. I can’t imagine bridge builders really have this sort of cycle time; or mechanical engineers, etc. In many, if not most, of the physical engineering disciplines they use computers to model their designs up front, and that has gained them some turnaround time, but in software it’s different: the model is the product. You don’t finish analyzing your model, then then push out a “real” one, and see if your modeling/simulation software was accurate: in software you ship the model.
This leads me to another observation: Software is often finished for a long time before it is complete.
By this I mean that every developer needs to evaluate, constantly, whether they have achieved the best trade off between better and good enough. The chunk of code you’re working on may be executed once in a blue moon and not be a performance hindrance; call it done as soon as it works at all. Or it may be deep code, linchpin code around which your product’s performance and correctness revolves: get that sucker as right as you can in the time constraints you have. Making that trade off at the right time gives managers headaches, and is all too often ignored by young software people.
So you know what I think. What do you think?
Is software handmade?