3 ms·

Disclaimer: I don't call myself 10X anything but I do work through 10X Management. I only work on legacy code, that's my specialty. My opinions are my own and d

by gregjor 10y ago

Disclaimer: I don't call myself 10X anything but I do work through 10X Management. I only work on legacy code, that's my specialty. My opinions are my own and don't represent 10X Management. First off not all legacy code is "shitty." The main reason I am 10 or 100 or 1000 times more effective with legacy code is that I'm usually the only programmer the customer has talked to who will work with it. Everyone else has one solution: Throw it away and start over with [insert favorite cool language/framework/ideology]. So at least in my experience it's not that I'm 10X more effective, it's that everyone else is 0X effective because they won't even try. It's easy and maybe fun to simply dismiss legacy systems as junk and shit and catastrophes, but when a business has a system that mostly works and they need some debugging, enhancement, improvement it's usually irresponsible to tell them to start over. When you do that you are telling the customer to throw away something that works, even though it has problems, and take a huge gamble on a new system that is 75% unlikely to even go live. You are telling your customer that your one hour reading of some code that you declare "shitty" is more informed than all of the cumulative experience of previous developers. You are telling your customer to change business processes, retrain staff, all on your word that you are more clever than the last team. Imagine if you had a leak in the roof at your house and the first five people you called out to repair it told you to tear the house down and start over. And they told you that because the house wasn't built with the kind of lumber and roofing they prefer, or they don't think it's aesthetically pleasing based on their strict adherence to Frank Lloyd Wright's style. Or that whomever built the house must have been morons because they didn't properly label all of the wires and pipes. That's a story I hear about software systems every month. The most important metric of software is whether it solves a business problem and adds value or not. What language it's written in, or whether the last programmer used spaces or tabs or camelCase or knew OOP as well as you think you do are not relevant metrics from the customer's perspective. And since a lot of the code I work on is not actually that old -- in fact it's just as likely to be the unfinished remains of the last green fields team -- I can say without hesitating that the worst code to work on comes from programmers who are so committed to an ideology or language or toolkit they lose sight of requirements and the only goal that matters: adding value to the business.

somehnreader 10y ago
This is the best thing I read for ages. I work with legacy systems all the time, lately mostly CRUD web apps, but I have debugged myself through pages of Excel macros, database drivers in enterprise systems and some code that was almost as old as me, and 100% agree with what you have written. Bookmarking this post for future reference.
deleted 10y ago
[deleted]
flukus 10y ago
> Imagine if you had a leak in the roof at your house and the first five people you called out to repair it told you to tear the house down and start over. And they told you that because the house wasn't built with the kind of lumber and roofing they prefer, or they don't think it's aesthetically pleasing based on their strict adherence to Frank Lloyd Wright's style. Or that whomever built the house must have been morons because they didn't properly label all of the wires and pipes. Sometimes they are required to tell you that. If there are obvious structural faults with a house then it's an OHS issue to be on the roof in the first place and the whole building could have to be condemned. A lot of software is in that state, but the organisations that use it have a remarkable ability to route around errors. I do agree for the most part, but as an industry we still rarely find that middle ground where maintainers can actually do preventative maintenance and slowly improve things. Very few maintenance programmers are actually doing maintenance work, there bolting on new features or fixing prioritized bugs. If I was in charge of building maintenance then my success threshold would be considerably higher than "the buildings still standing".
- gregjor 10y ago
  My analogy is imperfect, sure. And sometimes software is so bad that it should be tossed out. I mostly see that when business requirements have changed so much that the software is a drag, not adding value. Or a vendor went out of business (ask me about the companies left holding the bag because of SCO), or something else in the IT landscape caused the code to become obsolete and unworkable. But in my experience (and this is what I do) those cases are relatively rare. In the last 10 years freelancing I've taken on close to 40 projects, I've only told two customers that they should start over. In both of those cases we weren't looking at crufty 20-year-old code. The software was fairly new, just poorly designed or implemented (WordPress is not a great platform for everything, folks). One project was a pile of random piecework from low-price contractors hired online -- no conceptual integrity. Talking to other programmers who do the same kind of work I do, I get the same anecdotal evidence: most software systems are maintainable despite the best efforts of programmers to make things too complicated and obscure. Rather than rewrite from scratch it's safer to refactor bit by bit, fixing a defined set of problems little by little. That keeps your chance of success high and customer risk low. Try to remove dependencies rather than add more. Carefully get things like version control, testing, tooling in place, but don't get carried away, some code resists retroactive unit tests and you shouldn't be breaking stuff just to make it fit your toolchain. Resist the urge to "refactor" everything to suit your aesthetics or received wisdom about how code should look. You're right that it's more common to see features added on and the worst bugs addressed. That's usually because the core of the system is solid and doesn't need a lot of maintenance. It can also happen when the core is a black box no one understands and the programmers are afraid they'll break it. Most important is to listen to the customer but don't believe everything they say -- customers often can't describe in detail how their own business processes really work. Don't assume that just because the code is written in an old language or isn't based on OOP or doesn't have unit tests that it's shit -- you can blind yourself to good design principles that aren't in fashion anymore. And have some humility -- it's unlikely you actually know how to rewrite a non-trivial application from scratch and get a better result than what the customer already has, unless it's an unusable pile of goo already.

