Hacker News Reader

Comment by southern_cross | Hacker News Reader

IIRC, something like 90% of a software engineer's career will be spent doing "maintenance" work - working on existing code bases, some of which may (eventually) be quite long in the tooth. So it's something that the young bucks are going to have to get used to pretty quickly.

Also, a lot of the "new" stuff that they want to work on is really old stuff, just with a new name and a new coat of paint. Having been in the business for several decades now I see of lot of this, and I am by turns both amused and appalled by it.

View on HN

One caveat though. One way to avoid maintenance is to do full rewrites. This happens quite a lot in some domains and industries. As long as they can keep doing it and change company, they can avoid a lot of maintenance.

Doing a full rewrite is often asking for trouble, though. Somebody out there on the internet maintains a list of companies which have pretty much put themselves out of business by doing full rewrites. Why is this? Because it turns out that a lot of that "old, ugly code" is in fact various types of bug fixes and other operational accommodations. And when you do a full rewrite you tend to lose track of a lot of that stuff, meaning that you get to deal with it all over again, often in a quite painful manner.

A former employer of mine had switched from using custom code to packaged code, which introduced plenty of problems of its own but overall things were generally going about as well as could be expected. Then they decided that they just had to have the latest and greatest version of that code from the vendor, which promised all kinds of flashy bells and whistles. They unwisely jumped into this with both feet (they were an early adopter), only to find that when those bells and whistles were added a lot of the old code had been rewritten, too, which introduced (or maybe re-introduced) a large number of very serious bugs. By the time those bugs were corrected (if they ever really were), the company (which was by now my former employer) was in such bad shape that they were basically forced to close their doors. They had pretty much lost control over their inventory and financials, for example, and had committed themselves to fulfilling contracts which were based on cost figures that were woefully incorrect.

You're thinking of software that's been used and battle tested over many years. Most software will never reach that state.

A typical project is done by a handful of contractors or fresh graduates, that are all gone after a year or so. The next team will attempt to throw it away and start over more often than not. Point being, there is plenty of work in churning out software.

The "churn" thing may cut it the web world and such but not so much elsewhere. There's a local mega-corporation whose core code base is up to twenty years old now, and another whose is up to ten years old. Neither will probably be rewriting anything anytime soon because their current codes bases were the rewrites - expensive and time-consuming ones at that - so they're still adding new features and in some cases still trying to work out long-standing bugs. Neither is lately having much luck bringing in fresh graduates, either, because the young bucks don't want to work on that stuff - it's too old for them.

It's more common than you think. A lot of software don't last long. In fact a lot of software never actually get used.

Consider startups. Each successive group of new joiners will be adding a lot of new code and regularly throw anything that's already there. The churn is massive.

Have you worked with or for contracting company like Accenture? They assign developers to work on a project for a defined period of time, then disappear. It's not systematic that the software will reach a well working state, be handed over to the client and be actually used.

Another case. Things done with independent contractors. They are regularly hired to do nothing, well, maybe pretend to work and show a demo once in a while. If they produce something, it's not uncommon that the company didn't bother to hold the source code or build scripts.

Don't get me wrong. I fully agree with you. There is definitely more work available in maintenance than in new projects. However I also think there is enough work for a developer to make a career in either.

Yes, in the past I've been both a contractor myself and a contracting customer. And while I have seen newly built code bases thrown out for various reasons, from what I've seen that's not very common. AFAIK most of the code that I've ever written is still out there and working, unless maybe it died a natural death - company closed, got bought out, changed technologies, or what have you.

At my last gig as an independent contractor I did a lot of work on a project that mostly revolved around one of their largest customers. But then the employee who I was working with the most on this took early retirement due to medical reasons, which caused a change of direction somewhat because the employee who took over that job wanted to do things a bit differently. Then their big customer went out of business, which had a rather dramatic effect on the overall project. But as far as I know the code and such that I worked on is still in active use, it's just not nearly as critical to the business now as it used to be.

Before that I worked at a local mega-corporation, and there was one project there which I worked with on and off for ten years. But then one day, due to an act of legislative fiat, its reason for being just up and disappeared, so almost overnight all of the software and hardware that was used to make it work just went away.

But that same place suffered a bit from what you describe, in that it wasn't too unusual for them to spend money on software that didn't actually work, so it was ultimately abandoned. In fact, I had a running joke with them: "Gee folks, if I'd known that you were willing to settle for software that didn't actually work and that you were going to just throw out anyway, I would have only charged you half of what you paid those other folks to develop it!"

Reply on news.ycombinator.com