There’s a lot of talk about how important details are. But what’s often left out of the discussion is timing. Details and timing are intimately related.
God, the devil, beauty, perfection, precision – these aren’t the only things you’ll find in the details. You’ll also find stagnation, disagreement, meetings, and delays. These things can kill morale and lower your chances of success.
How often have you found yourself stuck on a single design or code element for a whole day? How often have you realized that the progress you made today wasn’t real progress? This happens when you focus on details too early in the process. There’s plenty of time to be a perfectionist. Just do it later.
Don’t worry about the size of your headline font in week one. You don’t need to nail that perfect shade of green in week two. You don’t need to move that “submit” button three pixels to the right in week three. Just get the stuff on the page for now. Then use it. Make sure it works. Later on you can adjust and perfect it.
Details reveal themselves as you use what you’re building. You’ll see what needs more attention. You’ll feel what’s missing. You’ll know which potholes to pave over because you’ll keep hitting them. That’s when you need to pay attention, not sooner.
(Reprinted from Getting Real, The smarter, faster, easier way to build a successful web application.)
Ninja
on 07 Jan 13I like it – can apply to lots of things not just website design.
Fernando Nava
on 08 Jan 13“The key to Understanding complicated things is to know what not to look at, and what not to compute, and what not to think.
One of the things we have to learn how to do is ignore details.”
- Abelson and Sussman, Structure and Interpretation of Computer Programs (1984)
Sorel Mihai Arghire
on 08 Jan 13I would say just don’t execute details early on. But ignoring them completely isn’t that good either. Details both depend on and influence the big picture. Is a cycle. So think the details while working roughly, but work on them only at the end, as they might change on the way.
Javier
on 08 Jan 13I think more or less like Sorel. Sometimes postposing details means that we will never focus on them, even when it’s time to.
There’s wisdom on letting them for later on but also on knowing when the moment has arrived and execute details even if our main work has already been done.
John
on 08 Jan 13Ugh, this post came at a perfect time for me. I’ve been working on Model-View-Controller all day wondering which component should fire which event and which one should capture it. I’ve been stressing over placing a getter here and a setter there. It’s burning me out. None of it matters compared to getting something in front of people. None of it.
helpermethod
on 08 Jan 13Reminds me of ‘Make it work. Make it right. Make it fast.’ (Kent Beck)
James Zhuo
on 08 Jan 13Very good post and always a good reminder. Though if you are in the business of custom software development, you’ll have to think through a lot of details upfront. The customer expects a legally binding document that can be signed off and a fixed price to go with that. You as a vendor wants to make sure you are covered as well.
Chris Meeks
on 08 Jan 13Totally true. This is a struggle with most projects because we still aren’t at a place where most designers feel comfortable refining core design details entirely in CSS. We still prefer the absolute control of every pixel that Photoshop provides, and too often use a flat document as proof of our design’s mettle.
Jamie Hill
on 08 Jan 13I blogged about the exact same thing from perspective just before Xmas, weird: http://thelucid.com/2012/12/19/embracing-perfectionism-as-a-long-term-goal/
Jamie Hill
on 08 Jan 13I blogged about the exact same thing from another perspective just before Xmas, weird: Embracing perfectionism as a long term goal.
Jamie Hill
on 08 Jan 13Sorry about the double post, you can delete the first if you like… and this.
proctime
on 08 Jan 13nice rehash, pressed the “easy” button, just kidding – always good to remember these ideas in the crush of daily info
by the way, are you planning to redo this blog design? the old design was old, yes, but much more readable and made it a lot more fun to come here, this new whitewashed “less is more” giant-size type center-river design is atrocious, seriously. nobody has noticed that? I can’t come here as much as I used to – maybe if I was on my phone or an iPad this would be Ok, but not on my 24” iMac or even my 13” MacBook, just atrocious, please change this to something else, no offense BTW you are an inspiration, this is just some push back, I welcome change but this seems like a bad change
Jon
on 08 Jan 13Thanks for the reminder….. Perfect timing for me as well
Rob
on 08 Jan 13I love the concept behind this post. The details truly are what bogs the process down. As a branding firm, we go through this process all of the time. When dealing with client’s actual brand identity, they want all the details – all the time. We do our best to keep our cards close to our chest when we formulate their brand strategy and only disclose the details when we’re ready to unveil our artwork. This typically works really well to keep clients distracted and happy with awesome art while discussing the details that they would otherwise nit-pick to death. They’re much more likely to accept the whole, when they receive the one element they’ve been waiting on for so long.
Pym
on 08 Jan 13Can we find an epub (or mobi) version of Getting Real somewhere?
Andrew
on 08 Jan 13While I think very few would disagree with this post on a basic level I think many would disagree on the definition of these “details”. What may be a detail to one might be an important aspect depending on our experiences and understanding of the market. How do we determine and agree one what is a “detail” and what is bigger problem is a better question.
Simon
on 08 Jan 13Yet sometimes going into deep details allow you to really resolve an issue.
protected static
on 08 Jan 13“None of it matters compared to getting something in front of people. None of it.”
Until it does, usually when you’re the maintenance programmer. Or when your proof of concept becomes a production app “because it works fine now!”.
John
on 08 Jan 13@Andrew: My definition of ‘a detail’ is anything that prevents you from meeting your immediate goals.
@protected static: Your point shows where the distinction lies. The danger many programmers face is never putting out a proof of concept at all because of analysis paralysis. My point, and the point of this post, is that you should favor any sort of usable proof of concept well over a maintainable codebase that no one uses.
Antonia
on 08 Jan 13The truth is, we forget things more than we think we do. A detail that you ignore early on, could be the back breaker later on in the project.
Programmers tell me how much they suffer when details are forgotten about and when the application goes live, heads start to roll, especially their heads.
I generally agree with the ideas behind the post, however every project has to be dealt with according to it’s context and with balance.
Cheers
Eryn
on 09 Jan 13Excellent timing for me (as for a few other commenters). I’ve spent the last several weeks buried in the tiny details of a project I’m working on, which has really stopped me from getting anything (really anything) done.
The wisdom, of course, lies in balancing “get it done now” with “polish and perfect”. I suppose that’s a skill that only comes with time and experience.
Dave
on 09 Jan 13I love this post. Like others, I’ve been really thinking a lot about this, and I think it really comes down to constantly asking yourself whether what you’re currently doing is absolutely essential in helping you to push ahead in your project. For example, I think Google’s testing of different shades of blue was a complete and utter waste of time. I can’t believe they wasted so much time testing 40+ shades of blue. I wonder why they couldn’t just pick a color and move on.
Anyway, I, personally, have fallen prey to trying to do too much at once (I go into depth about this here: http://www.thisisdavekim.com/getting-sidetracked/), and I think the key is to be laser focused on what you’re currently doing. And I’ve also realized that to keep the momentum up while developing a project, the trick is to figure out which things you should build yourself and which you should look for existing solutions. I don’t think there’s much utility in reinventing the wheel if it’s not a core part of your project.
Juzer Ali
on 09 Jan 13Very pertinent for me at the moment, sadly :(
nick
on 12 Jan 13This philosophy has worked for me at times, and also by not following it my progress and feedback have not been as good.
However, you have to be careful with “pot holes”. Sometimes you get used to stepping over them and forget how off-putting they can be to users.
As always, it’s not black and white and there’s plenty to think about.
Jakob
on 14 Jan 13I’m with you, I understand what you’re saying and why…... There is a but however (which is probably the whole cause that people get stuck in details) which you may have a hint for: how to prevent creating code today, that just works, but that is not flexible enough to put in the details at a later time. You’ll going to have to need to know in advance which details you’re going to need, in order to create code that doesn’t need a complete rebuild once you figure out the details…....... hence the discussion in advance
Shazad Rehman
on 14 Jan 13Yeah, I agree. Just thought the article’s title may of read better if it was “Ignore perfection early on”
This discussion is closed.