4 ms·

Is it buggy? Is it insecure? Is it slow? If the answers to those questions are no. Then you the problem and you should look for employment elsewhere. You are u

Is it buggy? Is it insecure? Is it slow? If the answers to those questions are no. Then you the problem and you should look for employment elsewhere. You are unhappy in that job, and you rewriting the codebase would potentially make the above questions answer to a YES, inflicting damages in the company. Now, if the above questions have yes as an answer. Talk to your manager, explain how it won't scale, how it is hackable, and the bugs you found - and get the blessing to make things better! Do not badmouth the previous maintainer/author you do not know the circumstances that led them into creating such a codebase.

throwaway_19393 8y ago
Somebody fathered a legacy codebase.
- JamesBarney 8y ago
  Only successful applications have the pleasure of getting old.
  - Retra 8y ago
    "Successful" by literally any measure.
    - yayana 8y ago
      I'm not sure about "any" measure, the average startup probably has no surviving code in production.. Even the average in acquired startups, if we count acquihires..
    - dwaltrip 8y ago
      Success, in this context, means having solved some problem for a meaningful length of time.
      - Retra 8y ago
        That doesn't exclude anything. Code can exist to pad resumes, feed paranoia, and bolster egos, manipulate people, or simply because someone can't admit their own mistakes. Anything can be a solution to a problem.
        dwaltrip 8y ago
        Yes, those things do happen. However, that isn't what I meant by the word "problem". I was talking about end-user problems.
- DoreenMichele 8y ago
  So you're saying they speak from experience and know whereof they speak.
- marktangotango 8y ago
  All code is legacy, the only code that’s not is the code that’s not written.
w-j-w 8y ago
Someone's a bit touchy on this subject. Is there a reason you're using a throwaway to voice this opinion?
- Varcht 8y ago
  Hard to guess their motives but it is easy to click on their username and see that they post a lot from it.
theossuary 8y ago
This seems like a great post to vent a little bit. I'm definitely a bit touchy on this subject. I like to think I'm pretty good at programming, development, and generally architecting solutions. I don't have a lot of experience, but I have a bit of talent and spent a lot of free time learning. Solving problems with computers is something I'm passionate about. I started this particular project without any idea of what it was (okay, they told me what it was, but it turned out to be something completely different). When we did a kickoff it was myself, two other developers (who both said during the kickoff they didn't want to be on this team, and wanted to go back to admin'ing MSSQL databases), and a non-technical TPM (last time he touched a terminal was a decade ago, and he wasn't particularly interested even back then). I ended up doing pretty much all the work. My PM would CC me on emails, I'd write the stories, he'd help prioritize them, and I'd do them. The first few weeks they wanted three services stood up and managed in an automated fashion. I got it done, it wasn't pretty. Hell I hadn't even figured out a DNS scheme, but this had to get done so other teams would be unblocked; it was the development account so I wasn't too worried about rushed work. Then we got more requests from other teams, and vague requirements from the infosec and governance teams. Then the board that reviews new technologies shot down our (my) requests to introduce automation services like Ansible Tower. Then the AWS team shot down our request for multiple accounts, one per environment. At this point the Cloudformation isn't scaling, I beg and plead for some time to freeze feature development and move to Terraform. I asked for 3-4 weeks, and was given 4 days. This was the one chance to move to Terraform though, otherwise we'd be using Cloudformation for the foreseeable future. So I took it, deciding I could rush through the Terraform rewrite, because then at least we could refactor it later during downtime. Next thing you know a year has gone by and we're going into production. Everything on the devops end goes pretty smoothly. My velocity is crap though, due in large part because of the shitty rushed work, which it seemed was all I was capable of. A few months after go-live, we finally get a real TPM, which was a godsend. I was moving to another team at this point, and so his first order of business was to replace me with two new guys. I spent a lot of nights interviewing and a month afterwards helping them get up to speed. I and the new TPM gave them cover that month so they could embark on rewriting the Terraform. They ignored my suggestions on how to refactor it, which is okay, I was leaving the team, it was their code as now. But it was hard, hearing them laugh at the code behind my back, saying how bad it was. Never giving me a chance to justify it, or even reading the commit messages, to understand why it was done that way. I'm off the team now, and while I recognize I left a lot of legacy code behind (which I'm not proud of), it wasn't just me who created it. It was also the business who said time and again development speed was the most important thing. That's how one legacy codebase was created. There were a lot of things I might have been able to do differently (mostly politically), but I truly believe I did the best I could with what I had. But what do I know? My new TPM seemed to agree with me, but maybe he just didn't want to make an enemy. Perhaps I could have headed it off if I'd said the right words to the right people. I don't know, will never know. This experience is why I don't make fun of others solutions. Somebody put effort and time and thought into it, and I guarantee (in most cases) I don't have that context to properly evaluate it.
baddox 8y ago
A software project can be fast, reliable, and secure while also being extremely poorly engineered and extremely difficult to maintain and extend.
- unit91 8y ago
  Not a large one.
  - workmad3 8y ago
    "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." — C.A.R. Hoare, The 1980 ACM Turing Award Lecture Always loved this quote.
