Development Speed vs. Maintainability

I've researched programming methodologies, and most of them seem to fall into two major groups: Agile and Waterfall. Waterfall is stereotypically slow, rigid, and exacting, where as Agile is faster and more flexible. Sometimes you have to program for speed - if, for business reasons (beating the competition to market, high workload, poor planning), you have a short deadline.

So how? How is your code, or your program different when you have to program for speed? Or is there even such a thing as programming quickly? I've definitely learned by now that I can't "code faster" - even the novice programmer knows we're not shoveling dirt here - we're solving problems.

Focus, for me, is the only thing that can speed up a coding effort. Notice I didn't say "development effort." Development encompasses much more than writing code. If given a coding task, intense focus and concentration puts me in the zone, where algorithms, codes, and bug fixes roll out smoothly.

But to speed up a development effort? Division of labor comes to mind first. A technical specification has to be drawn up, which divides the work into procedures and functions with inputs, outputs, pre-conditions, and post-conditions (yep, all that stuff you learned in programming 101!). Then you split it up, let the coders code, and in theory you'll just connect the parts later. Provided the tech spec is clear enough, well-thought out enough, and each coder tests their individual unit well enough, you'll quickly have a nice piece of software.

Or do you just start coding? Is putting code to the screen really the fastest way to develop software? It can be fun - who doesn't like to just start pumping out code, designing be damned. But for those who have taken this route, the inefficiencies show up later as the code base gets larger, and/or new features get added. At those points the design flaws become glaring, which is to be expected, because all you did was start coding without giving much thought to design.

Yes, you can still just plug along, hacking, patching, and adding until it does what you want. But good Lord, I feel for the poor soul who has to maintain and upgrade that software. I had the privilege/burden of working on a large piece of software that had been patched, upgraded, and customized by hundreds of developers over 15 years, with little management and consistency. Making changes to that software was not for the faint of heart. Even a seemingly innocuous change ended up causing a bizarre error in some other module of the software (I realize by definition modules shouldn't depend on one another, but they did!).

When I am afforded the time to actually design a piece of software, the end result is a logically organized, easily maintanable and upgradeable product. Naming conventions are consistent, and code/functions/files grouped properly and logically. Usually, though, my projects fall somewhere in between. You can see the roots of a logical design, alongside the hacking and patching that became necessary for one reason or another.

My question to the development world - what do you do when you need to code, or develop quickly? Do you just code hapazardly, ending up with more bugs or uglier code? Or can you develop quickly and still follow a good design, with good standards? If I need to pump out functions in a hurry, I don't look to see if everything is aligned properly and the names are consistent and make sense - I just put code to screen.

I can already hear the arguments against this approach, and I can't say I blame them. The alternative is to tell my customer/client/manager that whatever they want can't be done. But what I'd really mean is "what you want can't be done how I prefer to do it, but it can be done".