
Check you're wearing trousers first - FailMore
http://robertheaton.com/2013/04/01/check-youre-wearing-trousers-first/
======
zacharyvoase
Yes, 100%.

One thing I've enjoyed so far about being a contractor (but not a consultant)
is that even as a relatively junior developer, I get to see the dirty
internals of many different companies, and spot patterns between them. This is
one of them.

I've been at companies that decided to switch to hot new NoSQL distributed
fault-tolerant join-free key-value vector clock databases, when really they
only needed to add a couple of indexes to a few heavily-queried fields. I've
seen language switches and full re-architectures based on perceived
performance problems, but the complexities of the new architecture made
request latencies _worse_ (c.f. <https://en.wikipedia.org/wiki/Second-
system_effect>).

The best approach I've seen so far is described as 'list, rank, iterate'.
Profile your problems aggressively, rank the issues in descending order of
importance, and greedily work your way down the list, fixing them.

~~~
jiggy2011
If there's one thing that drives me potty it's people who claim that mysql is
too slow for their requirements (usually low-medium traffic website), then I
look at their implementation and see no indexes on non primary-key fields.

Before NoSQL was a thing, I saw people break their data out into 1000s of .txt
files to get around this.

~~~
jtc331
There are so many good reasons to avoid MySQL that one shouldn't even need to
bring up speed.

~~~
flyinRyan
Agreed but in this case "mySQL" meant "SQL" (vs. NoSQL).

------
edw519
Nice post.

Whenever I run into a fresh technical problem, I often think of this:

"Why does Grandma remove the chicken's legs when she makes soup?"

Aunt Dorothy: "It's easier to cut the chicken when it's cold that when it's
hot."

Uncle Bob: "Greater surface area better infuses the broth with fat."

Aunt Sue: "To allow the dark meat and white meat develop flavor on their own."

Aunt Jean: "Smaller pieces allow the chicken to cook faster and more
thorougly."

Grandma: "So that it fits in the pot."

~~~
JonnieCache
There's an even more effective version of this story that ends with grandma
saying something like "back when I was a girl, we couldn't afford a big enough
pot."

~~~
emelski
It's probably apocraphyl:
<http://www.snopes.com/weddings/newlywed/secret.asp>.

~~~
wglb
Perhaps the word you are thinking of is _apocryphal_. But I do like what the
spelling _apocraphyl_ implies--it sounds like some kind of plant compound. May
I borrow this spelling?

~~~
redler
This should be the name of the pigment that imbues those cheap bunches of
flowers at the local deli with their artificially bright neon petals.

------
bjhoops1
_It’s a pleasant delusion to believe that all our problems require hard
solutions._

Love this! So true.

I'll never forget my first job out of college, a Senior Developer told me
something along the lines of "Nothing we do is cutting edge. You will almost
never need anything more sophisticated than brute force algorithms and
database I/O." And yet we managed to create some pretty cool products for our
users. Good article.

------
smcl
The "STOP SPENDING SO MUCH MONEY ON HELICOPTERS AND MANAGEMENT CONSULTANTS"
line reminded me of this piece, from the excellent Armando Iannucci Shows:

