Personally, I think the ideal software development process boils down to three things:
1. Every decision is reflected in exactly one place in your project.
By this, I don't necessarily mean documented. Documentation is there to direct the people who are implementing the decisions, and to explain the business context and background information that's necessary to understand the actual code/schema/designs/whatever. I mean that, if a customer's name is limited to 32 characters, you type that number 32 exactly once in your entire project, and everything that needs to know how long a customer name can be refers to that one place where you originally recorded it.
2. Your tools allow each decision to be expressed clearly, succintly and quickly
Most of the worthwhile progress I've seen with software development is about letting the developer express their intent quickly and without ambiguity. String code in C is basically arithmetic manipulation of arrays of numbers. String code in .NET or Ruby is a whole lot friendlier; there's a compile and runtime overhead, but Moore's Law is on our side and, with a few exceptions, I think speed of development and ease of maintenance are becoming more important than speed of execution for most software these days.
3. Everything else is generated automatically.
If I change my mind about something, I don't want to have to tell a whole bunch of classes that I've changed my mind. I don't believe it's possible to build software without making some assumptions - even if I have a signed-off set of requirements, I'm still assuming that the person who signed the requirements understood what the client actually wants - and when these assumptions turn out to be wrong, I want to be able to correct them quickly and painlessly.
I have a homebrewed code-generation system based on CodeSmith that will generate a pretty comprehensive set of domain model objects and supporting DAL and stored procedures based on a SQL Server database. If we decide that a customer's name is compulsory and is limited to 32 characters, I change the Name column in the Customer table in our DB to a varchar(32) NOT NULL, and re-generate the code. 30 seconds later, my Customer class includes validation rules that check that Customer.Name is not null, not empty, and no greater than 32 characters - and throw a descriptive exception "Sorry, Customer.Name is limited to 32 characters" if you exceed the limit. The generated objects implement the IDataErrorInfo interface for automatic validation of data-bound WinForms apps, and use a variation on the MVP pattern that means that for each business object, we also generate an interface defining that object's editable fields - so you make your CustomerEditForm.ascx.cs code-behind class implement ICustomerView, and you can validate by calling Customer.ValidateView(this, "Name") from your user controls and get a nice (and completely auto-generated) error message if there's anything wrong with the name you've just entered.
That example is from Real Life. That's why it's a bit... technical.
[Potential spoilers after the photo... careful now.]
Driving home from watching Iron Man tonight, it occurred to me... in the movie, they do basically the same thing, but they do it with style. There's a scene about halfway through Iron Man where Tony Stark, our intrepid millionaire-playboy-genius-weapons-designer-turned-superhero, is putting the finishing touches on his Iron Man suit in his Malibu beachfront workshop. (I told you fiction made it look cool.) His computer system - known as 'Jarvis', apparently - brings up a 3D visualisation of his latest design; Tony casually asks Jarvis to "throw a little hot-rod red in there", and then goes off to drink scotch and dance with Gwyneth Paltrow while the system does the actual suit fabrication.
Ok, so I'm assuming there's some A.I. involved and that a certain visual style is implied by the phrase "hot-rod red" - but that's just about configuring your tools to suit your preference. Otherwise, it's just a really powerful configuration and build server... you make a decision, you record it once, and the system does the rest while you go dancing. Oh, and there's also the fact that it makes experimental rocket-powered bulletproof flying superhero suits instead of database-driven websites... but we can work on the details later, right?
Anyway. Point is - next time I have to explaining code generation and continuous integration to a non-developer, I'll start by asking if they saw Iron Man, and we'll take it from there.