David Shirey’s article, Managing RPG Program Complexity is, as the title suggests, aimed primarily at IBM i developers. The general principles, however, are true for anyone doing any sort of development and is worth a read. I particularly liked the last couple of paragraphs:
Limiting program complexity is a way of thinking, not a series of tips, and it starts with thinking through your design before you begin putting code on the screen. What are you trying to accomplish? What individual logical ideas make up your overall goal? How do you want to structure those ideas using programs and subprocedures?
… Most important, simplicity doesn’t just happen. Complexity just happens—you have to work at simplicity. But in today’s world, I can’t think of a more worthy endeavor.
If you didn’t manage to read that far, the TL;DR version is that any application consists of several descrete logical steps. Each of these discrete steps should be coded seperately and should be small enough that anyone (with the relavant language skills, obiously) should be able to glance at it and know exactly what it is doing. How you break out the various functional pieces is less important than that you do break them out.
Or, to rephrase it slightly, people who write massively monolithic programs deserve to have their fingers broken.
Lightly Seared on the Reality Grill 