

You can always do less - _giu
http://37signals.com/svn/posts/2106-you-can-always-do-less

======
revetkn
"For every 1 day estimates of a task, there’s a simpler version of that you
can do in 3 hours, and an even simpler still you can do in 30 minutes. Back
yourself into a corner and these versions will vividly appear before your eye.
You can always do less."

I wonder if this was the reasoning behind 37s' storing passwords in plaintext
instead of taking an extra 10 minutes to write the code to encrypt them?

~~~
nwjsmith
Evidence?

~~~
tome
[http://www.jgc.org/blog/2009/05/can-you-trust-37signals-
with...](http://www.jgc.org/blog/2009/05/can-you-trust-37signals-with-
your.html)

~~~
nwjsmith
This is from May, and 37signals just made a fairly large change to their
authentication system (I think its called Launchpad). Their password recovery
system now works differently than described in this post, so I doubt they're
still storing them plaintext (thank goodness).

~~~
revetkn
Yeah, it may work differently now, but I think the point still holds. I
understand that engineering's all about tradeoffs and being practical with
your time, but things like plaintext passwords are unacceptable (IMHO) in even
the first cut of a production system, let alone an established one with a
large userbase.

------
tekomino
The problem is that this looks good when written but bad when you have to
follow it. If you look at 37 Signals products over the years they relentlessly
add more and more and more while preaching less and less and less.

See disconnect? The truth is that you must always add more otherwise product
goes stale. They know it but "do less" as a story sells better...

~~~
teej
You're missing the forest for the trees.

The heart of "do less" and "minimum viable product" isn't to do a crappy job
or to have a minimalist product. The point is to relentlessly prune your
feature set and relentlessly prune your features so that you're solving real
problems and offering the most value per feature.

Prune your feature. If you cut two less use-cases from your feature's spec, is
it still meeting user's -real- needs? Is it easier to use now because it's
less complex?

Prune your featureset. Is that feature something that meets real users needs?
Even an HN hero (patio11) had this issue recently when he launched a feature
and had all of 2 customers use it.

Get validation. Don't answer these questions by intuition alone. Get customer
feedback, hear what they are saying, and do root cause analysis on why they
have those complaints. Make sure after you've launched a feature that it's
actually solving customer's problems.

Tighten your feedback loop. Living in a black hole for weeks at a time lowers
the chance that your feature will actually solve people's problems. Have a
feature that will take weeks to build? What's the smallest subset of that
feature you can launch that will tell you if it is actually solving real
issues? Even if you have to launch that feature internally or to a small set
of users, you need to figure out if you're on the right track as soon and as
often as possible.

Do less isn't really about having less features. It's a strategy for
satisfying the most customer needs for dollar. You do this by seeing a
problem, proposing a solution, and building the least you can to verify that
your solution is correct.

~~~
patio11
Teej has an excellent memory for offhand remarks on my blog, and that incident
was a great example of what not to do.

Issue: Many customers email me to ask "Can I access the cards I create at home
from school?", "Can I print the cards I create at home from school?", etc etc.
The cards exist as files on their hard disk but a significant portion of my
customers cannot reliably locate files they have saved, as evidenced by email.

Solution: I'll let them save files to the clooooooooooooud (technically, just
my server, via a simple web service) and then all they have to do is open up
their copy of BCC at school and, boom, there are the cards they were working
on.

Why This Belly Flopped: I launched the online version of my software prior to
launching this feature and my customers who had previously had problems with
distributed file management took to it like ducks to something ducks like a
whole lot. Additionally, the feature was an abstraction customers were not
used to -- it doesn't work by hitting the Save button like every other piece
of Windows/Mac software they have ever used. (By comparison, saving in the
online version is so easy customers don't even realize it is happening.)

What It Cost Me: Probably 12 hours of development time to marginally increase
satisfaction of 20 paying customers and add 0 sales. By way of comparison, the
next major pair of features added to the software took 4.5 hours and have been
used by thousands of people, and an A/B test I wrote Monday night in 15
minutes has already done more for my business.

------
z8000
This was the best part of the referenced page:

"Don’t be such a suck up Dan."

As if Carl here was just so damn annoyed that Dan beat him to "first DHH!
First! Pick me for kickball!" I just picture Jan Brady as Carl: "Marsha Marsha
Marsha!"

Ok enough semi entertainment by poking fun at the followers of David (since
when did he start going by one name like Prince or Madonna or Quasimoto?)

~~~
daniel-cussen
I read "The Rails Way" and apparently he hates the moniker DHH. He prefers
Heinemeier Hansson, if he's being referred to by his last name like Dawkins or
Lessig or Obama, but if it's more casual or frequent, especially if it's on
his blog, David works.

I suddenly feel all fanboyish though...ech.

~~~
dhh
Heh, I actually don't mind DHH in written form (let's face it, it's a long
name and plenty of people can't get the spelling right). It's when people
start calling me that in-person where things get a little weird.

~~~
gry
I had heard you didn't like DHH before as well. I thought it was DHH being
DHH.

I couldn't have been more wrong.

------
davidw
> What stops most people from doing less is the fear of failure.

I think most people do more because they figure (right or wrong) that it's a
good way to compete. Not everyone wrote Rails and has a huge 'following', so
they need other barriers to entry for their products.

------
k7d
Old truth, but it never hurts to remind ourselves.

------
tennisman120
They're great at taking the same thing, changing a few minor things, then
turning around and selling it.

