Great article. My first thought was … you think too much! Self-reflection is good. But like anything, if you probe too frequently for data, you can end up mired in too many details. Also, Heisenberg’s uncertainty principle starts to have an effect: if you probe too much, you can alter the state of what’s being probed.
A lot of things you’re noticing and wondering about fall along that same dimension. I don’t think there’s a “right answer”.
Most people believe that all programmers are equally skilled. I’ve found there are people who work best from 30,000 feet and people who work best crawling through the weeds looking for loose change and bits of lost trinkets. They’re both necessary skills in any software project. People with the former skills are great architects, and those with the latter are great implementers. Sadly, when you put the latter in Architecture roles, weird things often happen. I’ll leave that for you to observe and discover for yourself.
Finally, while it’s good to collect requirements, you need to be mindful that people don’t often know what they really want or need. Henry Ford is quoted as saying that if you asked people what they wanted in terms of better transportation, they’d say something like “faster horses that don’t poop as much”. When asked about the iPad and why he thought there’s a market for it when nobody has ever asked for one, Steve Jobs replied, “Sometimes people don’t know what they want until you show it to them.” The iPad went on to become the fastest-selling new computing product in history, establishing an entirely new product category called “tablet computers”. (Of course, my thoughts are that we saw them for years on various Star Trek episodes, so they weren’t a total unknown.)
This is often the case in software. I spent some time last year implementing something that was fairly well fleshed-out by someone who interviewed a client who claimed to need something unique for their accounting. I built what was described (even though it didn’t make a lot of sense to me), and I was told that when they saw it, they said, “Well, that’s what we asked for; but now that we see it, we realize it’s totally unworkable.” (Didn’t surprise me a bit.) That’s what you get when a Marketer collects requirements from customers. Worse, somehow that made it onto my review as something I “failed to implement properly”, as if it was my fault.
Anyway, I’m a huge proponent of building prototypes. Most management teams think they’re a waste of time and resources. And this gets at the question of “when do you start coding”. If there’s a UI, build a prototype that lets people play with it and get their feedback — the earlier the better.
If there’s a complex function that needs to be implemented under the hood, then build a prototype to evaluate its dynamics, both in isolation and in concert with other components. Take your best guess how it might work and start there. But don’t be surprised if your guess is way off. If it’s a prototype, that’s fine, and that’s exactly why you build a prototype first! But if there’s a Manager somewhere who thinks you should be able to collect a bunch of requirements, do a thorough top-down design, and that the first thing you build in code will be a shippable product, then he’s a fool. Give him a copy of “The Mythical Man-Month” to read. Heck, read it yourself if you haven’t yet. :)
As Steve Jobs once said, “Stay Hungry. Stay Curious.”
