Hacker News Reader

Comment by adatta02 | Hacker News Reader

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.

View on HN

"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.)

so you kinda skipped the code review and refactoring parts, right?

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?

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.

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.

"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.

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.

Reply on news.ycombinator.com