It's not about technology for its own sake. It's about being able to implement your ideas.
I've been on one side or the other of most approaches to managing software development: from hyper-detailed used of specs and flowcharts to variants of agile to not having any kind of planning or scheduling at all. And I've distilled all of that down into one simple rule: If you haven't done it before--if you haven't built something close to this before--then all bets are off.
It's one of the fundamental principles of programming, that it's extremely difficult to gauge how much work is hidden behind the statement of a task, even to where the trivial and impossible look the same when silhouetted in the morning haze. Yet even the best intentioned software development methodologies still ride atop this disorientation. That little, easy feature hiding in the schedule, the one that gets passed over in discussions because everyone knows it's little and easy, turns out to be poorly understood and cascades into another six months for the project.
This doesn't mean you shouldn't keep track of what work you think you have left, or that you shouldn't break down vague tasks into concrete ones, or that you shouldn't be making drastic simplifications to what you're making (if nothing else, do this last one).
What it does mean is that there's value in having built the same sort of thing a couple of times.
If you've previously created a messaging service and you want to build a new messaging service, then you have infinitely more valuable insight than someone who has only worked on satellite power management systems and decides to get into messaging. You know some of the dead ends. You know some of the design decisions to be made. But even if it happens that you've never done any of this before, then nothing is stopping you from diving in and finding your way, and in the end you might even be tremendously successful.
Except when it comes to figuring out how much work it's going to take. In that case, without having done it before, all bets are off.
(If you liked this, you might enjoy Simplicity is Wonderful, But Not a Requirement.)
permalink August 11, 2015
I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.
Where are the comments?