Up-Front Design: Not just for Chumps

You’re a “bottom-up” developer, eh? Elaborate please?

That was the opening with recently with a “senior architect” at a company I’d inherited. It turns out that this person’s definition meant “I start coding, and let the architecture evolve as I code”
Yup.
Let that sink in for a bit.
Oh, to help it sink in, understand that this wasn’t for wee-tiny components either — this was for the whole shebang, the system as a whole!
(hence the scare-quotes around “senior architect”)

The above is something I’ve seen quite a bit of, especially from “big company refugees”, people who’ve done their time at Accenture, IBM, Microsoft, or some such, and have come into start-up land, having absorbed all the wrong ideas from said companies. In a nutshell, “Process is bad”.
Look around your company — if you have people like this, be afraid, be very very afraid. They are going to be (or already are!) living embodiments of the “maintenance load equals available resources” trope (•).

Up front design is valuable — I shouldn’t have to explain the reason why, but just to flog this point
• It creates a starting point for your vision of what you want to build
• It clarifies the system structure
• It provides a common lexicon for everybody working on the project to discuss things (“Wait, you’re embedding monitoring? I thought I was!”)
• It helps identify the highest priority items, and risks

It’s crucial that you do so — if you don’t you’ve already lost.

(•) You’ll find that systems built by these people tend to work by happenstance, not circumstance. The overly complex nature of the beast is something that they probably take pride in , largely because they’re pretty much the only person who knows how everything works!