paulie_a 8y ago
Why can't you badmouth the previous developer? Sometimes they were simply shit developers and wrote large quantities of shit code. Circumstances be damned, I've seen a few developers that should outright find a new career.
- workmad3 8y ago
  Generally because once you start badmouthing a person, it quickly gets into politics rather than being a technical discussion about the problems you're trying to solve. And with politics it's generally less about what you know than who you know, so the person who's had a chance to build connections in the company will probably come out on top.
seabird 8y ago
If you ask me, this is a pretty awful approach. "Bug-free", secure, and fast are not the only metrics of whether or not a codebase is worth keeping alive. Some codebases are so obscenely dangerous that you really shouldn't be giving a shit whether or not it "works", because it's only a matter of time before it doesn't. There are code practices that are inexcusable under any circumstance. Sitting on a fucking nailbomb when it's in your power to change it because you don't want the headache of having to push for a real solution will catch up with you in the end. I'm not saying that you have an option in a do-or-die situation where it needs to be done in a couple days. I'm also not saying that you should subvert or defy management to execute a massive overhaul or total rewrite. I am saying that if you understand a system, know that it's fundamentally flawed, and have a window to fix it (even if it's a really tiny one), but choose not to, you are part of the problem. The standards that software developers are held to in terms of quality are an absolute joke, and the "it hasn't completely imploded our business operation, so don't even think about fixing it" mentality is where those standards stem from.
partycoder 8y ago
You have identified 3 important non-functional requirements: robustness, security and performance. But what about: - maintainability, extensibility, reusability, configuration - mean time to detection / mean time to repair during an incident - bus factor, cost of adding more developers, documentation Code can still be problematic in terms of those and I think that would be closer to what the OP described. Consider you have 2 cars: both are reliable, but during maintenance one of them requires you to buy rare and expensive replacement parts that you need to import yourself, only one shop in the entire city can work with it and it takes 2 weeks to get the work done. Which car would you rather have after going the process I described 3 times?

throwaway_19393 8y ago

Somebody fathered a legacy codebase.

JamesBarney 8y ago
Only successful applications have the pleasure of getting old.
- Retra 8y ago
  "Successful" by literally any measure.
  - yayana 8y ago
    I'm not sure about "any" measure, the average startup probably has no surviving code in production.. Even the average in acquired startups, if we count acquihires..
  - dwaltrip 8y ago
    Success, in this context, means having solved some problem for a meaningful length of time.
    - Retra 8y ago
      That doesn't exclude anything. Code can exist to pad resumes, feed paranoia, and bolster egos, manipulate people, or simply because someone can't admit their own mistakes. Anything can be a solution to a problem.
      - dwaltrip 8y ago
        Yes, those things do happen. However, that isn't what I meant by the word "problem". I was talking about end-user problems.
DoreenMichele 8y ago
So you're saying they speak from experience and know whereof they speak.
marktangotango 8y ago
All code is legacy, the only code that’s not is the code that’s not written.

w-j-w 8y ago

Someone's a bit touchy on this subject. Is there a reason you're using a throwaway to voice this opinion?

Varcht 8y ago
Hard to guess their motives but it is easy to click on their username and see that they post a lot from it.

theossuary 8y ago

This seems like a great post to vent a little bit. I'm definitely a bit touchy on this subject. I like to think I'm pretty good at programming, development, and generally architecting solutions. I don't have a lot of experience, but I have a bit of talent and spent a lot of free time learning. Solving problems with computers is something I'm passionate about. I started this particular project without any idea of what it was (okay, they told me what it was, but it turned out to be something completely different). When we did a kickoff it was myself, two other developers (who both said during the kickoff they didn't want to be on this team, and wanted to go back to admin'ing MSSQL databases), and a non-technical TPM (last time he touched a terminal was a decade ago, and he wasn't particularly interested even back then). I ended up doing pretty much all the work. My PM would CC me on emails, I'd write the stories, he'd help prioritize them, and I'd do them. The first few weeks they wanted three services stood up and managed in an automated fashion. I got it done, it wasn't pretty. Hell I hadn't even figured out a DNS scheme, but this had to get done so other teams would be unblocked; it was the development account so I wasn't too worried about rushed work. Then we got more requests from other teams, and vague requirements from the infosec and governance teams. Then the board that reviews new technologies shot down our (my) requests to introduce automation services like Ansible Tower. Then the AWS team shot down our request for multiple accounts, one per environment. At this point the Cloudformation isn't scaling, I beg and plead for some time to freeze feature development and move to Terraform. I asked for 3-4 weeks, and was given 4 days. This was the one chance to move to Terraform though, otherwise we'd be using Cloudformation for the foreseeable future. So I took it, deciding I could rush through the Terraform rewrite, because then at least we could refactor it later during downtime. Next thing you know a year has gone by and we're going into production. Everything on the devops end goes pretty smoothly. My velocity is crap though, due in large part because of the shitty rushed work, which it seemed was all I was capable of. A few months after go-live, we finally get a real TPM, which was a godsend. I was moving to another team at this point, and so his first order of business was to replace me with two new guys. I spent a lot of nights interviewing and a month afterwards helping them get up to speed. I and the new TPM gave them cover that month so they could embark on rewriting the Terraform. They ignored my suggestions on how to refactor it, which is okay, I was leaving the team, it was their code as now. But it was hard, hearing them laugh at the code behind my back, saying how bad it was. Never giving me a chance to justify it, or even reading the commit messages, to understand why it was done that way. I'm off the team now, and while I recognize I left a lot of legacy code behind (which I'm not proud of), it wasn't just me who created it. It was also the business who said time and again development speed was the most important thing. That's how one legacy codebase was created. There were a lot of things I might have been able to do differently (mostly politically), but I truly believe I did the best I could with what I had. But what do I know? My new TPM seemed to agree with me, but maybe he just didn't want to make an enemy. Perhaps I could have headed it off if I'd said the right words to the right people. I don't know, will never know. This experience is why I don't make fun of others solutions. Somebody put effort and time and thought into it, and I guarantee (in most cases) I don't have that context to properly evaluate it.

baddox 8y ago

A software project can be fast, reliable, and secure while also being extremely poorly engineered and extremely difficult to maintain and extend.

unit91 8y ago
Not a large one.
- workmad3 8y ago
  "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." — C.A.R. Hoare, The 1980 ACM Turing Award Lecture Always loved this quote.

paulie_a 8y ago

Why can't you badmouth the previous developer? Sometimes they were simply shit developers and wrote large quantities of shit code. Circumstances be damned, I've seen a few developers that should outright find a new career.

workmad3 8y ago
Generally because once you start badmouthing a person, it quickly gets into politics rather than being a technical discussion about the problems you're trying to solve. And with politics it's generally less about what you know than who you know, so the person who's had a chance to build connections in the company will probably come out on top.

seabird 8y ago

If you ask me, this is a pretty awful approach. "Bug-free", secure, and fast are not the only metrics of whether or not a codebase is worth keeping alive. Some codebases are so obscenely dangerous that you really shouldn't be giving a shit whether or not it "works", because it's only a matter of time before it doesn't. There are code practices that are inexcusable under any circumstance. Sitting on a fucking nailbomb when it's in your power to change it because you don't want the headache of having to push for a real solution will catch up with you in the end. I'm not saying that you have an option in a do-or-die situation where it needs to be done in a couple days. I'm also not saying that you should subvert or defy management to execute a massive overhaul or total rewrite. I am saying that if you understand a system, know that it's fundamentally flawed, and have a window to fix it (even if it's a really tiny one), but choose not to, you are part of the problem. The standards that software developers are held to in terms of quality are an absolute joke, and the "it hasn't completely imploded our business operation, so don't even think about fixing it" mentality is where those standards stem from.

partycoder 8y ago

You have identified 3 important non-functional requirements: robustness, security and performance. But what about: - maintainability, extensibility, reusability, configuration - mean time to detection / mean time to repair during an incident - bus factor, cost of adding more developers, documentation Code can still be problematic in terms of those and I think that would be closer to what the OP described. Consider you have 2 cars: both are reliable, but during maintenance one of them requires you to buy rare and expensive replacement parts that you need to import yourself, only one shop in the entire city can work with it and it takes 2 weeks to get the work done. Which car would you rather have after going the process I described 3 times?