Developers Are Quitting To Escape From Your Bad Code (zdnet.com) 160
An anonymous reader shares an excerpt from a ZDNet article, written by Liam Tung: [A] survey has come up with another reason why your engineers might want to quit -- their fellow developers' terrible code. Software engineers have long struggled with 'technical debt' created by past coding practices that might have been clever but also were undocumented and exotic. At a high level, technical debt is the price paid by supporting legacy systems rather than overhauling them or implementing a better, new system. The term can span everything from a major IT implementation, such as a core banking system that requires a decade of bug fixes, to the choice of programming language to build backend systems. In the latter case, subsequent language updates can require today's developers to rewrite old code written by long-gone developers who wrote under different conditions and who might not have documented what they did and why they did it. That's a big problem for companies that have millions of lines of code written in a language.
Stepsize, a firm that focuses on technical debt by tracking development issues in major code editors such as VS Code, conducted a fairly small survey of 200 software engineers to find out why they leave their jobs. The company said that 51% of engineers in its survey have considered leaving or left a job because of technical debt. Of that group who feel irked by technical debt issues, some 20% said that type of debt is the main reason they left a company. The results should be taken in context: the company's key selling point is trying to solve technical debt challenges that organizations face, but at the same time, technical debt could be one area worthy of attention considering how hard it is to hire and retain software engineers.
Technical debt, or 'code quality and codebase health', was the fourth most important issue cited by respondents. Salary still trumped it, with 82% citing it as one of the "most important factors" when interviewing for a new role. The survey allowed respondents to choose several primary factors. "Technical challenges and growth opportunities" was the second priority, with 75% choosing it as the one of the most important factors. Some 68% of respondents said remote work was the most important actor, while 62% put said 'code quality and codebase health' was one of those prime factors. Slashdot reader ellithligraw first shared the report, adding: "Yet another reason developers are quitting... to escape the technical debt, or schlock code, or code rot. COBOL anyone?"
Stepsize, a firm that focuses on technical debt by tracking development issues in major code editors such as VS Code, conducted a fairly small survey of 200 software engineers to find out why they leave their jobs. The company said that 51% of engineers in its survey have considered leaving or left a job because of technical debt. Of that group who feel irked by technical debt issues, some 20% said that type of debt is the main reason they left a company. The results should be taken in context: the company's key selling point is trying to solve technical debt challenges that organizations face, but at the same time, technical debt could be one area worthy of attention considering how hard it is to hire and retain software engineers.
Technical debt, or 'code quality and codebase health', was the fourth most important issue cited by respondents. Salary still trumped it, with 82% citing it as one of the "most important factors" when interviewing for a new role. The survey allowed respondents to choose several primary factors. "Technical challenges and growth opportunities" was the second priority, with 75% choosing it as the one of the most important factors. Some 68% of respondents said remote work was the most important actor, while 62% put said 'code quality and codebase health' was one of those prime factors. Slashdot reader ellithligraw first shared the report, adding: "Yet another reason developers are quitting... to escape the technical debt, or schlock code, or code rot. COBOL anyone?"
How interesting (Score:5, Insightful)
It's interesting that a company specializing in technical debt found that technical debt is considered a problem by 75% of developers.
Has the C-Suite of your company heard of this growing problem yet? Perhaps the same company who identified the problem can supply a solution.
Re: (Score:2)
came here to say this
'Article' is an Ad.
Re: How interesting (Score:2)
I wondered who coined the term "slash retirement"? It reminds me of the time I went to work for a startup. We got stuff published in industry trade rags, tech news sites, and Web 2.0 sites. I found out we paid money to a PR firm, and they made all that stuff happen. All we had to do was provide them with a draft of what we wanted published.
Re: (Score:2)
It's really hard to see how this product is worth paying for [stepsize.com].
Re:How interesting (Score:5, Funny)
Re:How interesting (Score:5, Funny)
Cause or effect?
Re: (Score:2)
Re: (Score:2)
Oh. I kind of always assumed that choosing to becoming an MCSE in the first place required lowered inhibitions.
Re: (Score:2)
Well, that means the other 1.99% are alcoholics but not raging. I guess they get the better pay and can afford the better stuff?
Re: (Score:2, Interesting)
Even though the article seems like an ad, I've been at places where they had insane amounts of technical debt. The Scrum master was the product manager, so the dev team has been in a sprint for years on end, and the PM felt that not in a sprint was like not hitting the gas pedal on a car. Nothing was done about technical debt, very little was documented, and the code had things like Rosary prayers, "Don't touch this, we don't know how this works" comments, duplicate tables in the backend database because
Re: (Score:2)
A language I used to program in / support was COBOL and there were a couple of cases which really stank.
One particular programmer would have variable names such as I1-V1, I2-V1, I1-V2 and so on. I had to work on a suite he had written - after he had left - and ended up doing global changes on variable names to make them less ambiguous. He would also have PERFORM S1. and then S1. PERFORM T1. That took quite a bit of restructuring. Once this new version was running ok I could start on the real changes.
In my
Re: (Score:2)
the PM/Scrum master would threaten them with a pink slip
An example where Scum went wild. Neither the PM nor the Scrum master has any authority over the team doing the programming.
But I'm sure: someone will blame Scrum :P (or "agile")
Re: (Score:2)
I'd be interested in solutions, because the C-suite almost always isn't. Make it work now, fix it properly later. Except "later" never gets planned in - if you're not working on the next great revision, you're not being a profitable deve
The Big Rewrite (Score:2)
It's not wrong to leave a job for tech debt. There are plenty of companies or managers out there who want to squeeze the last dime out of there software investment. A friend is mine works at small, but global food-logistics company who warehouse floor systems run on PDP emulators. His job was stressful for other reasons, but I could imagine quitting if upper management demands frequent enhancements to those systems.
On the other hand, I've wanted to leave companies that chose to solve tech debt with The Big
The best way to learn (Score:2)
The best way to learn to avoid technical debt is to put in the effort to fix some technical debt. Then you won't make those mistakes again (or you will catch them quickly).
These people who quit because of technical debt go from company to company, leaving behind a trail of ugly Webpack.config files and Makefiles. Learn to fix it once and you've got it.
Re:The best way to learn (Score:5, Informative)
The best way to learn to avoid technical debt is to put in the effort to fix some technical debt.
Provided your employer gives you time to engineer a fix rather than just bandaging it over and over in order to have the new feature done yesterday.
Re: (Score:2)
Then open-source shouldn't have any "technical debt" since as the saying goes, "it's done when it's done".
Re: (Score:2)
Provided your employer gives you time to engineer a fix rather than just bandaging it over and over
As the old saying goes, if you don't have time to do it right, you won't have time to do it over either.
Sometimes you just have to nod and smile to your employer, and then go in and do the right thing anyway. Your near-future self will thank you (and if you get fired for doing the right thing, your near-future self will still thank you, for extracting yourself from a bad work environment).
Re: (Score:2)
Re:The best way to learn (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
If the other guy was a good programmer, he simply wrote the code as I would have had. Hence nothing unpleasant or unreadable. And yes: that is actually a very universal standard amoung programmers/developers.
desire to rip everything out and redo it in a way intuitive to yourself is more or less universal
Only if the code is:
a) incomprehensible bullshit -and -
b) you have the original speccs
Because without speccs you have no real clue by what/how to replace it.
Sounds about right (Score:5, Insightful)
Developers have to have some reason to justify their existence, so why not blame someone else?
It's clear that in many cases the reason for pushing out a new version of software is for the eye candy. There is very little under the hood which is different from the previous version so the only other way to claim they're needed is for developers to make rounded corners, make things transparent or remove critical clues for where to click or drag something. And this doesn't include the newest fascination with hiding something until you happen to mouse over it, and then making it a full two pixels wide to grab onto.
This is also prevelant in web "design". Something as simple as displyaing a picture now requires several different scripts. And don't even think about displaying a video if you have less than 10 different scripts. Why make something simple when you can show off your coding instead?
Re: (Score:3)
It's clear that in many cases the reason for pushing out a new version of software is for the eye candy.
Yes, but the eye candy is just a means to an end. The real reason for pushing out a pointless new version is that the company needs to sell software in order to keep paying salaries, therefore they need to come out with new versions periodically, whether the anyone will actually benefit from the new version or not.
That's one reason so many companies are pushing "software as a service" subscriptions lately; if it catches on, it frees them from having to choose between ruining their own software with unneces
Re: (Score:3)
That's not really what technical debt is about.
When looking at new jobs I always ask if they have a lot of old code to maintain or if I'll be creating stuff from scratch. A mountain of old code is a big red flag, and if they specifically ask if I am happy to work with an existing code base there's no way I'm taking that job.
Might get lucky and the code is well documented and well designed so that making changes is easy, but more likely it's a giant pile a technical debt that the last person quit to get away
Re: (Score:2)
I _think_ w10 window border is *one* pixel thick?
I'd love to quit over technical debt (Score:2)
Re: I'd love to quit over technical debt (Score:2)
But where do I go that doesn't have it?
Startups. Then you can help them accumulate some, and jump to yet another startup. Or you can "pay it down" where you are, and assuming it's not a shitty company there's a bonus and promotion waiting. Or you can do what most people do, and just bitch about it as you bounce around between jobs.
Re: I'd love to quit over technical debt (Score:4, Insightful)
Most startups specialize in technical debt.
Re: (Score:3)
All too often, you need to burn it to the ground (Score:5, Informative)
One of the first projects I worked on, 38 years ago, was a nightmarish piece of Fortran, that looked reasonable, but had truly awful performance due to the use of a BACKSPACE command -- worked effectively on tape drives, but for disks it would go back to the beginning of the file and read forward one fewer records. I rewrote it (in VAX Basic, which at times was indistinguishable from VAX Pascal, but that's another show), and it was dozens of times faster, just by avoiding the BACKSPACE.
And years later, I was asked to help the Word Processing support group with some WordPerfect macros, was horrified at the half-recorded/half-authored mess, and said, "give me that, and don't touch it ever again!"... which eventually led to my being an expert in several generations of Microsoft Word VBA.
But I know there's stuff I wrote that I'd never want anyone to fix, only rebuild (some '90s cookie-driven shopping cart Perl code comes to mind).
It's not just "tech debt", it's learning, it's changing of standard ways of doing things, it's just getting better.
That works for utilities, small projects, but is obviously a nightmare for million-line projects.
Re: All too often, you need to burn it to the grou (Score:2)
In my 2nd or 3rd assignment I had to work on an MMI implemented in C using FORTRAN thinking. Shared global variables. No structs, no use of pointers, just arrays.
Surprisingly it did not use gotos as much as you would have expected.
Maintained that code for a few years.
Re: (Score:2)
In many case arrays are much better than pointers. There's less chance of wild addressing, and it's feasible to decide in the code if the index is within bounds without adding lots of complexity.
Pointers are drastically overused by many C programmers. At one point there was a decent reason to do so (optimization for speed), but that time is long past.
Yeah, I started out in Fortran. But when I have a choice I still prefer to avoid pointers. They're dangerous in anything except a really small piece of cod
Re: (Score:2)
Pointers *do* have their uses, but they *are* dangerous. They aren't *very* dangerous in small pieces of code, when you can see all the ways they are being used. But they're always dangerous. If you think you never make an obvious mistake, you can't have written much code.
Also, if you think Java and Python are toy languages, you don't know much about them. There are times when they're the wrong choice, but there are times when C is the wrong choice. (Actually, though, when C is the right choice, I usua
Describes Javascript (Score:2)
"coding practices that might have been clever but also were undocumented and exotic."
Describes every javascript "guru" ever. Why write code that's logical, straight-forward and readable when I can put everything in 1 line that only makes sense to me, who cares if anyone can debug it in 5 years.
Re: (Score:2)
No, I believe that prize goes to APL.
If it was hard to do (Score:2)
it should be hard to understand.
The fun part is when the code is exquisitely commented by one of the subsequent generations of engineers, but every single comment is something to the tune of, "this looks like it gathers the coefficients" and "Fred was the only one who understood it."
The last bit I found in some publicly released code from NASA. Closer inspection and research identified "Fred" as a staff scientist at JPL in the early 1960s.
Re:If it was hard to do (Score:5, Informative)
Debug code, comments lie.
Re: (Score:2)
It's rare that code does something hard these days. Most of us are just building scaleable websites or integrating APIs, we're not doing hard stuff. JPL might be a cool exception.
Re:If it was hard to do (Score:5, Insightful)
Re: (Score:2)
Yeah, but today's stacks abstract everything to the nth degree, so instead of a straightforward path, you end up with a Byzantine collection of brittle components that effectively makes for an environment that is difficult to learn and even harder to change without breaking something.
That's up to you. If you write code like that, then you'll end up with code like that. Don't write code like that, you don't need to.
Re: (Score:2)
That's often better than no comments, because you have clues to go on.
Re: (Score:2)
That's often better than no comments, because you have clues to go on.
Maybe. Sometimes the comments are misleading and send you down a rathole. Inline comments are a code smell.
Testing, testing, is this thing on? (Score:2)
Rather odd timing:
Automated Testing of Gameplay Features in 'Sea of Thieves' [youtu.be] You sure YT isn't hooked into Slashdot?
Breaking changes are a language failure. (Score:5, Informative)
"subsequent language updates can require today's developers to rewrite old code"
That's the definition of a failure by the language, and it's now a new language. It may share some semantics with the other language, but anyone trying to push breaking changes in the language itself should be seen as the enemy.
Sure, this keeps programmers employed, but everyone knows when they're doing a "bullshit job" that shouldn't even exist. Rewriting working code to satisfy a language wanker's vanity is the most bullshit job I can imagine. No wonder people quit over it.
Re: (Score:2)
*cough* Python *cough*
Re: (Score:2)
There's something to be said for having a mix of compilers from different vendors: it keeps the code healthy.
But like many places, the argument for using clang everywhere because it reduces development cost is beginning to win at our place. We're going from gcc, msvc and xcode/Apple LLVM to mostly LLVM. I can appr
Re: (Score:2)
I prefer GCC but it does get slow for very large projects. The error reporting is a lot better than clang.
"Clever" code? (Score:2)
"past coding practices that might have been clever"
You say that like it's a good thing.
Here's a new saying (Score:5, Insightful)
"Clever code is the enemy of maintainable... erm, code."
Somebody should probably rephrase that into something better, but you get the general idea.
Stop writing clever code for your own ego, write easy-to-read code that any idiot can read - and don't forget that this includes yourself in a few months.
Re: (Score:2)
"Clever code is the enemy of maintainable code."
A specific case of a more general principle:
Efficiency comes at the expense of resiliency.
Re: (Score:2)
In my career there has been many times when I've run across code in one language that looks like idioms in another language--C++ that looked like Assembly (yes, 'oops' was the only comment), and Perl that looked like PHP are two examples. The code worked but was awkward and didn't take advantage of language features. In most cases it doesn't make sense to touch working code, but it some cases the code was sometimes copied and used elsewhere and had subtle errors on edge cases. Allowing this to spread is
Re:Here's a new saying (Score:5, Interesting)
The problem here is setting priorities. A lot of that clever code you're talking about is the direct result of people trying to adhere to other rules such as code duplication being bad, configurability being good, magic values being bad etc. These things are almost without exception solved by making things more generic/abstract/configurable. So instead of Firing an Employee, they're now Deactivating an Agent and instead of creating an employee, they now need to create an AgentFactoryFactory that will yield a PersonFactory that can then be used to instantiate an Employee. But there's no code duplication so it's great!
It's a matter of priorities. And priority number one should be: write code that idiots can understand because we're all idiots.
Re: (Score:2)
That about sums it up nicely, but it's hardly a corporate-friendly way of saying it.
Re: (Score:2)
The real problem here is that so-called clever code is not always more efficient at all, but young coders who need ego boosts will write things in the most convoluted ways that seem clever at the time of writing, that takes minutes to understand by others instead of being near-instantaneously understood.
Experienced coders try to avoid clever code knowing full well that compilers will end up with optimized code in 99% of the cases, and that readability is more important than cleverness.
Re: (Score:2)
Re: (Score:2)
Stop writing clever code for your own ego, write easy-to-read code that any idiot can read - and don't forget that this includes yourself in a few months.
I was thinking of many systems (code and hardware) developed by an expert, the kind so brilliant they never document. It's all great but it can only be maintained by that one person. If that person not available, then that system is unmaintainable.
Seriously? (Score:2)
I have yet to work in a place, ever, where people are happy with the choices their predecessors made in coding style, methods, idioms, whitespace, tabs, build systems, source code repositories, desk chairs, wall color, etc.
You are happy to take the paycheck and work with what you've got, or you don't like what you're doing and move on. You don't join an established company to make really excellent code from scratch. And if you join the kind of company where you are making code from scratch, you're probably
Re:Seriously? Tabs!!!? (Score:4, Informative)
Re: (Score:2)
There are degrees to this.
Yes, some places it's just "ugh, this looks ugly". Some places are real problems.
Like the place I worked where the product was originally written in VB6 in the '90s. They had outsourced to the lowest bid in the 2000s, and it is now the late 2010s and they aren't allowed to use VB6 anymore...since it was more than a decade out of support.
They continued to outsource to that lowest bid, where apparently they only still knew VB6. So their "developers" wrote the code in VB6, changed
Orâ¦. (Score:3)
Re: (Score:2)
As an older dev with decades in the job, I have to agree with a lot of these observations. *In general*, the younger devs seem fairly sharp where I work, although we have one that really shouldn't be allowed near a compiler. I also think what probably contributed to a bunch of crappy older code was that years ago, there wasn't as much accountability since there wasn't as much process involved. Guys back then just checked their crap directly into the master branch unsupervised and unreviewed, and as long a
Re: We found the guy who hates commenting! (Score:2)
For every 1 well trained developer there are 1000 "developers" who did a 2 week javascript course after they couldnt find a job from their art history degree, now think they are gods gift to software development and lie on their CV to boot.
Finding that one good developer in that sack of shit is hard, keeping them is harder.
My code? (Score:5, Insightful)
My code works well, because I made sure that it does, because I know I will have to live with it going forward, and I don't want my life to be hell.
In my experience, (some) developers quit to escape from their own terrible code, and those of us who are left at the company are then called upon to triage their abandoned spaghetti for the rest of its miserable existence. The quitter, meanwhile, has moved on to another company, presumably to make another plate of pasta for them :)
Re: (Score:2)
Incompetent + agile (Score:3)
Re:Incompetent + agile (Score:5, Funny)
That's because you fucked up agile wrongly. There's a proper way to fuck agile up. Pay for real consultants with real bucks so you can fuck it up like a pro.
Bad code or not allowed to fix it? (Score:3, Informative)
Priorities are dictated by management. There is a difference between a system you're afraid to try to fix, and not being allowed to spend time to truly fix it. Both could be labeled "technical debt" by the buzzword focusing survey.
Technical debt causes (Score:2)
It's also a favorite result of new managers who have manpower available to rewrite popular tools they way they think they should be written, and re-invent very basic tools. Software packaging is a popular one. Switching working software to use a distinct language is another. The result is a new mortgage on new technical debt with variable interest rates and balloon payments due in a few years. It's similar to the business of flipping houses: the managers gain some short term successes, sell off their projec
Re: Technical debt causes (Score:2)
the managers gain some short term successes, sell off their project, and take on the next project
Because that's how they build their reputation. And eventually make it to the executive suite where they don't have to produce any more.
If you want quality code, go to work for an organization that has responsibility for operation and maintenance as well as development. Its up to your management to spend money on proper code vs hand-ho.ding the customer every time it breaks. And if you are the person who has to fix what you originally wrote ,you are more likely to comment it properly.
Not all technical debt is real (Score:3)
For sure, a lot of code bases have serious technical debt problems. But I've also seen a lot of devs see 20% of the problem and accuse the current solution of being a pile of technical debt while proposing a worse solution.
Of course, do everything you can to avoid and eliminate technical debt, but also remember that sometimes when the code is doing something seemingly weird it's because it's handling a problem you're not aware of.
Re: (Score:2)
Of course, do everything you can to avoid and eliminate technical debt, but also remember that sometimes when the code is doing something seemingly weird it's because it's handling a problem you're not aware of.
This is true, but on the other hand, I shouldn't be unaware of a problem the code handles. For me, this has been the largest source of frustration - I often don't know what's safe to touch because I try to go in assuming that my co-workers aren't idiots (some days it's easier than others), and that
In any case, The Grass Is Always Greener (Score:2)
... on the other side of the fence.
I can honestly say (Score:2)
I've always hated working on other people's code. I far prefer projects small enough to solo - during which at some point I invariably have to refer back to something I've forgotten writing, can no longer remember the logic behind, and sometimes didn't adequately document.
Then I hate working on my own code... but I've been through that cycle enough to mostly beat me into compliance on following standards and documenting my work.
Tech Debt = Code that some else wrote (Score:2)
I do consulting for SMB/MB.
Most of the initial consultation comments are that there is too much tech debt.
After several rounds of discussions it means "Code I did not write."
sign of the times (Score:3)
There's a bunch of kids around who think it's some sort of killer argument to shout "COBOL!" when they want to "move fast and break things".
When your fave language has survived as long as COBOL you might have a right to sneer at it.
And when you're done moving fast, try coming back in five years and see how people feel about the code you came up with.
Culture of continuous development... (Score:2)
There will ALWAYS be some technical debt, even with software lovingly crafted, taking onboard all of the principals of good software development.
It comes down to culture, that when the developers say "we have to iron out the problems with this legacy software, before starting 'the new shiny'" - and the company understanding this as being, in the long run, a time saving and thus money saving exercise.
If you are building new software on top of a shaky foundation, the technical debt just grows and grows.
The co
It's more a patch creep problem (Score:2)
You know the cycle of software design. Or, rather, the cycle of any technical solution. And therein lies the problem.
Something gets developed. Be it software, a system configuration, a firewall setup, a web presence. It does not matter. Some technical "thing". I will even go as far to assume that it isn't that different for hardware either. It gets designed, implemented, documented. Let's be generous and assume that it didn't get later than late and we actually didn't have to rush it out the door, but it wa
Always code as if... (Score:4, Funny)
features features features (Score:2)
The never ending demand for new features leaves no time to deal with tech debt. And the longer this goes on the harder it is to implement new features. I blame management. They ultimately decide the priorities. If you complain enough, they'll schedule a tech debt week, which is slapping a bandaid on a gaping wound.
Spagetti Code == Job Security (Score:2)
I'm surprised that know one knows this one.
The perils of a full rewrite (Score:3)
At a high level, technical debt is the price paid by supporting legacy systems rather than overhauling them or implementing a better, new system.
Implementing a new system just gives you an opportunity to make the same mistakes all over again [joelonsoftware.com]. A gradual overhaul of the existing system lets you keep the good parts of the old system (including the years spent finding all the corner cases and fixing ever more obscure bugs), while replacing the bad parts one at a time. This has to be done right, no bandaids that will fail again in 3 months.
Re: (Score:3)
I worked for an investment firm that had a C++ trading platform for registered investment advisors. It worked but it was old fashioned and hard to maintain. So they decided to rewrite it with .NET, replacing chunks of C++ until it was all ported. In the interim, the .NET front end would host C++ views and each iteration would replace some of them. Except we d
This is why I stopped working in webdev. (Score:2)
They are all hacks that are extremely overconfident because they live in their own filter bubble of circle jerk, and product only the worst spaghetti code.
I mean the fact that they are still in aggressive denial of the inner-platform effect that they built their entire world on should tell you all you need to know. And so should the oxymoron "living standard" (aka Google starving ALL the competing browsers.)
I switched to Haskell and real software. (With a bit of low-level code wherever necessary.)
Much bette
I see this way too often (Score:2)
technical debt... (Score:2)
Tell me about it! (Score:2)
I maintain several legacy products that were written in an idiosyncratic style, then embellished by a group who thought they were smarter than everybody else and wrote their code accordingly.
One notorious product was designed to do one thing, then they decided at the last minute that it needed to do something else. I've discussed a ground-up rewrite with my boss but there's no business case. We pulled this off with another product, replacing a gig of unreadable spaghetti code that tried to be all things t
Kernighan or Ritchie (Score:3)
This is why I hate C++ (Score:2)
and other "rich" languages. Rich languages allow for dozens of different ways a particular function can be written. Put another way, sure you know C++, but do you know that programmer's dialect? Put on a contest to write a simple bubble sort. I guarantee there will be submissions you will swear are in a different language altogether. Clever? Ooooh great, you get a cookie, but as a maintainer, I don't want to have to jump thru your cleverness hoops.
Talking about bad code (Score:2)
So you guys know how we use these all the times: com.company.object.method.etc....
So this guy has ObjectName.a,
So when we did a troubleshooting session in an S1 situation and I said:
ObjectName is "b"ing like this because the other object is busy "f"ing the database and they depend on each other.
Re:Technical debt isn't always "bad code" (Score:5, Insightful)
Sounds like a potential skill vacuum. As long as you all can find someone familiar with both the language and the OS there's no problem. Mainframers should be familiar with this situation.
Re: (Score:3)
Re: Technical debt isn't always "bad code" (Score:2)
It is debt if a contract is awarded that makes use of a derivative of that code. Cut-and-paste business practices, where engineers are liabilities, not assets.
Re: (Score:3)
The code was paid for when it was originally written. There is no "debt".
If the code is working fine and never needs to be changed or looked at, sure -- just leave it alone and let it do its thing.
OTOH if the code needs to be changed (due to newly discovered bugs, or changing business requirements), then the code needs to be understood. And if the code is overly complex, undocumented, or brittle, then whichever poor soul is tasked with the job is going to spend a lot of time figuring it out, and is likely to add a lot of regressions along with any changes (s)he comes up with, w
Re: (Score:2)
Re:Technical debt isn't always "bad code" (Score:4, Insightful)
What new developers looking at old code often forget is that the original authors weren't necessarily lazy or bad - they just had to get the job done in a tight timeframe and limited budget, as dictated by the business, often with an ever changing scope while the project is in progress, Thus they didn't have the luxury of writing the architecturally perfect masterpieces that they wanted to, nor did they have the time or resources to chase every bug or coding wart.
Once new developers get a few projects under their belt they realise these realities, become the older and wiser programmers and the cycle continues when the next generation is ushered in.
So it has been and always will be.
Re: (Score:3, Insightful)
Forgot to mention. There's always time to write a few brief comments to explain intent, and those that don't are doomed to burn in programming hell. It's the one thing that really those that follow - even if it's yourself in a year or two's time.
Re: (Score:2)
Re: (Score:3)
Where it gets tricky is when the author of the bad code is the manager the developer is reporting too. Thinks his/her code is his Gift to Mankind and masterpiece of creativity. Takes criticisms of old code personally and gives the poor developer bad annual review.
Sometimes the manager is right. I've witnessed more than a few upstarts complain loudly about the former coder's, now manager's, code and then be given cart blanche to replace it. Only for the end result to be slower, buggier and written in some flash-in-the-pan flavor-of-the-month language or framework. Ultimately I'm of the opinion that it's okay to let the newbies make this mistake as a learning experience, and it has the added benefit that it will be a point of pride to fix this code when it breaks. Eas
Re: (Score:2)