by gregjor 10y ago

somehnreader 10y ago

This is the best thing I read for ages. I work with legacy systems all the time, lately mostly CRUD web apps, but I have debugged myself through pages of Excel macros, database drivers in enterprise systems and some code that was almost as old as me, and 100% agree with what you have written. Bookmarking this post for future reference.

deleted 10y ago

[deleted]

flukus 10y ago

> Imagine if you had a leak in the roof at your house and the first five people you called out to repair it told you to tear the house down and start over. And they told you that because the house wasn't built with the kind of lumber and roofing they prefer, or they don't think it's aesthetically pleasing based on their strict adherence to Frank Lloyd Wright's style. Or that whomever built the house must have been morons because they didn't properly label all of the wires and pipes. Sometimes they are required to tell you that. If there are obvious structural faults with a house then it's an OHS issue to be on the roof in the first place and the whole building could have to be condemned. A lot of software is in that state, but the organisations that use it have a remarkable ability to route around errors. I do agree for the most part, but as an industry we still rarely find that middle ground where maintainers can actually do preventative maintenance and slowly improve things. Very few maintenance programmers are actually doing maintenance work, there bolting on new features or fixing prioritized bugs. If I was in charge of building maintenance then my success threshold would be considerably higher than "the buildings still standing".

gregjor 10y ago
My analogy is imperfect, sure. And sometimes software is so bad that it should be tossed out. I mostly see that when business requirements have changed so much that the software is a drag, not adding value. Or a vendor went out of business (ask me about the companies left holding the bag because of SCO), or something else in the IT landscape caused the code to become obsolete and unworkable. But in my experience (and this is what I do) those cases are relatively rare. In the last 10 years freelancing I've taken on close to 40 projects, I've only told two customers that they should start over. In both of those cases we weren't looking at crufty 20-year-old code. The software was fairly new, just poorly designed or implemented (WordPress is not a great platform for everything, folks). One project was a pile of random piecework from low-price contractors hired online -- no conceptual integrity. Talking to other programmers who do the same kind of work I do, I get the same anecdotal evidence: most software systems are maintainable despite the best efforts of programmers to make things too complicated and obscure. Rather than rewrite from scratch it's safer to refactor bit by bit, fixing a defined set of problems little by little. That keeps your chance of success high and customer risk low. Try to remove dependencies rather than add more. Carefully get things like version control, testing, tooling in place, but don't get carried away, some code resists retroactive unit tests and you shouldn't be breaking stuff just to make it fit your toolchain. Resist the urge to "refactor" everything to suit your aesthetics or received wisdom about how code should look. You're right that it's more common to see features added on and the worst bugs addressed. That's usually because the core of the system is solid and doesn't need a lot of maintenance. It can also happen when the core is a black box no one understands and the programmers are afraid they'll break it. Most important is to listen to the customer but don't believe everything they say -- customers often can't describe in detail how their own business processes really work. Don't assume that just because the code is written in an old language or isn't based on OOP or doesn't have unit tests that it's shit -- you can blind yourself to good design principles that aren't in fashion anymore. And have some humility -- it's unlikely you actually know how to rewrite a non-trivial application from scratch and get a better result than what the customer already has, unless it's an unusable pile of goo already.