
Design first, then code. - hajrice
http://emilhajric.wordpress.com/2009/08/09/design-first-then-code/
======
gdp
I'm not sure that "design" is necessary up-front. There are plenty of good
strategies for rapid application development. I think what _is_ necessary is
plenty of up-front _thought_, as in "why am I creating software?" and "what
does it need to do and why does it need to do that?", then you are in a much
better position to keep referring back to your original goals when making
design decisions during the implementation process (without committing to an
inflexible design should your needs evolve).

~~~
alabut
_I'm not sure that "design" is necessary up-front._

Most programmers aren't. And it's often a tug-of-war between designers and
programmers to gain respect for their roles: have a designer always come later
in the process and you'll get more of a limited traditional visual designer;
have one always come earlier in the process and hand down visual specs like
they're stone tablets, now you've got old school art directors from the Mad
Men era and programmers are treated like code monkeys (still mostly the case
at ad agencies today, actually); have one on your team that can design upfront
while doing usability testing to validate features, all on a tight schedule,
now you're talking about today's interaction designers, but they don't come
cheap and most startups have a hard time landing one.

------
StrawberryFrog
Should you design your entire app before you start coding?

You can, but that doesn't work very well. Part of the whole agile and test-
driven development movement is a rejection of that "waterfall" / "Big Design
Upfront" approach after seeing how it fails in the real world. Slogans like
"do the simplest thing that could possibly work" and "You aren't going to need
it" are there to stop you doing too much design.

Should you do design?

Of course. Slogans like "red, green, refactor" and "Don't repeat yourself" are
there to get you to think about program design as you code. Also doing a bit
of design thought before each coding task is good.

See also JEDI Programming - Just Enough Design Initially

[http://bradapp.blogspot.com/2009/07/jedi-programming-just-
en...](http://bradapp.blogspot.com/2009/07/jedi-programming-just-enough-
design.html)

<http://www.featuredrivendevelopment.com/node/507>

~~~
alabut
_You can, but that doesn't work very well._

Sure it does, just along a different metric - visual cohesiveness. It's a big
difference between design and programming - you can and probably should slice
off pieces of functionality to implement but doing that with design leads to
one of the biggest criticisms of designers within an agile/xp/scrum
programming setup: a frankenstein-looking interface.

There's a reason why "agile design" and "agile ux" is gaining steam as topics
amongst designers (especially startup-focused ones like me) and it's because
yes designing everything upfront is old school waterfall and clearly bad but
designing on the go with super fast iterations can lead to an ill-considered
spray-and-pray approach to the visuals. So we're trying to figure out a middle
ground where the designer isn't just following behind and applying polish.
That diminishes a designer's role just as much as it does to make a programmer
always come later in the process and treat them like someone that simply
implements what the designers make.

I'm not advocating an approach, just pointing out that there's definitely
positives to having design go first, especially if you do user-focused
research like running usability tests on mockups or paper prototypes. It'd be
great if you could flip flop back and forth from having design or engineering
drive the discussion and that's exactly the setup promoted in Bill Buxton's
Sketching The User Experience.

~~~
StrawberryFrog
The problem seems to be that "design" means two different things here - #1
User experience and graphic design, and #2 program architecture. I was talking
mostly about #2.

I agree that if you want a slick-looking app, you have to put some upfront
thought into #1 - maybe not nail down where every pixel goes, but establish
the metaphors, colour schemes, mock up some sample screens and so on.

~~~
alabut
Agreed that we agree - I limited the discussion to #1 because that's how the
blog post described it.

#2 is important as well, but honestly, I find that worrying too much about #2
upfront makes it too easy for coders to go down blind alleys and turn into
"architecture astronauts" as Spolsky would say because they're busy
implementing what's technically interesting rather than pure minimum needed to
make an interface work. And don't get me wrong, that's just as much a danger
for designers to go off into visual polish mode and get the interface looking
like lickable candy rather than making the bare minimum interface they need to
test with real users, whether with usability testing or metrics or what have
you. I'm definitely an advocate for both designers and programmers to
implement the smallest possible feature set they need to test their app or
site in the real world.

Speaking of which, I'm not sure the original blog author limited the scope of
their app either - they didn't explain how they define "success". I think it
might just be that the interface actually got made and photoshop files got
sliced up into html/css? That's a pretty low bar if that's the case.

~~~
StrawberryFrog
_I find that worrying too much about #2 upfront makes it too easy for coders
to go down blind alleys and turn into "architecture astronauts"_

I am still agreeing, and that's about where I came in. The words "Design
first, then code" are fighting talk to an agile software guy. But if you add
"but I meant graphic design not software design" I would say "oh... that's all
right then, I guess".

