7 ms·

I'm not sure I agree. I've watched large numbers of people crash and burn running 'agile' processes. Agile doesn't work at all with large numbers of people on

by b0 14y ago

I'm not sure I agree. I've watched large numbers of people crash and burn running 'agile' processes. Agile doesn't work at all with large numbers of people on code that is constantly changing. Regardless of how you package it, the only way to achieve coherency and scalability of product development is through extensive planning, solid architecture and loose coupling of components. Agile throws those three concepts out of the window for time to market. Sure your first few iterations will survive this, but as your product grows, so will coupling logarithmically. This eventually cripples you.

wpietri 14y ago
I certainly agree that a lot of "agile" projects are clusterfucks, especially large ones. Of course, that's true of all software projects. And a lot of what people sell as "agile" is bullshit. So I'm not sure how much that proves. I also agree that well-run agile approaches throw big up-front design out. But I think they can happily achieve solid architecture and loose coupling. There's nothing you can achieve with up-front planning that you can't achieve by refactoring your design after a release. The main differences are that you need some supporting practices to make refactoring economical, and that you have much more information available to you after release than you do before-hand.
- b0 14y ago
  Well actually you're wrong on the following point: There's nothing you can achieve with up-front planning that you can't achieve by refactoring your design after a release If your application is relatively standalone then yes, but if you have heavy APIs and integration (which value adding applications usually do), you're up shit creek.
  - wpietri 14y ago
    Depends on what sort of API you mean. Internal ones are fine, so I suppose you're talking about public APIs. Which again are fine on the client side; it's just the server that can be harder. But I still think the way to good public server APIs isn't to sit in one's arctic Fortress of Architecture and think real hard. I think you just build and iterate in private, refactoring as you go, and then switch to a closed beta. And of course build your protocol in such a way that it's reasonably extensible. Up-front planing is still no panacea. You will have to change your protocol someday. Someday soon if you're up to something interesting, because the world doesn't stand still. And even if it does, your competitors won't.

by b0 14y ago

wpietri 14y ago

I certainly agree that a lot of "agile" projects are clusterfucks, especially large ones. Of course, that's true of all software projects. And a lot of what people sell as "agile" is bullshit. So I'm not sure how much that proves. I also agree that well-run agile approaches throw big up-front design out. But I think they can happily achieve solid architecture and loose coupling. There's nothing you can achieve with up-front planning that you can't achieve by refactoring your design after a release. The main differences are that you need some supporting practices to make refactoring economical, and that you have much more information available to you after release than you do before-hand.

b0 14y ago
Well actually you're wrong on the following point: There's nothing you can achieve with up-front planning that you can't achieve by refactoring your design after a release If your application is relatively standalone then yes, but if you have heavy APIs and integration (which value adding applications usually do), you're up shit creek.
- wpietri 14y ago
  Depends on what sort of API you mean. Internal ones are fine, so I suppose you're talking about public APIs. Which again are fine on the client side; it's just the server that can be harder. But I still think the way to good public server APIs isn't to sit in one's arctic Fortress of Architecture and think real hard. I think you just build and iterate in private, refactoring as you go, and then switch to a closed beta. And of course build your protocol in such a way that it's reasonably extensible. Up-front planing is still no panacea. You will have to change your protocol someday. Someday soon if you're up to something interesting, because the world doesn't stand still. And even if it does, your competitors won't.