4 ms·

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)

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.

user5994461 7y ago
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.
- southern_cross 7y ago
  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.
  - user5994461 7y ago
    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.
    - southern_cross 7y ago
      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.
      - user5994461 7y ago
        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.

user5994461 7y ago

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.

southern_cross 7y ago
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.
- user5994461 7y ago
  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.
  - southern_cross 7y ago
    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.
    - user5994461 7y ago
      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.