5 ms·
I get where Jeff is going with this post, and I agree and disagree. It may seem like splitting hairs, but I find a big difference between details and decisions.
by jroseattle 14y ago
I get where Jeff is going with this post, and I agree and disagree. It may seem like splitting hairs, but I find a big difference between details and decisions. My version: your app is a collection of decisions.
The details (and implementation) of an app flow from those decisions. Include or exclude a feature? That's a decision. Buttons on the left/right, top/bottom? Decision. Add a pluggable architecture? Decision.
Look at a rather successful product like the iPhone. Much of its success can be traced to getting lots of details right. But understanding what was going into the iPhone -- the decisions made about how to create it -- led to those details. Touchscreen, app store, glass cover, all of it were active decisions.
Executing details are absolutely critical, but making the decision of what to do (or not to do) is where it all starts.
- hellerbarde 14y agoThat is a very good point, coming from the developer's view. I think that Jeff's point is more valid if you look at it from the customer's view.
- jroseattle 14y agoA great clarification as well. And a customer certainly is not going to be aware of the decisions made around trade-offs, direction, etc.
- amirmc 14y agoAnd from the customer's point of view, the first product did the single most important thing properly. Feed the cats with minimal human input. That's still a decision on the creators' part i.e the creators could have sat down and bickered about colour options but they (presumably) took a decision to fix the customer's problem. The fact that Jeff used the same feeders for five years is a testament to how well the original designers were able to address the core problem well enough. Edit: They also functioned well enough that he bought the updated version on faith.