There is lots of evidence that Agile helps reduce technical debt and it keeps building with Waterfall. But Agile is simply a project management methodology. It doesn't specify exactly how you write and test code. that's where other things such as SOLID, refactoring, unit testing, continuous integration, etc come into play and help reduce technical debt even more.


>That's an excellent metaphor (or is it a simile?) and it fits in with my big company experience pretty well.
>
>It's a lot less relevant to the small to mid size market where I tend to work now, and where things happen more quickly and spontaneously.
>
>I hope this doesn't sound too cynical- I don't mean it that way- but after many years in this business, I've concluded there are only two "right" answers to the queston "Is this a good way to develop this project?"
>
>The first one is "It is if my technical and business instncts and training tell me it is." Of course that's an ellusive criteria and it changes day by day as new gadgets and techniques emerge.
>
>The second one, and it's a close second, is "It is if someone will pay me what I ask for while doing it that way."
>
>I have to have both, but I alway consider them in that order.
>
>The two harmonize more often than not, and that's what makes this profession such fun!
>
>Regarding agile development, I'll have to check it out.
>I was on teams who used PERT or variations of it quite successfully on some very large projects when PERT was the flavor of the day during the 60's and 70's.
>There were 30 or more people on a team then, and projects ran for years.
>Now Mark Z and a couple of his buddies write a billon dollar app in a few weeks in their spare time!