Ignore details early on | Hacker News Reader

Ignore details early on

37signals.com

80 pointsmh_28 comments

Open articleView on HN

> (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...

[2] http://gettingreal.37signals.com/ch04_Ignore_Details_Early_O...

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

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

.. and, they still ignore detail in their content.

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.

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.

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...

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.

I do a lot of design work, and the little details often consume a disproportionate amount of time. I'll have a sense of what the icon, photo or color should be and I won't stop searching and testing until I nail the zeitgeist of it.

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.

I have found simplicity in design and thinking about performance to have a symbiotic relationship. Performance concerns prompt simplifications in the design, and simplicity in design uncovers new ways to improve performance.

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.

You could just as easily soend that time refactoring for code clarity.

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.

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.

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.

Not to mention terrible pieces of software. Every time I'm forced to use basecamp, I run smack into an annoying bug. I don't get the hype, really.

I had the same trouble. Just feels clunky. Fortunately they managed to use hype to offset it.

they need something to blog about

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).

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.

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.

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-...

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com