
Ignore details early on - mh_
http://37signals.com/svn/posts/3387-ignore-details-early-on
======
jcoder
> (Reprinted from Getting Real, The smarter, faster, easier way to build a
> successful web application.)

So, 37s turned a bunch of blog posts[1] into a book[2], which they are now
turning back into blog posts[3].

[1]
[http://37signals.com/svn/archives2/getting_real_ignore_detai...](http://37signals.com/svn/archives2/getting_real_ignore_details_early_on.php)

[2]
[http://gettingreal.37signals.com/ch04_Ignore_Details_Early_O...](http://gettingreal.37signals.com/ch04_Ignore_Details_Early_On.php)

[3] <http://37signals.com/svn/posts/3387-ignore-details-early-on>

~~~
rednukleus
You have to admit, It's quite clever really.

------
edw519
This is great advice as long as you know the difference between a detail and
an issue. They are often easy to confuse.

Detail: What font should we use on the payment page?

Issue: Should the customer's credit limit be for our division or for the
entire company?

Ignore the former and make faster progress.

Ignore the latter and be prepared to redesign your database and rewrite your
app if you made the wrong choice.

~~~
notimetorelax
Exactly what I thought. If you're designing backbone of your application then
being sloppy can be very expensive in the long run. Of course you still need
to see the difference between essential elements and those that can be tackled
later (usually parts of functionality that have nothing depending on them).

Personally I find it very hard to do software design on initial stages of a
project. It is similar to deciding on the laws of chemistry when building a
tree, if you chose wisely it will grow naturally, if you make a mistake
project completion may become impossible.

------
summerdown2
I'm not sure. I think this ought to be correct, but in practice I find it
often isn't.

The more I try to write fiction, which I think follows the same creative
process, the more I find each piece of work needs its own method for
development.

Sometimes the shape of an idea comes first and the task is to trace its
outline, but at other times an idea will accrete in the process of writing,
and the important thing is to edit it into being.

Maybe some web designers really do need to figure out the font in order to
work out what they are trying to say.

As usual, Neil Gaiman describes it best:

[http://neil-gaiman.tumblr.com/post/39857822411/what-do-you-t...](http://neil-
gaiman.tumblr.com/post/39857822411/what-do-you-think-about-the-idea-of-not-
editing-while)

~~~
hatu
As a game developer, when making a new game, I will only focus on a few
details that might seem small but if they don't turn out the way they were
imagined, the game just will never work/feel right. Just like someone might
need to see the right font on the page to see how it all ties in together, in
games sometimes I just have to have a pretty polished reference animation for
a character to tell if the controls are going to work.

------
calinet6
This is the design equivalent of "Don't optimize prematurely."

If you optimize too soon in programming, you could run into all kinds of
pitfalls. You might make the wrong thing efficient; you might spend a ton of
time making the right thing efficient and then not use it; you might make
something too complex by accident and it could screw you later on. So you wait
to optimize.

You make the simplest solution that will work first, then optimize later, if
needed. Often it's not needed.

The same _should_ go for design, as it's an excellent fundamental principle of
creation in general. Don't prematurely optimize: in other words, don't make
things too complicated, too soon. Don't build something up before you have all
the information. And don't build things you might not use until you know you
need them. All good general rules of thumb, and they apply to all your work.

~~~
zxcdw
Somehow you seem to assume that optimizing code would lead to complexity. From
personal experience I would argue that often the code is actually clearer and
more readable after it has been optimized. This is because great care has been
put into it -- it's not just written and left at that, but it has been
refactored with speed in mind.

Though my experience is mainly in C and C++, I guess it can be different in
dynamic languages.

~~~
calinet6
There's a balance. You have to optimise to some degree (writing blatantly
poorly designed code is just silly), but you shouldn't _over_ -optimize. To
me, that's sort of implied in the word 'optimize.' You should start with a
good design, that's well-thought-out, and you should reduce it to the simplest
and clearest possible concept, but you shouldn't go overboard until you know
the path.

------
senorprogrammer
Excellent points. Personally I find early detail obsession to a be a red flag
about my own behaviour.

As a developer when I notice myself re-tweaking about what shade of green to
use, what perfect image to put in place, or what pixel size of font to use, it
means I need to walk away for a bit. I've burned out for the moment on the big
issues that need to be done and am just fooling myself with inconsequential
work in order to maintain the feeling of progress.

------
locacorten
I find it sad when clueless people end up well-rewarded. It leads to articles
with terrible pieces of advice, such as this one.

Anyone who pays attention would notice that things that work well are always
built by people who pay attention to details.

~~~
krautsourced
Sure. Only that's entirely not what the article says. It says not to focus on
details _too early_. Because while the entire team may (or may not) agree on
the general idea, getting into the details at the same time will take _much_
longer, with very little gain (since that early in the project it may not even
be sure if that detail will even be relevant later on). Get the rough ideas
sorted out first. Then chip down, iteration by iteration. Finally, get to the
details (and then it's time to pay attention to those).

~~~
locacorten
On surface, you're right.

However, I've never encountered a person who pays attention to details and can
switch this on or off, depending at which stage the project is in. You either
care about details (and you can't help yourself), or you don't.

When you are good but don't pay attention to details you end up with things
like ... the Facebook website. You make a million bucks by some random chance
and then you start writing crap articles like this one. And then all the cool
under-30 kids start worshipping you.

~~~
thisone
Give someone a project where there's not enough time to nail down every detail
and complete the project.

Either they fail by not producing a working product, they learn to prioritize,
they burn themselves out and get it done to their standard, or they quit
because they can't accept that sometimes deadlines matter more than details.

------
SatvikBeri
The process of creating a great [novel, product, presentation] is iterative.
You create a first version. It sucks, you find obvious flaws, and you make a
few passes through editing it. Then you show it to other people and get more
feedback. Repeat.

The advantage of high-level, low-detail [outlines, prototypes, sketches] is
that you can find a lot of flaws without doing all the work, and iterate
faster. It sucks when you have to scrap 3 weeks of code because there's a
fundamental flaw in your architecture. It sucks even more when you have to
scrap 5 years of work because you built something nobody wanted.

Novelist Rachel Aaron started writing 5 times faster and with higher quality
(at least according to Amazon) through extensive use of outlines[0].

Now, the high-level outline will never be 100% accurate. As you dive into
details, you'll realize that there are flaws and you need to change your
design. That's okay. The point is to go with the approach that helps you
improve faster than anything else. If you're writing a new feature for your
app findthenearesthotdog.com, the right iteration loop might be idea -> 15
minutes on a whiteboard -> code. If you're creating software that has
interface with 17 different legacy systems from hospitals with administrators
who think web apps are made by spiders, you might want to go idea -> talk to
customers -> talk to lawyers -> draw up diagrams, get approval -> write up 500
page spec, get approval -> code

With the product you're building, figure out which source of feedback
(yourself, customers, friends) and which level of detail (code, specs,
whiteboards) will help you improve fastest, and start there.

[0]: [http://thisblogisaploy.blogspot.com/2011/06/how-i-went-
from-...](http://thisblogisaploy.blogspot.com/2011/06/how-i-went-from-
writing-2000-words-day.html)

~~~
xxpor
This is something I've noticed about Amazon. The first version of things they
come out with generally suck (See: Kindle, Kindle Fire, a lot of AWS
services), but they iterate like hell. Everything is rapidly improved every
iteration.

This is opposed to Google, which tends to throw something out there that's
pretty good to begin with, but once it's released it doesn't get much support
and dies. Also, Google's (hosting) services tend to get more expensive, AWS
always gets cheaper. I think it says a lot about how each company works.

~~~
SatvikBeri
If you view the loop as:

Creator(s) -> Product -> Creator's feedback -> Consumer's feedback

Google seems to have heavy focus on the "Creator's feedback" portion, while
Amazon has heavy focus on the "Consumer's feedback." That's why Amazon will
release crappy v1's. This is basically the same as the agile development
philosophy: orient your process to get external feedback as soon as possible.

------
Shank
I agree, though it's borderline "ship fast and break things" mentality. It's
the difference between shipping a product with a great solution to a problem
or waiting to ship because you want to make the entire thing configurable from
the ground up.

It's much better to ship an early product with not much customization in a
prototype/alpha/beta phase and get immediate feedback on what's truly
important before arbitrarily deciding for yourself what's needed.

------
programminggeek
I use this process when I'm building things with
Obvious(<http://obvious.retromocha.com>). The web and the db are details.

Building this way lets you fill in those bits when you need them, but you
don't spend a bunch of time being tied to a particular framework or database
infrastructure until you need them.

What is cool is once you start decoupled, it is easy to stay decoupled and the
details can stay that way.

------
brennenHN
I think the real point is to know which details to focus on, and getting
distracted by the less useful examples here makes that case pretty strongly.

If you ignore details altogether, though, you're probably going to miss
something important.

------
whichdan
I'm guilty of this, and still debating redesigning my landing page without
having enough traffic to even properly A/B test the current one.