------
ThomPete
You cannot not design first, no matter if you are developer or designer or UX.

When I did the Nasdaq Market Replay app, we sketched out some of the vital
areas of the application, then tested to see whether they where viable, in the
meantime we went on to do the rest of the design and getting feedback from the
developers to see whether what we wanted was possible.

My personal philosophy is to design in the environment that we are developing
in as early as possible.

That way we don't have this blind tag team situation where designers mindfuck
and developers has to solve their mindfucks because the client approved them.

The agile process requires that all the involved are contributing all the
time.

------
StrawberryFrog
the author basically says "I tried to do X, and just got stuck into the code.
I failed. I started again, designing the entire User interface. After I was
done designing I started the coding. This worked perfectly. So do the Design
first and then code."

Maybe the reason that he succeeded the second time around was that he had
already tried and failed, and so knew where the pitfalls were. It's not proven
that design on it's own, without trying out some ideas first, is going to
help. Many people would say that it' doesn't. I'd say that big upfront design
without any reality checks can be a major hindrance later on when it turns out
to be impractical.

Also "designing the entire User interface" ? Is he talking about graphic
design or program architecture?

~~~
roam
Graphic design. But it looks like few are reading the article that thoroughly
anyway. ;)

I have to agree with the article up to a certain point though: creating
mockups helps me find out what I need to build. Of course, creating a graphic
design is something entirely different.

~~~
StrawberryFrog
_Graphic design._

Yeah, it looks like it. So the article is poorly titled and poorly worded in
that respect.

------
joshu
Bullshit.

You can design all you want, but you aren't going to take into account every
last interaction. You can only do this by reacting to a prototype or
implementation. Do some design, then some code, then react to the running
system.

The important bit is to get to the minimal running system so that you can
react to it.

This will also help you achieve conceptual integrity in your design; the
missing stuff that you never thought of will come to you.

------
dmillar
This was a tenet of the 37signals book "Getting Real"

see: <http://gettingreal.37signals.com/ch09_Interface_First.php>

------
azzleandre
hmm.. I'm not so sure if the author is right. If you're building one-time
projects, I think he's right. But if you are building large apps that are
constantly improved, you can't forecast what features must be added and what
features you must get rid off. So it's all about designing your code, in a way
that makes sure, that it's easy to change afterwards.

~~~
gdp
I don't think there's really such a thing as a "one-time project". It is very
rare that you would create a piece of software in its entirety with no
variation from your original design or conception of the software, and then
never revisit or change it. As soon as you start modifying or maintaining
software, you are in a position where your up-front design decisions may
hinder your efforts to improve or add features.

~~~
azzleandre
"and that's why you never ..." :-)

With one-time projects I've meant products like a micro-page that a customer
wants for some ad-campaign an then after some weeks have passed nobody will
ever visit again.

But I agree, anything more than that is destined to be modified one day.

------
tome
I don't think this is an argument for upfront design. Rather it's an argument
for thinking about what you are doing.

------
kungfooey
But... that's not _agile_!

~~~
DanielBMarkham
Assuming you're not making a joke, I think these things get blown way out of
proportion.

You're _always_ going to design before you code, even if you just take ten
seconds before starting to type your tests into the IDE.

The question is "how much design is too much?"

The reason we have to ask that question is that for some folks design is
supposed to eliminate all uncertainty and control execution. When design is
taken to this extreme, bad things happen. But bad things happen when no
forethought is put into work as well.

High-performing teams use design as a way of getting common understanding
about a general plan of attack on the problem domain -- which can include
things like initial data models. But the general idea is to do simple, easy
things repetitively. So whatever you do for design, make it something that's
easy enough to do every sprint. Perhaps that means an hour or two at the
beginning of each sprint -- perhaps a day or two. But thinking ahead and
getting group buy-in is always a good idea when there's more than just one of
you. Heck, it's a good idea even when there's only one of you. Good design can
try out and throw away ideas really quickly. Designing from code is a lot more
painful.

~~~
hajrice
Thanks for the feedback guys, I appreciate it. I agree with you Daniel, you
have a very good point. Although, I still think we should do the entire design
before we do the cause: a) It's very easy and fast to get feedback. b) You're
not creating any diversion with your team members. c) As a development
guide(if you have a status update going on in every page of the website,
that'll definitely make you think differently while developing the product).

------
hamidp
It seems to me that in this case the design is serving as a spec. If you don't
have any idea what it's supposed to do it's kind of hard to build it. Then
again, that seems rather obvious.

