Every single legacy application I've ever worked on has had analogous code buried in it somewhere.
An application I've just been "repairing" recently has a spot where it uses two separate queries to pull two full table sized lists of values, then manually joins them with a loop, and then manually re-orders the joined values into groups selectively ignoring some rows, and then embeds the the whole reordered list in a web page. The page takes around 20 seconds to load. Switching it to use a single properly formatted SQL reduced load times to under a second.
Another legacy app I'm employed to "repair" has one single 'template' for every page on the whole site. Its first ~500 lines conveniently consist of a giant and highly nested if/else clause to set the page variables and inline javascript.
Such things are the result of "IT experts," "Software Managers," and "Product Administrators" who've never done real software/web development in their lives hiring random "programmers" who have history or psychology degrees and think they can program because they made a form in PHP.
It only gets lovelier when eventually somebody realizes it's a huge security risk and hires an outside development firm to "secure" it. (Giant eye roll. If they couldn't vet a programmer, you can bet they're great at vetting security consultants and contract developer shops.) Did you know that randomly moving code into folders named "private" and "public" for a few thousand dollars can solve giant architectural and security issues like ridiculously easy XSS and SQL injection?
I don't know what the deal is, but a huge proportion of people writing code are plain incompetent.
At my last company we fired someone who created huge amounts of work for everyone (he thought he could secure page content and alert messages by using base 64 encoding as a stand in for hashing and encryption, for example) and a few months later he was hired as lead developer by a pretty reputable educational business.
> I'm not old enough to be responsible for stuff like that but I am incompetent enough.
Now that is a great conversation starter! I assume you think you know more than the senior/lead/architect on the team. You might, but have fun with that mentality. It's not sure to last. :)
>Another legacy app I'm employed to "repair" has one single 'template' for every page on the whole site. Its first ~500 lines conveniently consist of a giant and highly nested if/else clause to set the page variables and inline javascript.
oh, oh! I'm doing one of those. Only, it's a modern, MVC version, so there's actually a couple of dozen controllers with a single function each, and all actions snake through The Great Maze of Ifelsedom to set their rightful values, before traversing it once more on the page view file
Manager: "Uhm, I thought you said changing that label would be a 5 minute task?"
That is, computer running the sign on the front of the store pulls data from here, and you've completely broken it because now the page loads a second time before it can finish drawing the screen. It /needs/ that delay on the HTTP request in order to catch up. A real programmer would have thought of that. Add some loops, sleeps and rands; we can talk about your reckless conduct in the morning.
What's worse is when fake delays are put into the code because (stupid) people think that the computer can't possibly be doing a good job if it retrieves the results in under a second. If it's "thinking", it's working well!
> hiring random "programmers" who have history or psychology degrees and think they can program because they made a form in PHP.
That's pretty unfair to people coming from history or psychology who actually can write good code. Just because you don't have a degree in CS doesn't mean your code is shit. This is purely anecdotal, but my predecessor at my current job was a CS graduate and wrote code like in the OP.
One of the real issues has to do with the mentality of coding. There are people regardless of background who approach coding as a job, and those who approach it as a craft. You want the latter, not the former.
Here's my rule:
If you don't look back at code you wrote a decade ago with some degree of horror, you are either an extraordinarily good coder, or you aren't a good coder at all.
I tend to spend a lot of time planning (almost as much as coding). I do tend to notice big changes over a period of 2-3 years but areas where I can notice improvements in say six months.
I think I spend too much time planning and not enough time just getting shit done. It's one of the things that I feel like I have to work on this year.
I don't think it is necessarily a bad thing. I spend a lot of time planning because I find my coding productivity is higher. Often it's better to let problems sit for a bit than to code then first, or if one does a mock-up it is an exploration that is part of the planning, to be discarded and done right a second time.
But what this means is I rarely come in the next week and wonder what I was thinking (it does happen, but rarely). More often I look at things, over a few months figure out better solutions to coding problems and my style changes accordingly.
I became an English major because I'd been coding since I was six years old and preferred to learn how to become a better writer.
At the time, the majority of incoming CS freshman did not even harbor the most basic ideas or curiosity about how a computer functioned. They had all heard they could make mounds of money. When I took elective CS classes in college, I had graduate CS students attempting to copy off of me.
It's possible CS students and programs have changed since the 90s, but based upon the CS graduates I encounter, I expect they haven't improved that much.
I knew a music major who was a better coder than most of the CompSci grads.
At one job, I judged coding ability by the number of times your SQL woke me up due to huge I/O usage[1]. Many a CS graduate cannot read a query plan.
1) if it looked like a reasonable query and it was just Sybase's crap optimizer, I gave them a pass. Although, after a while, you learned to force the indexes.
Yeah, I didn't mean to sound so derogatory, but out of non-formally-trained developer co-workers I've ever had only a handful didn't create work for everyone.
The two most common issues are inability to create sanely defined and decomposed schemas and clearly written queries, and poor ability to structure code in an organized way.
That said, I have known a couple very good coders without any kind of formal education. They just seem to be outliers.
When dealing with formally trained developers I've certainly encountered the incompetent also, but I'd say at an easy majority of trained coders I've worked with are competent enough to not be hard to work with.
Mind I you I do not claim to be a "superstar developer" or anything. The state of the art tends to change just a bit faster than I can keep up with these days.
Conversely, I'd hazard a guess that <10% of my outgoing CS class were competent in the way you describe... I'm fairly certain that the "ability to create sanely defined and decomposed schemas and clearly written queries, and structure code in an organized way" is the outlier here.
Speaking as a former history major, thanks! :-) Code like that is written by people who don't really understand how their code works and there are plenty of CS majors in that category. With any luck, they are swiftly promoted to management where they can do less harm.
I know it's unfair to generalize, but seriously if we'd had to put numbers on it and perform statistics on it (something most psychology degrees are pretty capable of even though the way they do it might raise questions) I'm rather sure the outcome would be close to: sorry, but 90% cannot write good code. Why I think this? Because I've seen and fixed code written in multiple laguages by psychology degrees (about 20 in total, from more than one institution) for the last ten years. And there are just no words for how awful it was. Hell, I've seen matlab scripts in which I would use the same dataset for both dataset arguments and still the result was there was a statistically relevant (p < 0.01) difference between the two.
I'm starting to really dislike the term "legacy code". It implies the code is bad because it's old. It perpetuates the misconception that code gets "stale" and problems build up. But that's not true. "Legacy code" is bad because it's BAD. All code is "legacy code" because unless the project is brand new, it has some history. We just don't call good old code "legacy code" because it hasn't caused us any problems. There is no reason to correlate bad code with age.
I think you're misunderstanding the term. Legacy code -- like legacy lots of other things -- is the intersection of "bad" and "it's too late to fix now".
Code which can be fixed easily isn't "legacy". Code where a replacement would need to be bug-for-bug compatible in order to avoid breaking things is "legacy".
My favorite definition of legacy code is bad code for which no tests exist. It's terrible because people have no idea what to do with it and no idea what they're breaking when they change it.
I've heard of that scenario, but I'm curious about what the best way to produce a bug-for-bug replacement would be. Should you do it right, and then put a layer in front of it that switches/transforms the output to match the old errors?
Code sitting on the same machine can keep on performing the same way forever.
But other things change. The library changed its interface. You coded your crypto lib when MAC-then-Ecrypt was all the rage. You aren't handling HTTP/1.0 headers. Windows 7 doesn't even have those 16-bit drivers any more.
I hate the "throw everything away and rewrite with the brand new frame work every two years" that some parts of the web development community seem to have (and then get angered when you ask about a version over six months old because it is what you installed everywhere). But sometimes software does rot if it's old and no one is trying to keep it up-to-date.
In 'Working with Legacy Code', Michael Feathers defines legacy code as code without sufficient tests.
The great thing about this definition is that it doesn't matter how old the code is - if it can be changed without worry about introducing unwanted behaviour because of test coverage, then it's not legacy.
It also means that you can write new legacy code right now!
The only legacy code that people talk about is bad legacy code. People never fondly remember the function they wrote ten years ago that's still doing what it should do, no debugging required.
It's always the function that's been rewritten twenty times that gets labelled as legacy code.
While code may not go bad with age, the surrounding world (compilers, frameworks, dependencies) change constantly. So while the code quality of a million LOC Java 1.0 application might be stellar, maintaining it may still be a royal pain. So in one way code does get "stale" when left untouched for too long.
An application I've just been "repairing" recently has a spot where it uses two separate queries to pull two full table sized lists of values, then manually joins them with a loop, and then manually re-orders the joined values into groups selectively ignoring some rows, and then embeds the the whole reordered list in a web page. The page takes around 20 seconds to load. Switching it to use a single properly formatted SQL reduced load times to under a second.
Another legacy app I'm employed to "repair" has one single 'template' for every page on the whole site. Its first ~500 lines conveniently consist of a giant and highly nested if/else clause to set the page variables and inline javascript.
Such things are the result of "IT experts," "Software Managers," and "Product Administrators" who've never done real software/web development in their lives hiring random "programmers" who have history or psychology degrees and think they can program because they made a form in PHP.
It only gets lovelier when eventually somebody realizes it's a huge security risk and hires an outside development firm to "secure" it. (Giant eye roll. If they couldn't vet a programmer, you can bet they're great at vetting security consultants and contract developer shops.) Did you know that randomly moving code into folders named "private" and "public" for a few thousand dollars can solve giant architectural and security issues like ridiculously easy XSS and SQL injection?
I don't know what the deal is, but a huge proportion of people writing code are plain incompetent.
At my last company we fired someone who created huge amounts of work for everyone (he thought he could secure page content and alert messages by using base 64 encoding as a stand in for hashing and encryption, for example) and a few months later he was hired as lead developer by a pretty reputable educational business.
... sigh