

Levels of aspiration - hawke
http://37signals.com/svn/posts/3200-levels-of-aspiration

======
Udo

      To help someone move up the hierarchies, they have to have an intrisic (sic) 
      desire to do so. Arguments like “but it works” or “it gets the job done” are 
      tell-tell signs of someone happy at the lowest level of the technical 
      hierarchy and your cue to just quietly back out of the debate.
    

For an article that claims we need software "in all shapes and sizes" the
amount of smug superiority exhibited here is amazing. Yes, different people
have different priorities when it comes to software choice, but applying an
arbitrary one-dimensional quality pyramid to it and assigning users to levels
corresponding from ' _absolutely clueless hillbilly_ ' to ' _latte-sipping
Ruby poet_ ' is just wrong.

And the pyramid itself doesn't follow any logical ordering either. E.g. the
implication that "beautiful code" is also fault tolerant is a total non
sequitur. We get it, 37signals is moving the industry forward, it says so
right in the infographic. I'm not even disagreeing with the fact that this
company has been extremely influential, and I did enjoy reading their book -
but appointing yourself king of the hill while casually dismissing technology
you don't agree with as being lower level, that's just bad form.

~~~
frankc
The irony of the whole thing is that it is usually the pragmatists and not the
idealists who wind up "moving industry forward", because by definition, the
pragmatists get things done. The world needs C not lisp.

~~~
raganwald
I have great sympathy for your point that pragmatism has tremendous value. I
disagree in a trifling way with statements like “The world needs C not Lisp,”
it is obvious to me that the world needs both C and Lisp. Or it did, and both
have contributed in various ways to progress, and C continues to be a useful
tool.

The interesting thing is that insanely great progress requires operating at
all levels of the hierarchy. Consider the oft-quoted maxim, “Real artists
ship.” This does not suggest that there is no room for dreaming, but rather
that the highest form of artistry is the application of pragmatism to
manifesting our dreams.

~~~
frankc
First of all, I think my statement "the world needs C not Lisp" was meant to
be taken metaphorically, not literally. Of course there is a place for Lisp,
but at the end of the day, who has gotten more done in the real world? That
certainly hasn't stopped the Lisp hackers from looking down their noses,
however.

The bottom line is that the sense I get from the kinds of rhetoric in the OP
is not the kind of high-minded idealism you express but rather just a bunch of
software aestheticians casting value judgements on the people who are focused
on making things happen. My perception could be wrong, I'll grant you that.

------
davidw
Someone once wrote, in their bestselling business book:

"Good enough is fine A lot of people get off on solving problems with
complicated solutions. Flexing your intellectual muscles can be intoxicating.
Then you start looking for another big challenge that gives you that same
rush, regardless of whether it's a good idea or not."

This is somewhat different than what's written in this article:

"Arguments like “but it works” or “it gets the job done” are tell-tale signs
of someone happy at the lowest level of the technical hierarchy and your cue
to just quietly back out of the debate."

And here's the deal: they're both right, but you need to recognize when each
situation is right. The terminology for this is called "maximizers vs
satisficers". I wrote something about that and programming here:

[http://journal.dedasys.com/2006/02/18/maximizers-
satisficers...](http://journal.dedasys.com/2006/02/18/maximizers-satisficers-
and-programming-languages)

And the book that is widely cited is this one:

[http://en.wikipedia.org/wiki/The_Paradox_of_Choice:_Why_More...](http://en.wikipedia.org/wiki/The_Paradox_of_Choice:_Why_More_Is_Less)

But getting back to the discussion: there are times when you really should be
looking for the _best_ whatever it is you're looking for. But if you try and
do that all the time, you'll spend all your time looking (or worse, deciding
everything sucks and you can do it better yourself) and not enough time doing
what it was you set out to do.

Which, in the end, simply means that you have got to do the thinking and make
your own difficult decisions, rather than listen to trite advice from business
books or blogs, or hacker news comments, no matter how insightful they may
sound!

------
gfodor
For mature developers the choices here are not about innate skill but about
tradeoffs. This blog post makes the error of projecting what is a multi-
dimensional problem onto a single dimension.

You can have a pretty abysmal code base with beautiful design on top and
amazing UX and be rolling in piles of money, and be perfectly aware that the
code sucks but made the decision that beautiful code was not the priority or
competitive advantage of the business.

~~~
smacktoward
I would go a step further and say that, at least in my experience, the code
bases that have yielded amazing UX, piles of money, etc. are almost _never_
beautiful. The code may _start out_ beautiful, but once people start using it
they start surfacing naïve assumptions, flawed designs, bugs, etc. And if
things are going well business-wise there's rarely time or resources to fix
those issues in a beautiful, comprehensive way (since maintaining beauty
frequently means massive refactoring or flat-out rewrites).

In other words, beautiful code is code that nobody uses.

~~~
jackcviers3
To me, ugly code is code that gets the work done but at the price of too much
complexity ( non-DRY, non-cohesive, spaghetti, callback soup ), not enough
abstraction, too much abstraction, or too few quality control measures
(tests). These things make it difficult to maintain any code.

In other words, ugly code is code that must be rewritten to be maintained.
Depending on the innate complexity of my problem that can be an acceptable
trade-off.

Beautiful code should also be easy to maintain; usually that means making each
layer of abstraction as simple as it can be, and adding a new layer of
abstraction to handle additional complexity.

In this way, I may write more new code to handle newly discovered edge cases
or new features, but at least I am not rewriting old code to solve the same
old problems plus the new ones. That gets old really fast.

------
tjr
Would not the top of the pyramid intersect with the bottom in the land of
computer science research, where new ideas are being developed but the
software itself is often hacked together to the point of just barely working?

Not sure if this is a useful observation, or only an observation.

------
eragnew
This diagram is kinda like a roadmap for how to succeed, IMO:

[http://s3.amazonaws.com/37assets/svn/952-technical-
hierarchy...](http://s3.amazonaws.com/37assets/svn/952-technical-
hierarchy.png)

(that links comes directly from the article in question)

Good stuff!

~~~
alberich
how to succeed at what?

------
ry0ohki
This is a great point, I've always been towards the bottom of the pyramid
(just coding to "make stuff work"), so when people have tried to sell me on
the latest and greatest, based on the beauty, etc... were never compelling
enough for me to switch.

------
pgrote
Why is Wordpress on the base level?

~~~
dhh
I used it as an example of what people who just modify an existing code base
would use. Not Wordpress, the product, itself. I'm sure that's nicely done.

~~~
pgrote
Thank you for the clarification.

