Building vs Maintaining: A Junior Dev's Perspective

The excitement of building a new application is unmatched. Maintaining an application is less fun. And the pain of maintaining an application that was built using heaps of tech debt is akin to stepping on Lego bricks.

The three apps I've coded thus far have started like this:

"I've got a million-dollar idea," I say to myself. "It's brilliant, and everyone and their grandmother will know about it soon enough."

This high keeps me going for a week or two as I build a bare-bones implementation of the ideas floating around in my head.

This is the easy part. The simple bugs that crop up during this initial phase of development are mild frustrations. They're usually due to being in a hurry or doing things out of order, but these bugs are never that hard to untangle in the beginning.

The hard part comes when I'm doing a full stress-test of my app. I start to realize there are many common cases that I had labeled as edge cases simply because they would have taken longer to develop. Then, I realize that entire features of my app have been built on a foundation of lies and broken promises.

Maintenance is dull and dirty work, and the only reward is that things don't continue to get worse.

Depending on your disposition, you might be tempted (as am I) to scrap the whole thing right then and there to start from the ground up.

"This time will be different," I say to myself. "I'll start by strongly typing everything, use my testing library to do test-driven development, and learn from my mistakes."

These are valid solutions for a side project. But if you're doing this for an employer, that means you haven't been using your time wisely.

And you wouldn't be the first developer to make the mistake of taking on tech debt for the sake of speed. It's how coding bootcamps (probably unwittingly) teach us to execute projects.

"You have one week, and you have to meet these loose requirements. The rest is up to you," the instructors say.

In reality, you're likely to get a similar set of instructions for a project from a business unit. If you're lucky, there's a project manager or someone who can negotiate to ensure the timeline includes room for thorough planning, testing, customer feedback, and a little more testing for good measure.

If you're not so lucky, you could be given a deadline and a set of features that are incompatible. It will be up to you to explain why you need twice as long as they're asking to ensure the product A) works and B) isn't a mess to maintain later.

Which brings me to maintenance, the less glamorous part of software engineering. In most other types of engineering, we imagine someone who designs the thing and then writes instructions for how someone else can maintain the thing.

In software engineering, you're probably going to design the thing, write your own instructions for how to maintain the thing, and then do maintenance on the thing yourself.

In software engineering, you're probably going to design the thing, write your own instructions for how to maintain the thing, and then do maintenance on the thing yourself.

I won't tip-toe around it: I hate maintenance. It sucks.

I dislike maintenance for the same reason I disliked playing outfield in baseball: you do a lot of work preparing for something that is only occasionally ever going to happen, you do your job when the time comes, and the team doesn't get any points for it.

Maintenance is dull and dirty work, and the only reward is that things don't continue to get worse. But like it or not, we have to maintain things. Otherwise we'd be living under mountains of discarded items because we couldn't be bothered to wash or fix them.

There is a silver lining to all this: maintenance does add value to a product, even if it doesn't feel like it. This can be proven mathematically. Depreciation is a loss of value (a negative number). The only way to offset a negative number is with a positive number (a gain in value). Maintenance prevents some depreciation, or put another way, maintenance is a positive value that offsets the negative value of depreciation. Therefore, maintenance adds value.

To illustrate how important maintenance is, let's examine a car. Imagine a base model fresh off the lot. You've driven it home and parked it in the driveway.

Fast forward a few months and you've put 5,000 miles on the car. You haven't changed the oil, but you did add a nice stereo system and some custom rims. It looks and sounds really nice, but you're not maintaining it properly.

Fast forward a few more months, and you've put considerably more miles on the car. You're thinking about selling it to get a new car, so you want to spruce it up a bit. You decide that what it really needs is a new spoiler and a pearlescent paint job. Maybe you'll sell it to an aspiring street racer, or a late twenty-something who played too much Need for Speed Underground.

Your car looks really nice, but you still haven't gone in for that oil change. On the way to park it somewhere people can see the "for sale" sign you've put on the windshield, it breaks down. You take it to the mechanic, and they tell you the engine is shot. There's no hope of repairing it.

Now what you've got is a very pretty pile of bells and whistles that can't do the one thing it derived all its value from: drive.

Because you didn't maintain it, the car lost value faster than you could add it with a spoiler, rims, paint, and a stereo system. Even if you'd have covered every inch of the car in a fine layer of 24k gold, it would still be functionally useless because it can't drive.

The same idea applies to software. Adding feature after feature to a core product that is dying because bugs have been hotfixed, punted, or outright ignored is like painting a dead car with actual gold.

So despite how painful it is, let's not ignore maintenance. And because it's going to suck either way, we can save ourselves time spent on maintenance by properly planning and testing our applications in the early stages. This makes maintenance suck a lot less.