How to treat the people that built the system you work on

You are infinitely smarter than they are, better-looking, and taller - probably

You have been hired to work on a system. The system has problems. The usual problems:

• it doesn’t work all the time

• they want it to handle more work without slowing down or failing

• they want to add new things to it

• they want it to cost less to run

You have seen this all before. And as you dig into the system, you see more familiar patterns:

• the code is using an older way of doing things

• the system isn’t documented well

• there are places in the code that are very dangerous to change

• there isn’t an easy, consistent complete way to test the software

Clearly, the people who worked on the software before you didn’t know what they were doing. They are part of a long line of idiots that ended when you came along. Not everyone is as sharp and experienced as you are.

Getting to Work

You get to work making a list of things that must be changed. You avoid using the word rewrite, but it is a complete tear-down and rebuild situation; you’ll have to do it in phases. You try to avoid it, but you do let it slip a few times that the current system isn’t well built and that your predecessors are responsible for the situation you are in now. You imply that if you had built the system The Right Way, there wouldn’t need to be all this remodeling work.

After you make the list, the product manager gives you their list, and it is very long. A few things match on the two lists, but as you begin work, you notice that more of her list is getting pushed to active work. But there isn’t much you can do, so you start with the low-hanging fruit, fix a few issues, and create some tech debt cards for things that you find.

This builds credibility, so you start pitching larger-scale changes. It turns out that there seem to be constraints that you aren’t aware of, and many of your proposals aren’t rejected outright but seem to never really happen, either. You make more aggressive changes, the system doesn’t work, and the upgrades must be rolled back. Searching for more details, you realize that the system might be good enough from the perspective of the people who run the business, as they don’t ask you when you will reapply the changes.

Normal Life

You are stuck in meetings for most of the day once you get some experience and seem never to have time to sit down and think strategically. You do your best with what you have, keeping the system running and talking less and less about how bad it is.

Sometimes, sitting alone in your cubicle, trying not to be distracted by the four other conversations within earshot, you wish you were one of the first people to build this system. Oh, how you would do things differently if you were first on the scene without all these distractions and constraints.

---

Paid subscribers view additional commentary about this post, with links to useful resources on this topic. If you are reading this and thinking, “well it depends,” or “this is a gross oversimplification,” or “what an idiot,” then you might be interested in Additional Commentary for this post.