Well, the Agile approach is to break them down into smaller things that can be accomplished in under 1,000 hours.
"There's nothing that can be accomplished in a single chunk taking more than a 1,000 hours that will produce a system with a manageable and maintainable level of complexity unless it is broken into smaller, well-defined and loosely-coupled components," perhaps.
Lots of meaningful things take thousands of programmer hours. Projects where those thousands of hours are meticulously planned for by non-programmers (whether by using "Agile" or any other process that sits on top of the process of programming) are fucking doomed from the jump.
The software that keeps all modern airliners in the sky is written by companies that have lots and lots of process. Do you think those software projects are doomed from the jump just because there's a lot of process involved?
You said "...Agile, or any other process...", so you're explicitly not limiting your statement to Agile methodologies.
Do you think _slower_ (as in taking longer to develop) software is the only outcome of the processes that avionics software companies use? Or do you think they are wrong or would be better off not using any of these processes?
The companies have a lot of process, but how do you know how the software was written? Usually I see things like a huge project that is failing while the initial prototype that works gets upgraded to production...which has often been produced by cowboys.
However, I don't work in the airline industry. I do work somewhere where one errant line of code can destroy productivity around the entire globe, brick computers, and really piss people off, and it's low process, cause the process guys can't ever get anything shipping.
As for Agile, I would suggest reading the Mythical Man Month circa 1995, the final chapter covers iterative development and makes a lot of sense, imho. Not sure why we need people with certificates selling snake oil where common sense works just fine.
Processes implemented to save lives are the product of death, and the process is put there to slow things down. Ask your friendly agile consultant how much their process is going to slow down your company.
They will tell you that Agile will make you faster. They might even be right, if it's replacing a bigger, worse process that already exists on top of the process of software development. But if it's adding a layer, it's going to slow you down and get in your way.
Any professional has some process, explicit or implicit: it's the observable regularities in the way they work.
Any team is going to have some explicit process, because there's no way people will converge on the maximally effective way of working together without some discussion.
So as far as I can tell, what you're saying is that it's impossible to take any process ideas from an external source, because every team is already maximally efficient. That doesn't make much sense to me.
In our case, the process we've converged on is the most efficient one we can find. But we're always looking for ways to make it more efficient.
So as far as I can tell, what you're saying is that it's impossible to take any process ideas from an external source, because every team is already maximally efficient.
Nope. I'm saying that the process of programming is what we should focus on getting better at. We should take improvements from wherever we can find them. Getting better at the process of Agile or Waterfall or Scrum or XP or Kanban or whatever else is dreamed up is tangential to our progress as programmers.
I agree that nobody should focus solely on getting better at, say, Agile. I also agree we should work hard at getting better at programming.
However, I don't think that focusing on programming alone is sufficient. A lot of projects fail for reasons other than bad coding, and almost no project exists where programming is the end purpose. You can do all kinds of great programming, but if you make the wrong thing, you're screwed. Ditto if you have a bunch of individuals doing great programming that doesn't add up to a functioning project.
I also think you're creating a bit of a false dichotomy. When I first tried XP, it wasn't for the sake of doing XP. It was because I wanted to improve how we made things for our users. So exploring XP wasn't tangential to better programming; for me it was closely related, in that programming was a big part of making.
