3 ms·

As time goes by there is going to be more and more "old" code out there, and generally that will either have to be maintained in its current state or converted

As time goes by there is going to be more and more "old" code out there, and generally that will either have to be maintained in its current state or converted to something newer. And to do that you're going to have folks who are both familiar with it and are willing to work on it - except that the young bucks today just really don't want to do that. I'm hearing from IT employees of local corporations that if their code base is twenty, ten, or even just five years old now, they can't find young folks who are willing to work on it. And even if they do find them, they don't necessarily have the skills to do that work, nor any particular inclination to really learn those skills, nor are they willing to stick around for very long even if they do start the process.

jpindar 7y ago
It may be risky but I've started putting "working with legacy code and obsolete languages" in my list of skills.
harimau777 7y ago
I think that a lot of engineers consider the opportunity to work on new technology and code to be part of their compensation. In that case, in order to attract them a company would either need to allow them to do that or increase other forms of compensation. However, it doesn't seem like many companies are willing to do that.
- southern_cross 7y ago
  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.

jpindar 7y ago

It may be risky but I've started putting "working with legacy code and obsolete languages" in my list of skills.

harimau777 7y ago

I think that a lot of engineers consider the opportunity to work on new technology and code to be part of their compensation. In that case, in order to attract them a company would either need to allow them to do that or increase other forms of compensation. However, it doesn't seem like many companies are willing to do that.

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