[http://www.youtube.com/watch?v=MSJggp-
mbiA&t=50s](http://www.youtube.com/watch?v=MSJggp-mbiA&t=50s)

~~~
muan
This is surprisingly entertaining.

~~~
chrisdevereux
That show was great. Not as well known as it should be because it had the bad
luck of premiering on 9/11/2001.

Ianucci also made The Thick of It, which you should really watch if you
haven't seen it. One of the best pieces of political satire ever made.

~~~
rmc
If you haven't seen Yes Minister/Yes Prime Minister, you really should. 30
years on and still great political satire.

~~~
kemayo
There's some fantastic parts like the bit about leading questions:
<http://www.youtube.com/watch?v=G0ZZJXw4MTA>

------
abstractbill
Excellent post.

The first question I ask myself, as an engineer approaching a new problem, is
"How can I cheat? What's the 90% solution that will take 10% of the time?"
(The next question is, "Is 90% enough?").

I'm always surprised by engineers who don't think this way.

~~~
jakejake
I think this is the essence of the phrase "a good programmer is a lazy one."

~~~
bigiain
The three qualities of any great programmer: laziness, impatience, and hubris.

(From The Camel Book (Programming Perl) in about 1990 or '91, from memory)

<http://www.hhhh.org/wiml/virtues.html>

~~~
MaysonL
It ain't hubris when it's objectively true. :-)

------
RKoutnik
Working on trouser-color problems is also a form of procrastination. It's much
more "fun" to tackle big problems with lots of code that will get Big Results.

I always try to start my day with something really boring and basic for this
reason - Things like "Add X to DB class" are tedious, but they help bootstrap
my brain into a place where I can tackle the bigger problems (if I need to).

~~~
reeses
That's a great technique. It's a good application of most prolific writers'
advice about writer's block: just write, dammit!

I've taken it as a sign that I am officially "old" that this article was
stunningly obvious. I remember being introduced to a profiler and similar
instrumentation techniques by my first software engineering mentor.

Value, including your reputation, is built on applying intellectual leverage
to get results that are faster and larger than expected.

The quick fixes (low hanging fruit) buy time to gedankenversuch your big
architectural solution, so you can apply your critical mind to tearing it
down, rebuilding it, boiling the ocean for tea, and tearing it down again
while washing your underarms in the shower[1]. With a new team, it builds
trust so that "rudely" doesn't come into it when you open the topic.

[1] This is the leading cause of having to jump back into the shower because I
forgot to rinse.

------
DoubleMalt
Great post. It's a trap I tend fall into myself far to often. And it's the
same direction as DHH's famous rant about winning in Vegas.

It's a virtue too rarely seen, that you should try to solve a problem with the
minimal set of code possible.

Everything should be as simple as possible., but not simpler. (Sometimes
attributed to Albert Einstein, even if he probably never uttered the exact
words)

~~~
GFischer
Thanks, I had to look up that article, and it's definitely a good one:

[http://37signals.com/svn/posts/3384-winning-is-the-worst-
thi...](http://37signals.com/svn/posts/3384-winning-is-the-worst-thing-that-
can-happen-in-vegas)

Edit: discussion on Hacker News

<https://news.ycombinator.com/item?id=5002454>

------
noelwelsh
I enjoyed this article and I agree with the main point it makes. I want to
quibble about a smaller point, which is that intuition is not always a
reliable guide.

The author gives a few examples where they got stuck in and fixed the
"obvious" problems. My experience is that what is a problem is not always
obvious. Furthermore, while the big wins might be obvious, you'll miss many
small wins if you're not carefully tracking stats. These are the main lessons
of A/B testing.

~~~
derefr
The whole point of the article is "don't A/B test (or do anything else fancy)
until you run out of obvious problems."

~~~
noelwelsh
Sorry, let me be clearer. What I may believe to be an obvious problem may not
actually be a problem for customers. What may be an obvious problem for
customers may not be an obvious problem for me. Intuition is often wrong.

~~~
derefr
There's no impassible wall between you and your customers. Watch a few of them
use your product. If 80% of them stumble somewhere-- _that's_ an obvious
problem.

It didn't take Chi-square analysis for Microsoft to notice that nobody could
figure out how to start a program in Windows 95; they just sat down and
watched a few people, and it was suddenly very clear that they needed a big
arrow pointing to the start button.

~~~
noelwelsh
Agreed!

Generating hypotheses often involves qualitative techniques. Validation must
be quantitative.

------
johngalt
One accurate measurement is worth a thousand expert opinions.

You'd be surprised how many big strategic decisions are made on top of a
mountain of opinions. Try to be guided by what _is happening_ not what
_should_ happen.

------
austenallred
While I get the point of the article, I have to say that nearly every time I
run split-testing or multivariate testing I am surprised at the results.
Honestly, at this point I'm somewhat convinced that sites that are uglier
convert better.

So while I agree that a lot of things we can overcomplicate, it's not safe to
say "Just go with your intuition." It doesn't have to be as cut and dry as
"once users get 10 friends they keep coming back," but don't use that as an
excuse to not look at your data.

~~~
sesqu
Chances are that's just because your data is insufficient or non-independent,
but I do agree that intuition isn't the be-all. A big problem with
multivariate testing is explaining your results, which is a huge time sink for
low or negative gains - see the other post about hero images, for example.

------
lesinski
If you're just a dude or a small start-up then sure, avoid analysis paralysis.
But if you work at a bigger company, you have to test and bring in data to
make changes -- otherwise, your stuff will lose out to other priorities.

~~~
danohuiginn
also, you need to measure and test to know whether it worked, and thus to move
quickly on to the next problem. If you can't demonstrate that a problem is
solved, you'll likely be told to keep working on it long after it stopped
being the most pressing issue.

------
wolfgke
I don't think these solutions are simple. I personally consider the highly
technical solutions far more simple, since there are scientific properties
like falsifiability, lower bounds etc. that you can use to analyze these kinds
of problems.

On the other hand for the problems written about in the article there are no
such methods known. Thus they are far more complicated. The only property that
enables us to apply them in our world is that our society brainwashes people
into common sense (which is far, far away from good solutions; common sense
only delivers solutions that barely work).

So I still believe (more than ever) that hard problems require hard solutions.
But I define "hard solutions" differently than the article.

------
hipsters_unite
My dad worked his way up (several companies) from being an engineer to a
technical manager and most of his success was from repeating 'keep it simple'
at key junctures, so far as I can tell.

------
zimbatm
In short, identify the problem, solve it. Not, choose a technology that you
like and hope it's going to solve your vaguely defined problem.

------
pluggerguy
"He says, there are no easy answers! I say, he's not looking hard enough!"
Bart Simpson

------
daedalus_j
Okay, I'm gonna take a huge karma hit for this, but I had flashbacks to
slashdot mentality here:

"But I wear a kilt you insensitive clod!"

------
benjaminwootton
Want happy blog readers? Check you're not hijacking peoples back button first!

(Just kidding, it was a great read apart from that!)

------
jorgeleo
TLDR:

Occam Razor

TLDR2: Better simple than easy

