11 ms·

The central thesis of the post “Optimizing for your software project becoming big is the same as optimizing a car to hit a rock wall - you are optimizing for fa

The central thesis of the post “Optimizing for your software project becoming big is the same as optimizing a car to hit a rock wall - you are optimizing for failure” is garbage. I can't imagine any sane engineer not realizing that writing say an operating system is on a different level of magnitude than writing some HTML peppered in with a little Javascript. Edit: "This is the reason I like agile. It emphasizes small, working pieces all the time. If you work with code this way, you can’t really become big. Instead, your project will be forced to be modularized and divided into smaller, more logical components that are highly cohesive and decoupled from each other." Using Agile really doesn't guarantee you any of this. You're still very free to abandon separation of concerns and end up with a tightly coupled mess.

Tamerlin 17y ago
"Using Agile really doesn't guarantee you any of this. You're still very free to abandon separation of concerns and end up with a tightly coupled mess." This is what I find usually happens with agile development. The software tends to start out small, but because it's not well thought out and because it tends to be rushed, even the small stuff becomes spaghetti startlingly quickly -- as happened on a current project, where after less than three months, we managed to cram THREE separate object models into a UI with a whopping TWO screens. (Imagine my frustration when what was six lines of code when I last worked on it now had over 500.)
- joevandyk 17y ago
  so you kinda skipped the code review and refactoring parts, right?
  - jamesbritt 17y ago
    I'm guessing you were modded down for implied snark, but it's well worth asking how a small project becomes a big project with no noticing, or noticing but not taking appropriate action. It happens to the best of us, the feature creep, the must-haves, the rush to ship. So, does agile actually fail to address this, or is this something subtle that manages to evade detection despite better practices and intents?
    - run4yourlives 17y ago
      but it's well worth asking how a small project becomes a big project with no noticing, or noticing but not taking appropriate action. Simple, nobody pays you to notice how much of a problem the software that works perfectly has become. They pay you to improve feature x by a very small amount, or to add feature y. So, sure Agile works fine, in the same world that most every other methodology works fine. It's not the methodology that makes good software, it's the people behind it.
  - Tamerlin 17y ago
    No, that's the sad part. But when you have 10 people tromping around the same code in a hurry it's hard to keep things clean and consistent even with code reviews... and there's been such a push for new stuff that there hasn't been time for refactoring.
    - aaronblohowiak 17y ago
      "nd there's been such a push for new stuff that there hasn't been time for refactoring." This is a management failure, and you haven't been practicing Agile.
      - Tamerlin 17y ago
        I agree. It's been what I would call lip service to agile, but that's about it. My experience with agile has been that most managers who seek to lead agile teams wind up equating rapidly typing code to rapidly developing software.
kingkongrevenge 17y ago
He's ignoring the reality of irreducible complexity. There is not always some cute dynamic language trick to cut down the code length. Some software is inherently very large and complicated, such as pretty much anything attempting to model a reality rather than just slinging data around. Modifying such code without static typing and a compiler would be a nightmare. Maybe you could write a big program with a dynamic language and cover it with so many automated tests it would work out OK, but the size of your tests might rival whatever amount of strongly typed code you managed to eliminate. This was the lesson of the C to C++ progression. C with all its type casting and void* simply doesn't work with big complicated programs. Same for perl & python and so on. You need as much consistency checking from the compiler as you can get.

Tamerlin 17y ago

"Using Agile really doesn't guarantee you any of this. You're still very free to abandon separation of concerns and end up with a tightly coupled mess." This is what I find usually happens with agile development. The software tends to start out small, but because it's not well thought out and because it tends to be rushed, even the small stuff becomes spaghetti startlingly quickly -- as happened on a current project, where after less than three months, we managed to cram THREE separate object models into a UI with a whopping TWO screens. (Imagine my frustration when what was six lines of code when I last worked on it now had over 500.)

joevandyk 17y ago
so you kinda skipped the code review and refactoring parts, right?
- jamesbritt 17y ago
  I'm guessing you were modded down for implied snark, but it's well worth asking how a small project becomes a big project with no noticing, or noticing but not taking appropriate action. It happens to the best of us, the feature creep, the must-haves, the rush to ship. So, does agile actually fail to address this, or is this something subtle that manages to evade detection despite better practices and intents?
  - run4yourlives 17y ago
    but it's well worth asking how a small project becomes a big project with no noticing, or noticing but not taking appropriate action. Simple, nobody pays you to notice how much of a problem the software that works perfectly has become. They pay you to improve feature x by a very small amount, or to add feature y. So, sure Agile works fine, in the same world that most every other methodology works fine. It's not the methodology that makes good software, it's the people behind it.
- Tamerlin 17y ago
  No, that's the sad part. But when you have 10 people tromping around the same code in a hurry it's hard to keep things clean and consistent even with code reviews... and there's been such a push for new stuff that there hasn't been time for refactoring.
  - aaronblohowiak 17y ago
    "nd there's been such a push for new stuff that there hasn't been time for refactoring." This is a management failure, and you haven't been practicing Agile.
    - Tamerlin 17y ago
      I agree. It's been what I would call lip service to agile, but that's about it. My experience with agile has been that most managers who seek to lead agile teams wind up equating rapidly typing code to rapidly developing software.

kingkongrevenge 17y ago

He's ignoring the reality of irreducible complexity. There is not always some cute dynamic language trick to cut down the code length. Some software is inherently very large and complicated, such as pretty much anything attempting to model a reality rather than just slinging data around. Modifying such code without static typing and a compiler would be a nightmare. Maybe you could write a big program with a dynamic language and cover it with so many automated tests it would work out OK, but the size of your tests might rival whatever amount of strongly typed code you managed to eliminate. This was the lesson of the C to C++ progression. C with all its type casting and void* simply doesn't work with big complicated programs. Same for perl & python and so on. You need as much consistency checking from the compiler as you can get.