One of my team members shared this article with me: Treat bugs as fires. The author said,

“There are software devs who follow a different approach. They focus on fire prevention, not fire cure. Sure, they have to put out fires. But they use each fire as an opportunity to learn how to prevent fires, and then they build new parts of the city in a way that prevents the fires they have seen. Over time, these teams live in cities that don’t burn down. They go weeks and months between alarms going off. They rarely even have building code violations (risks found by QA or build verification tools).”

There are very few number of such teams. It’s because balancing between firefighting vs. fire prevention is hard:

1. Firefighting is heroic and many managements reward such heroic behavior. If they don’t do so, there will be no fire fighters. The dilemma is: then, preventing fire is less rewarded than firefighting and it’s human nature to go after bigger rewards. So fewer people will do fire prevention and more people will do firefighting.

2. Few people stay in the same place long enough to start to harvest from their investments in fire prevention. To optimize for the outcome in 18 months, I would rather to cut a lot corners in order to ship a lot of shining features, get a promotion, and move on. The corner-cutting will hurt us after 2-3 years, but why would I care if I am not here anymore?

Both need to be address by the managements:

For (1), the managements have to first be conscious about how he/she is rewarding firefighting vs. fire prevention. Then find out a balanced way to encourage fire prevention while keep firefighters a desired job.

For (2), attrition is natural, but the managements can keep people stay a bit longer and can make ownership stable. It also depends on the management’s judgment. Management needs to point it out when people cut corner and punish people if it’s too much.

That’s why the management is so critical (especially the first line as well as middle management). If the management fails to steer the team toward the right balance between firefighting vs. fire prevention, or the management themselves only plan to be here for 18 months, the team/product has little chance to thrive.

I have been always thinking that we are very early in the history of software. Using timepiece as a metaphor:

• The software in the 50’s and 60’s were like the sundial.
• The software in the 80’s are like the clock made in 16th century: need to be wound daily, and off by a couple minutes daily.
• The software today are somewhat like the first generation of pocket watch, such as those made by John Harrison: they are pretty sophisticated and works really well, but each of them took John a dozen years to make.

Today there are very few number of watches are handmade. Most of them are hand-assembled, or purely machine made. When we look at the craftsmanship a few centuries ago, we don’t think their techniques are too impressive. A teenage today probably knows everything that the greatest mathematics and physicists knows in the 17-18th century. I believe, in maybe 50 years from now, when people look back at us and how we make software today, they will have similar feeling.

Today, all software are handmade. It has been talked for a decade or two about producing software in the way how today’s plants produce cars. But I believe there will be another several decades when that become true. By the time we retire, I believe most of the software will be written by software. There will be very few of software engineers at that moment. Their main job is to write the “seed” software or component, to kick-start the whole software-writing-software chain. When software is written by software, bugs will be like the fires.