Design before you code

[Brutha]

If you want to write code for a program, what do you do before you start coding?

How much design specs do you write before you start writing the program?
How formal are those design specs?

[pianoperformer]

I work with the client (or myself if it's my own project) to get the user stories, and get a priority on each one. Each story is in the format:

As a [role]
I want [feature]
So that [benefit]

I put each user story into a .feature file (for Cucumber).

Every two weeks, I choose the user stories I will work on in that time, and expand them into scenarios, in a given/when/then format. Again this is supported by Cucumber. This should really only take a few hours of planning.

That's all of the up-front design there is.

I then go to the first scenario I want to code, and just code it. I start from the outside in, working on views first, then the controllers, and finally the models. it's small vertical slices of functionality. But of course I never write code until there is a spec in code to implement it (kind of like tests but thinking about behavior instead of tests). I use RSpec for this. Each layer is tested independent of the other layers. The layer below it is mocked so as to provide that independence.

Once you start writing tests/specs before code, you will never want to go back to designing everything up front, coding, and then testing. That is entirely backwards. Testing before gives you much more assurance that what you are writing actually is what is needed, that it works, and that you have the minimal and simplest code required to make it work. There have been times I had no idea how to design a certain feature, but I just jumped in writing one test, code to pass it, another test, etc, until before long, a design was evident that worked really well.

[Dharma]

I try to get all the specs I can and maybe the ideas they have for the future (so I can write the code loose enough to accept changes).

In thinking of code, I look to where I can reuse code, objects, and processes. Do I need to care about performance? Do I need to make a huge DB and worry about it's performance and efficiency? Multi-lingual? If it's a web app, how much data am I dumping on the user's browser? Am I gonna make low performance machines/56k/iPhone/PDA users crawl?

[pianoperformer]

Dharma,

have you ever looked up extreme programming? Have you ever heard of the red/green/refactor cycle? This article has a good description, too.

The basic idea is that you only test and code whatever feature you are working on right now, and don't plan for future features, because, YAGNI ("you aren't gonna need it"). Your tests describe your scenarios/features, and you only code the simplest thing that'll possibly work.

Further, premature optimization can be rather dangerous.

[Dharma]

Yes, I know all about it and I like XP. But, my job is to look into the crystal ball and know what bomb (features!) my customer will drop on me later in the project. Always happens. In a way it is also an efficient model too.

[Brutha]

I try to get all the specs I can and maybe the ideas they have for the future (so I can write the code loose enough to accept changes).

You mean you asked somebody else for the specs or do you write specs yourself to have a more concret idea of what your code has to do?

[CubicleBailout]

Who is going to do the coding? If it is just you, then your spec could be the code itself and maybe some diagrams of how it will all work together.

Do a work break down structure or create a backlog of user stories (really the same thing) of what the software will do at a high level.

Don't waste time on specs if you don't need to (i.e. coding for yourself).

Oftentimes, I'll create basic file structures for code and put todo lists in there as well as why I'm doing something the way I'm doing it. This goes a long way when you are staring at that same code months later and have forgotten why the heck you wrote it.

[vilbara]

At minimum, you should write down in simple words what you think your application will do.

Just start writing and soon you will notice questions poping up in your head. Write those questions down. Analyse and answer them.

At the end you will get some specification but this is not the most important. The most important is the act of planning and the insights you've got.

Changing specification takes just a fraction of time you need to change code.

Read Joel Spolsky: Joel on Software

He has written a series about specifications:
Painless Functional Specifications - Part 1: Why Bother? - Joel on Software

[jamestl2]

Yeah, simply getting the goals of the program down are where I first start, and ask myself what purpose will this serve Wll I expand on it in the future? Just how flexible does it need to be?