There are books about it. Many books. Books about projects that started with good budgets and good intentions, and in the right language and with the right tools, and eight or nine months later they've been to-and-through the last ditch “death march” and they're still not done. Only now you have half as many programmers as you used to. What goes wrong? Why so many books?

I see the same sort of things over and over; we all do. (Hence, the books...) But a few things in particular stick out in my mind. Oh Monks, what sticks out in yours?

Take the time to define “what does it do, and for whom does it do it?”

Two-thirds of the books about Web Pages That Suck talked about the same thing:   if the site does not do what it's supposed to do, for the people for whom it's supposed to do it (inside or outside the company's walls), it's not going to “be successful.” If you don't do that first, it can be the quintessence of Perlishness and still flop.

Beauty is skin-deep

Visual design is not enough, and you can't wait until visual design is perfected before you start building the stuff upon which you will ultimately attach that pretty “skin.” Don't build a blonde. ;-) Don't be beguiled by a pretty but vacuous smile; a bouncing icon; a clever coding trick; a meaningless Flash; cleverness or difficulty.

Build (or steal) the foundation first

“Build,” of course, means “use CPAN shamelessly.” Whatever you're doing, you're not the first one to be doing it. So, don't build anything from scratch. But do build the foundation first, and build well. And build as little as possible. There are dozens of frameworks out there, and they're not all just for blogs. You'll never get a second-chance to do your framework.
Don't repeat. I repeat: don't repeat. ;-)

Start with a town, not a planet

So it's going to do everything in the world someday? Start small. Deliver often. But build (or steal) your foundation well enough for Atlas himself to stand on.

Don't “scrap the old and start over.” Don't even say in public that you might.

That crufty old “legacy” system used to be the greatest thing since sliced bread, and it doesn't take an accountant to know that, in just a very-few years, you or (more likely) your successor will be saying the exact same thing about this one. If the old system was “built wrong,” have you changed and improved your process to be sure that this one won't just follow it down the same old dog-track? If the present system is really not-so-bad, design and build upon it.
We've already got the reputation of being an “engineering” industry that builds things costing millions of dollars which have a business life-span of no more than four or five years. Accountants, CFOs and CEOs hate that. But they love terms like “return on investment” and “durable.”

Your thoughts?