Design first, then code.(emilhajric.wordpress.com)
emilhajric.wordpress.com
Design first, then code.
http://emilhajric.wordpress.com/2009/08/09/design-first-then-code/
10 comments
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).
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.
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.
I disagree, if not a visual design, then a design for the code itself is needed- well, it's needed for big enough projects. If one were to skip planning out the project and how to code it, one could easily mess up whatever protocol system there is an just code the entire system poorly. Sadly I did this once! I coded the entire thing, and it worked. No plans, no designs, no nothing- one bug, and the entire project was ruined because I didn't plan ahead and design my code to be flexible in the least. Basically what I am saying is that if I had taken a minute to plan it- I would never have had to rewrite LOTS of code. It's always a good idea to design something before coding, a visual of the project helps and the actual code structure outline helps.
Moral of the story: Always have a design up front. I didn't have a design so the structure of my code was incorrect for the "visual" the other person had in mind, so it broke. If that visual is solid, especially when working with/for another person, then fewer mistakes will be made down the road.
Moral of the story: Always have a design up front. I didn't have a design so the structure of my code was incorrect for the "visual" the other person had in mind, so it broke. If that visual is solid, especially when working with/for another person, then fewer mistakes will be made down the road.
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://www.featuredrivendevelopment.com/node/507
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://www.featuredrivendevelopment.com/node/507
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.
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.
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.
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.
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.
#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.
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".
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".
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.
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.
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?
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?
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.
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.
Graphic design.
Yeah, it looks like it. So the article is poorly titled and poorly worded in that respect.
Yeah, it looks like it. So the article is poorly titled and poorly worded in that respect.
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.
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.
This was a tenet of the 37signals book "Getting Real"
see: http://gettingreal.37signals.com/ch09_Interface_First.php
see: http://gettingreal.37signals.com/ch09_Interface_First.php
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.
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.
"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.
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.
I don't think this is an argument for upfront design. Rather it's an argument for thinking about what you are doing.
But... that's not agile!
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.
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.
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).
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.