Software generations

At my first job I wrote long-lived software. I started that job ten years ago. The software that I wrote still runs today. It will continue to run for at least another decade.


At my second job I wrote short-lived software. I worked for that company for three years. Most software that I wrote for them lived for about eighteen months. As the company outgrew its software, the software got rewritten, replaced, or removed.


At my first job software outlived its authors. The members of my team have all left. Some to different teams, most to different companies. The software we wrote continues to operate.


At my second job authors outlived their software. I saw newcomers rewrite the work of their colleagues. I decommissioned services that I had created. I saw my work thrown away.


I have since started my third job at a small, fast-growing company.


What I see at this place is software written without consideration for the future. The authors have not considered the lifespan of the software. They have not considered the tenure of this company’s software engineers.


Software at fast-growing companies will tend to be short-lived. Requirements change at a rapid pace. Products evolve. Systems scale. What was important six months ago ceases to be. What was unimaginable a year ago becomes quite real.


When writing software in such an environment make it quick and easy to rewrite, replace, or remove.


People at fast-growing companies will tend to be newcomers. They won’t have your knowledge of company history. They will need to be productive before they completely understand the software. They may never completely understand the software before it ceases to exist.


When working with such people make your software simple and explicit.


Doing these two things is not particularly difficult. It requires writing software in a certain style. That style is very achievable, even when moving at the pace required by a startup. The challenging aspect is maintaining that style over time, as people join and leave.

A giant pile of rocks

There is a giant pile of rocks. It is in an inconvenient location. A leader directs you and a small group of others to remove the rock pile. You have no equipment. The only option is to pick up a rock in your hands, carry it to a nearby hole in the ground, then throw it in. So that’s what your group does. Every day.


Time passes. You make progress, but not enough. The rock pile is smaller, but still inconvenient. One day a new person joins the group. They are an expert rock-pile-remover. They have a lot of experience removing large piles of rocks. On arrival, they look around and start making comments.


The expert points at the large pile of rocks. “This pile of rocks is far too large. It is in an inconvenient location,” they say.


The expert points at a small pile of rocks that is halfway between the large pile and the hole. “That shouldn’t be there. Those rocks should be in the hole,” they say.


The expert points at one of your group balancing a rock on their shoulder as they walk to the hole. “It’s more efficient to cradle the rock in your arms and hold it close to your chest,” they say.


The expert directs their attention to the rest of the group. “We should be using heavy equipment to move these rocks. We would be able to move the pile a lot faster if we had heavy equipment,” they say.


Time passes. The small pile is a little closer to the hole. The large pile is a little smaller. You still have no equipment. The expert rock-pile-remover has left the group. “They have no interest in removing the rock pile,” they said.