Software albatross

The only way to completely wash your hands of a piece of software you’ve written is to change employers, and sometimes even that doesn’t work.

Why is this? The primary reason is that it is very difficult to transfer software from one person to another. Good development processes help, but only so much. It’s difficult to hand over even the best code because you need more than code. It’s hard to jump into someone else’s code because it’s hard to jump into someone else’s head.

Taking over a software project is like taking over a novel. Editing to fix typos and grammatical errors in a completed novel is relatively easy. Taking over a half-finished manuscript is much harder. It might be easier to throw away the manuscript and write your own novel from scratch.

When someone does take over an unfinished book, it’s often someone intimately connected to the author. For example, J. R. R. Tolkien’s posthumous works, such as The Children of Húrin, were completed by his son and literary executor, Christopher Tolkien. The younger Tolkien had much more to work with than a set of notes. He knew the author and knew how he thought.

Because projects are so hard to transfer, the path of least resistance is simply to never transfer projects. Often projects are officially transferred to someone else but return like a boomerang when difficulties arise. Each project a developer works on adds some residual responsibility until he or she hits a ceiling of complexity and can no longer do new work. At that point, the developer either settles into maintenance mode or changes employers.

Thanks to John Z. Fields for recommending the title of this post. Literary allusion explained here.

Related posts

15 thoughts on “Software albatross

  1. Very true…and I’m still trying to work out which is harder to get rid of – successful software or ‘train crash’ projects…

  2. Debiprasad Ghosh

    Things are more difficult, when legacy codes of a group of legacy developer is given to a modern group of developer who are not at all interested in legacy languages or types. My advice, if they are confident in the domain of the problem, rewrite, although it will also be a legacy code very soon to make it asynchronous/parallel/cloud/rain/AI/social whatever it is.

  3. I’ve had four different exhausting multi-year projects in my life:

    * my pair of novels (blog at
    * doubling the size of my house, and doing 99% of the work myself.

    Each of these is like opening Pandora’s can of exploding snakes.

  4. We certainly struggle with this at SAS (a 36-year-old company) when programmers leave, retire, or die. Ultimately, someone else is assigned to maintain/develop the code so that it is not abandoned. Do you think that open source software is more or less likely than commercial code to be abandoned? On the one hand, many eyes have seen the core code, which argues for fewer problems maintaining it. On the other hand, what will be the fate of lesser-used packages and libraries created by researchers who move on to other pursuits?

  5. Rick: Open source software is not nearly as democratic as its image. Most projects are small and have only one developer. Larger projects may have many developers, but also have a “benevolent dictator” or a close-knit oligarchy of leaders. These leaders are not easily replaced. They may have a position for life, the life of the project if not the life of the leader. If they’re replaced, they’re replaced slowly by people they have worked with. So the situation is not that different from commercial development.

    On the other hand, since open source software is often a voluntary effort (with some exceptions: most of the work on the Linux kernel, for example, is done by people paid to work on it) you have more enthusiastic developers, and typically highly skilled developers.

  6. I am working on a project that has had many hands in the pie, plus little or no real coding standards.

    On the other hand I have picked up projects where the code reads like a well written book.

    The difference is SOLID, clean and DRY coding. There is more to good coding than it working.

    I recommend the Clean Coding book by Robert “Uncle Bob” Martin.

  7. That’s why in other enginerring jobs they standarized as much as they could, so everyone know’s the basic concepts and transfer is easier. We as developers have a long way to go. Right now there are too many people reinventing the wheel with their own solutions and ideas. Of course this is good beacuse sometimes someone will invent something awesome but most of the time we are drifting on the sea with too many posibilites and too many options.

  8. I had been thinking about software reusability and readability a lot lately and one thing I don’t see taught or guided correctly is style management. I know it’s hard to say ‘this is the way you will program’ but when programming in groups for manageable code over a period teaching and enforcing style management may be needed. We’ve all heard the ‘herding cats’ euphemism used over and over but someone’s got to put the yoke on and ‘herd.’

  9. Coding style standards are very important, but it isn’t quite as much of a problem as it use to be. Because IDE now will format your code with a given standard. A group should adopt a standard and stick to. It doesn’t really matter that much what the standard is as long as everyone follows it.

    I have found we a little work, you can make code read like a book without having a lot of comments. Comments should describe what and maybe why the code. The code should describe how.

    Most of the time lots of comments is a sign of unclean and hard to read code.

    The SOLID principles are like the rules for Database normalization. If you don’t follow them or being very away of why are you not following them, you will regret it.

  10. programming is still an immature art. it’s not like making steel. they just do it based on standards over and over to perfection whereas programming is still like oil painting everyone has their own way. See if you could make steel like that.

  11. I don’t see software development ever becoming standardized. When something becomes routine enough to be standardized, it can be automated and the process starts over.

    That’s not entirely accurate. Some things can be standardized, and there’s room for more. But by necessity, programming effort will always go toward whatever hasn’t been routinized.

  12. There is one sure-fire way to lose responsibility for a project: have it cancelled and the code thrown away or lost. That’s a common way to shed projects in the games industry, but also in larger companies where perfectly good projects are thrown away for “strategic reasons”. I know one chap who’s worked at the same company for 8 years and never shipped a line of code. Each of the four projects he’s worked on in that time has been cancelled: thrice because the customer has paid to get out of the contract before taking delivery, and once because a competitor released a superior, free alternative before completion, destroying the market. This programmer is currently maintaining my old code. :-)

  13. Writing a “new version of novel” isn’t always possible – new author should have corresponding experience in given topic. Even maintaining of a subsystem that has complex logic inside requires that maintainer had a lot of “business-specific understanding” to make correct changes in code.

  14. Well, at least it incitates you to build software that needs as little maintenance and support as possible, ie well documented and rather failproof..

Comments are closed.