5 ms·

>Fun fact: I have a friend who worked for Skype in Prague. He said the codebase is a true horror, an extreme mess, and that soon it would "reach a singularity"

>Fun fact: I have a friend who worked for Skype in Prague. He said the codebase is a true horror, an extreme mess, and that soon it would "reach a singularity" Being a developer, I read this and think, what developer thinks any existing codebase is NOT a mess. It's the number one developer complaint ever. They (we?) all think we know a better way.

topbanana 11y ago
I work on two systems at the moment, and they are in very good condition
anon4 11y ago
As someone who has seen several LARGE commercial software projects, there is a definite gradation from "it's hard to comprehend these layers of abstraction, but after a few days I kind of understand how they interact" to // X - uncommented on 1.2.03 to fix bug // Y - commented again on 3.2.03 because it broke stuff // if (condition) { ... logic here, half of it commented out ... }
- cakes 11y ago
  Of the same opinion, there is sort-of the architecture "mess" where it is complicated and you may just have to spend some time learning and/or see some hiccups because large projects are complicated and then there is the 15 year old code base where _everything_ feels hacked/tacked on.
lmm 11y ago
I've worked on plenty of good codebases. I think the key is continuous improvement. The code from 5 years ago is always going to be worse than today's code, but as long as you're able to improve code as you work on it it doesn't get too bad.
- criddell 11y ago
  Once when I was interviewing for a job, I was given and offer and I accepted it conditionally. I asked to sit with a senior developer for 30 minutes and browse the code. Turns out it was in great shape and the person that gave me the walkthrough was one of the greatest programmers I've ever had the pleasure to work with.
  - verbify 11y ago
    Do you do this for every job you apply to?
    - criddell 11y ago
      No. This company's main product (the one I would be working on) had been around for a long time so I was concerned about what kind of shape the code was in.
CydeWeys 11y ago
A lot of the codebase at Google is pretty darn good. Certainly nowhere close to approaching a technical debt singularity where further progress becomes impossible.
cookiecaper 11y ago
Yeah, I agree. It's a really common excuse and I think it somewhat diminishes the credibility of those who use it. I don't think anyone's opinion on what constitutes a "truly horrible codebase" should count until they've been a developer for at least 10 years, worked at several different employers, and contributed to several different large open-source projects (which usually have the luxury of rejecting code until they feel it's "right" despite the potential commercial consequences, not something that most other projects get to do). "This codebase is terrible" is a common whine from newer devs and/or people that are just too lazy to put in the time to learn someone else's code. In the real world, production projects get messy because getting stuff done is more important than building a codebase that represents the paragon of academic excellence. That doesn't automatically make the project horrible.
- pyre 11y ago
  Depending know how horrible it gets that starts to affect maintainability and development of new features.
  - JustSomeNobody 11y ago
    You mean like SQL query strings sprinkled throughout and IF'd depending on the DB type? Yeah...
fweespeech 11y ago
I think I know a better way because I run a 7 figure a year project and the codebase isn't a mess. :/
- ultramancool 11y ago
  In my experience it mostly just boils down to having the right processes and being strongly motivated to do things right rather than push things out the door as quickly as possible. Assuming superiors have your back, this is doable. It's when they don't or when the developers lose or completely lack motivation that things start to fall apart. Lack of motivation often means lack of process, lack of process often means lack of testing and maintenance, lack of testing and maintenance often means lack of quality. It's a vicious cycle too - once you start down the road it's harder and harder to get motivated about your product again.
  - fweespeech 11y ago
    Pretty much. Honestly, the only reason the codebase isn't a mess is its a single project I've been able to tightly control and enforce things on [because its 100% my problem if something goes wrong]. The rest of our codebase is filled with drama. :/
minusSeven 11y ago
There is a difference between bad code you write today and make better tomorrow and code so bad that it takes you days to even understand it properly that making changes become very difficult and usually always breaks existing functionality.

topbanana 11y ago

I work on two systems at the moment, and they are in very good condition

anon4 11y ago

As someone who has seen several LARGE commercial software projects, there is a definite gradation from "it's hard to comprehend these layers of abstraction, but after a few days I kind of understand how they interact" to // X - uncommented on 1.2.03 to fix bug // Y - commented again on 3.2.03 because it broke stuff // if (condition) { ... logic here, half of it commented out ... }

cakes 11y ago
Of the same opinion, there is sort-of the architecture "mess" where it is complicated and you may just have to spend some time learning and/or see some hiccups because large projects are complicated and then there is the 15 year old code base where _everything_ feels hacked/tacked on.

lmm 11y ago

I've worked on plenty of good codebases. I think the key is continuous improvement. The code from 5 years ago is always going to be worse than today's code, but as long as you're able to improve code as you work on it it doesn't get too bad.

criddell 11y ago
Once when I was interviewing for a job, I was given and offer and I accepted it conditionally. I asked to sit with a senior developer for 30 minutes and browse the code. Turns out it was in great shape and the person that gave me the walkthrough was one of the greatest programmers I've ever had the pleasure to work with.
- verbify 11y ago
  Do you do this for every job you apply to?
  - criddell 11y ago
    No. This company's main product (the one I would be working on) had been around for a long time so I was concerned about what kind of shape the code was in.

CydeWeys 11y ago

A lot of the codebase at Google is pretty darn good. Certainly nowhere close to approaching a technical debt singularity where further progress becomes impossible.

cookiecaper 11y ago

Yeah, I agree. It's a really common excuse and I think it somewhat diminishes the credibility of those who use it. I don't think anyone's opinion on what constitutes a "truly horrible codebase" should count until they've been a developer for at least 10 years, worked at several different employers, and contributed to several different large open-source projects (which usually have the luxury of rejecting code until they feel it's "right" despite the potential commercial consequences, not something that most other projects get to do). "This codebase is terrible" is a common whine from newer devs and/or people that are just too lazy to put in the time to learn someone else's code. In the real world, production projects get messy because getting stuff done is more important than building a codebase that represents the paragon of academic excellence. That doesn't automatically make the project horrible.

pyre 11y ago
Depending know how horrible it gets that starts to affect maintainability and development of new features.
- JustSomeNobody 11y ago
  You mean like SQL query strings sprinkled throughout and IF'd depending on the DB type? Yeah...

fweespeech 11y ago

I think I know a better way because I run a 7 figure a year project and the codebase isn't a mess. :/

ultramancool 11y ago
In my experience it mostly just boils down to having the right processes and being strongly motivated to do things right rather than push things out the door as quickly as possible. Assuming superiors have your back, this is doable. It's when they don't or when the developers lose or completely lack motivation that things start to fall apart. Lack of motivation often means lack of process, lack of process often means lack of testing and maintenance, lack of testing and maintenance often means lack of quality. It's a vicious cycle too - once you start down the road it's harder and harder to get motivated about your product again.
- fweespeech 11y ago
  Pretty much. Honestly, the only reason the codebase isn't a mess is its a single project I've been able to tightly control and enforce things on [because its 100% my problem if something goes wrong]. The rest of our codebase is filled with drama. :/

minusSeven 11y ago

There is a difference between bad code you write today and make better tomorrow and code so bad that it takes you days to even understand it properly that making changes become very difficult and usually always breaks existing functionality.