
How to design perfect software products (2013) - bdon
http://hintjens.com/blog:19
======
gfodor
One problem with the meme that building products is about "solving problems"
is that the biggest successes often come from recognizing very vague
"problems" others don't, in the form of seeing fundamentally better ways of
doing something -- without being able to grasp up-front the long term concrete
benefits. You need to build and ship to learn them. So in those scenarios,
people don't recognize what you are doing as a "real" problem, so it ends up
being hindsight bias when it's recognized as such. An example in the article
cited was Wikipedia: Wikipedia didn't "solve a problem" with existing
encyclopedias, it recognized there was just a fundamentally better way to
collect objective knowledge and disseminate it -- most people at the time were
scratching their heads about what the point was, since from their perspective
encyclopedias worked perfectly well within the scope of their design goals.

I think the mental model that you should always be working on software where
you have people directly telling you the problem they want to solve is a poor
one -- it's great for a variety of domains, but often people want a faster
horse or don't even see a problem with their existing horse. Even when you
think you are recognizing a problem others don't see yet -- it can require a
leap of faith to begin exploring to see if you can iterate and react to
discovering something with big promise.

------
stolee
The comparison to hill-climbing algorithms is an interesting one, especially
because the author ignores the fact that hill-climbing algorithms get stuck in
local optima unless there is a way to “restart” the search from a new
location. There is a time and place for big, risky changes to advance beyond
what this “patch” approach can do.

~~~
anbop
I think this is what happened to Amazon. A series of locally optimized
decisions like commingled inventory and 3rd party sellers that has turned the
site into a used car dealership in some categories.

------
ncmncm
The rarest skill, even in highly intelligent engineers, is to be able to
imagine the world after a thing has been changed, and see what will matter to
people then.

Everyone else (including you, most likely) can only see the change itself. Is
the change pretty? No awareness at all of whether the product after the change
is nicer than the present product.

It is a skill that can be developed, but it takes focused attention. The end
result is to see how to alter the change to make the end result better to use,
not just a thing with another PITA feature.

------
revskill
What people failed to define themselves is "Simplicity". That concept
"Simplicity" needs context.

Is it API surface simple ?

Is it data model simple ?

Is it Lines of Code short ?

Is it extensible with small core and huge plugins system ? ...

Is Wordpress simple ? Is MERN simple ? Is Rails simple ?

There's no answer here.

That's it. There's no "absolute simplicity", it depends on context.

~~~
lucio
How many new concepts a new user needs to learn, and how many mental models a
new user must develop in order to effectively use your software. Twitter is
simple, Git is complex.

~~~
cheez
Git is pretty simple.
[https://github.com/git/git/blob/ecbdaf0899161c067986e9d9d564...](https://github.com/git/git/blob/ecbdaf0899161c067986e9d9d564586d4b045d62/ll-
merge.c)

~~~
dreamcompiler
Git is one of those rare products whose internal implementation is simple but
whose user interface is a complicated mess.

------
externalreality
What is being described here is very similar if not identical to what can be
found in Agile software and lean software development books that gained
popularity in the mid 2000's.

~~~
mr_vile
well, it's definitely not identical

~~~
TheOtherHobbes
No it isn't. Agile _software_ development assumes management knows what it's
doing - which is often not the case at all.

Agile is primarily about managing down assuming a coherent goal exists - not
about finding the best coherent goal when it doesn't, or even about being able
to tell that it doesn't.

Agile _business_ management doesn't really exist as an established practice.
Although you can certainly find books, consultants, and all the usual noise
that use the term, the idea that you can recursively define your business
strategy - not your implementation - by solving the problems that provide the
best customer satisfaction at the lowest implementation cost isn't as common
as it should be.

The obvious complication is that the definition of "customer" varies. A
bootstrapped startup needs to focus on real income-generating customers.

A VC-funded startup is in a different market. The primary customers are
actually the VCs and other investors - not product users, whether they're
paying or not.

Pieter Hintjens is always worth reading, even though his "solutions" are
wildly oversimplified and contingent. Here he takes it for granted that
solving customer pain points should always be the primary value-generating
goal - which for better or worse happens not to be true, especially for
startups.

------
simplyinfinity
Can we get ( 2012 ) tag please

