How much time do you spend on design before coding? [duplicate]

Question

This question already has an answer here:

• How much design to do first? [duplicate] 4 answers

In my experience, it is useful to spend a little while sketching plans for a project before getting into code. Such planning usually includes choosing frameworks/tools, writing requirements and expectations, and doing mockups.

I usually only do this for serious projects though, not so much for one-off or short-lived attempts.

I'd be interested to hear how much time you spend on planning/designing projects before starting to do the coding. Do you do it for every project, or just the "serious" ones?

Answer 1

It depends greatly on the project.

If the project is based on a specification that has been already written (e.g. a binary data file specification), then there may not be much design involved.

If the project is highly speculative or research oriented, I might spend more time writing throwaway code to formulate a design than I will on creating a design up-front.

If the project is a large one, it will need more up-front thinking about high-level architecture.

Answer 2

As Much As It Takes

to understand the project, the model, the risks, and the unknowns

especially the risks and unknowns

Answer 3

We use Scrum at my job, so I would say at a minimum you have to give enough design thought to break down your user stories into tasks. You need a pretty good idea of what's needed to write tasks. Remember that the key is to write them so someone else could theoretically do the implementation. I usually fold the little details (e.g., which algorithm to use) into the time estimate for my tasks. If I need to do some no-kidding research, I'll make that its own task.

When dealing with an Epic (a project that lasts multiple sprints), I'm a lot freer with what I call "design." Design in that case usually involves a rough sketch of the basic architecture and a handful of user stories that I expect to do. It's not cowboy coding, but it's not a rigorous design process (think traditional waterfall model) either. Something will come up (a requirements change or an a-ha moment) that changes the game somewhere down the road. I try not to invest too much time in something that will likely get thrown out or heavily modified.

Answer 4

The famous Jamie Zawinski said in the book "Coders at Work" something along the lines of... It's better to spend just enough time in order to be able to code something we can use, then go from there. Depending on the project and competition, if you spend TOO much time planning and thinking of THE best way to do something and don't have a working product in a given time frame, your competitors will be ahead of the game and it will be a huge loss.

I don't necessarily agree with it though, but you've got to give him credit for what he's accomplished.