6

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?

Grant Palin
  • 1,721
  • 2
  • 14
  • 28
  • possible duplicate of [How much design to do first?](http://programmers.stackexchange.com/questions/115282/how-much-design-to-do-first) and of [What to plan before starting development on a project?](http://programmers.stackexchange.com/questions/69215/what-to-plan-before-starting-development-on-a-project) – gnat May 21 '13 at 21:08

4 Answers4

3

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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
1

As Much As It Takes

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

especially the risks and unknowns

Community
  • 1
Steven A. Lowe
  • 33,808
  • 2
  • 84
  • 151
  • 1
    Disagree. Even the best plans usually don't survive first contact with Other People's Code. There's nothing wrong with up-front planning, but there are lots of things that happen over the course of a real project that you can't plan for. I think it's important to get your hands dirty. Learn those quirks while you still have time to deal with them. – Michael Kristofik Dec 04 '10 at 02:27
  • @Kristo: I agree, which is why I said 'as much as it takes'. When you reach the point that you know what you don't know, and you have identied the major risks, it's time to start prototyping. – Steven A. Lowe Dec 04 '10 at 04:29
0

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.

Michael Kristofik
  • 1,503
  • 9
  • 15
0

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.

chiurox
  • 1,498
  • 12
  • 17