Alright, pre-coding design. By that, I mean, the serious thinking one does before one starts typing code into the computer.
The first puzzle of pre-coding design is to identify when to start & went to stop.
Start When You Have A Story
When to start: when a story has been selected for implementation.
That starting condition will be tricky for noobs, so let me blather for a minute. There’s no time to discuss stories in general, but in short, by story I mean “slice of functionality that goes from ‘pixels to registers and back’ doable in less than a couple of days.”
All the way in and out is very important. A couple of days is very important. There’s other very important, too, such as valuable, and some unimportant parts noobs often think are most important. No way we have room to discuss how you get to stories like that, we’re gonna stash that for another day.
Now, don’t go off telling everybody I said they should shut up until we have a story picked. We’re gonna talk, kids. We’re gonna talk, and it’s gonna include design ideas. We need that burble of ideas and insights before we even pick a story, after all. That’s fine. What I’m saying is, don’t take it very seriously. Sketch this, poke at that, look this up, schmooze it all over. That’s fine.
But design that specifies changes at the code level in any detail at all waits until the story has been chosen. You start when you have a story and you’ve decided to implement it.
Stop When You’re Excited BUT Nervous
When to stop: when you are at the place where you feel excited that you’re probably right but nervous that you might be wrong.
This surprises a lot of folks.
People who’ve dabbled in this movement will have encountered a great deal of railing against “Big Design Up Front”, and they think that means there’s no designing allowed. They’re surprised I encourage us to design at all. Relax. The method works for you, you don’t work for the method.
People who’ve trained and worked their entire careers old school, on the other hand, think that this is way too little design. One hears the word “cowboy” among the epithets. Relax. We’re not done designing, we’re done pre-code designing.
“Hey. I think we got it.”
That’s the sweet spot for stopping the pre-coding design. Notice that “think” isn’t “know”.
If You Pass The Big Black Bulldog With The Droopy Eye…
Let me throw out a few “too far” indicators, so you can get a feel for that sweet spot to start with. If you pass any of these points, you’ve gone too far in your pre-code design:
* you think all the thinking is done.
* there’s zero risk.
* you’re so detailed there’s a program that could just translate it directly into code.
* you can just send all the lesser lights out to type it in.
Right? If you see one of those droopy-eyed bulldogs you’ve taken that pre-code design too far.
Keep Going Past Where The Dairy Queen Used To Be…
Well, if we’ve got “too far” indicators, let’s look at some “not far enough” ones.
* you have no idea what files/modules/objects are likely to change.
* you are terrified it won’t fit in a couple of days.
* you don’t know how you’ll respond to a generic failure in the new functionality.
* you don’t know how you’ll enable/disable the new functionality.
When you hit the keyboard, you want just enough to make you feel you know where to start typing. Don’t worry that you haven’t done enough thinking. You haven’t, and that’s the correct situation to be in.
Hey, That’s A *Feeling* Not An Algorithm!
Yes. It’s a feeling, not an algorithm. (The force is strong in this one. <cue eye-roll>.)
There’s no computable algorithm for determining when you’ve done enough design. Very intelligent bozo’s have been trying and failing to find one for quite some time. Or, maybe there is one, maybe one exists, but it doesn’t matter because we don’t know it yet.
And before you bemoan this too much, try to remember: the current non-computability of the software design problem is why you aren’t on the night shift at 7-11. Or hiding from SkyNet in the rubble.
So you’re going to have to go with your gut.
Collaboration May Be Called For
The decision point will vary from one context to another, depending on factors including but not limited to: codebase knowledge, mad geek chops, domain knowledge, really offensive arrogance, number of eyeballs, most recent collossal failure, etc.
In a collaborative situation, people will disagree about their gut feelings. I’ll offer a pro-tip: don’t disrespect folks who are less confident than you. Find a 50/50 compromise, then bias it a little towards the nervous side, and do it explicitly and openly and cheerfully. The time difference isn’t that significant. Good nervous cheer from your pair is very significant.
(On the other hand, I usually resist compromising with corporate handbook nervousness. I especially target here company-wide design rules, which are nearly always borked beyond any ready solution.)
Is That All The Design We Do?
Of course not.
The stopping point above isn’t the stopping point of design, far from it. Remember, we’re talking here about pre-coding design.
When we say we’re ready to code we most definitely don’t mean we’re ready to not design. The real design is just heating up, in fact. All through the implementation process we will be making further design decisions.
The fear is that we haven’t done enough thinking to really solve the problem.
The reason we have that fear is because that’s the situation: we haven’t done enough thinking to really solve the problem.
But I’ll let you in on a little secret. Thinking is done with thoughts. Really solving the problem is done with code. You will never really solve the problem by thinking, you will only ever really solve the problem with the code.
That doesn’t mean we don’t think. It means we think enough to code, then enter a tight little cycle of code-think-code-think-code-think.