How do you know when it's time to stop staring out the window... and start coding?
The department had been given a new project. It was a bit like earlier projects, but had a few unique needs that made the application interesting. On the plus side, the software was built using the same framework that the team was used to. So the developers interviewed the users, gathered requirements... and that's when things went astray.
Maybe.
One journeyman developer — I'll call him Paul, though names have been changed to protect identities — immediately gathered his tools around himself like a security blanket, and started writing code. His more senior colleague (whom I'll call Leo) took umbrage at this.
"You haven't thought this through," Leo told Paul. "There are a lot of ways we could address these needs. You thought of one, and you didn't consider whether another approach would be faster, or easier, or more robust. Or anything."
"But this works," said Paul. "I can always refactor it."
Perhaps Paul can. Perhaps he chose the best option (purely by luck). But Leo feels that Paul saying he'll "refactor" the design is an excuse for not-designing in the first place — throwing code against the wall and seeing what sticks. He believes Paul's "dive right in" approach is laziness that will eventually trip him up, and as a result will probably delay the team (and the project). It's one thing to re-think the way you wrote something, says Leo, but another to re-design a building after the foundation is poured.
Leo credits Paul's (and others') too-short design-time to early school training, when we were all criticized for "daydreaming," though the ability and willingness to daydream is a critical skill for anybody in a creative field. Leo himself says he spends at least 30% of his project-time creating the design before he starts to create the application; he tries out several designs in his head before he decides which one is right. Perhaps he expects others to do the same thing.
I don't think there's one right answer. Some people do design on-the-fly. Others construct an entire application in their head before they put hands to keyboard. I have a tropism to the latter mode myself, or at least I have learned to recognize the signs for when I've reached the end of my Research Phase and am ready to write. (My "notes" begin to look less like bullet points and turn into sentences, then paragraphs.)
When I began thinking about this scenario, I started to put together a poll to ask you about the amount of time you spend on design, and a second one to ask how much your time you wish you could spend designing applications rather than writing, testing, or (ick) in meetings. But I could never find a way to phrase the question.
First, you might not identify your design time as such. When you're at your most creative, you probably aren't thinking about the process. Mihaly Csikszentmihalyi's Creativity: Flow and the Psychology of Discovery and Invention goes into marvelous detail about "getting into flow" (the same process that Peopleware addressed by explaining the sin of calling a programmer on the phone, because it takes at least 15 minutes to get into a warm creative zone again.) Many of us get our best ideas in the shower, while riding a bike, driving. (Csikszentmihalyi offers an explanation why.) Design doesn't happen when you sit down at a desk with a pad of paper and a sharpened pencil, so how could I ask how much of your time is devoted to it?
Plus, the percentage of time you need to devote to designing one project isn't related to the time you spend on another. Not every application requires earth-shattering innovation. A smaller application probably (not always but probably) doesn't require as much design time as a mission critical corporate SOA project that touches every corner of the enterprise.
So then I thought I'd ask whether you felt that on a typical project, you spent enough time on design. But that doesn't work, either. Paul would say Yes, he spent enough time designing his software; Leo would object strenuously.
So much for the poll. But I think you know what I'm trying to get at: When do you know you're done with the design? By which I mean "the design for this piece;" if you use Agile, you're probably ready to tell me that you don't try to design everything up front. (Yeah yeah, I know.) But at some point you do stop staring out the window, and you reach for the keyboard. You're ready. How do you know when that happens? And how much of your time do you spend designing... at least compared to the other developers you know?
You probably should follow me on Twitter. Because, y'know, you just should.
This story, "When Do You Have "Enough" Design Time?" was originally published by JavaWorld.