... In Which We Discuss Digital Gearheads and Geek Mastery
I had a roommate in college named Eric who was from "Pennsyltucky" as he called it. A pretty nice guy, he was your very, very typical gear head: hacked up muscle car, kept every spare part he could find at a swap meet (and that fell of his car), insisted that he was safer driving at 80 than he was at 55 "because he could control his car better", etc.
Eric's car was disturbing. He had a 1978 Capri (nicknamed the "Crappy") that he had rebuilt 16 or 17 times - a true Frankencar. All I know about the engine was that it had 8 cylinders, a "bored out hemi", and was faster than shit. Inside, Eric had ripped out the center console and put in a series of toggle switches that controlled fuel mixture, some kind of blower, and something to do with the radiator. All I really remember was going down highway 5 to LA once, doing 110, screaming at Eric to slow the #@#@ down while he flipped his switches.
Eric also kept a dedicated pad and pencil in the glove box that were covered in grease. Everything was covered in grease in that car. I asked him WTF was with the paper and he showed it to me:
- Every time he went to the gas station he noted the date and the amount of gas (excuse me, "fuel") that he added
- Every oil change was documented, with a note indicating the smell and color of the spent oil
- Every part change was documented
- Every breakdown was documented, including the fix.
In short: Eric was scary.
For fun, my other roommate John and I used to steal his pad and pencil (OK, it was just me) just to mess with him. Eric took it in stride and knew exactly where to find it: in the freezer. I'm not sure why I put it in the freezer but the fact that I did that every time somehow annoyed the hell out of him. I think he wanted me to at leat try to give him a hard time. Instead I just always put it in the freezer.
In truth, the geek in me found the pad and pencil thing pretty interesting - Eric could pinpoint any fault with his car (after it happened) and fix it very quickly. He could also tell what was going on with the car at any given time by looking at the fuel consumption and (probably) twiddling some of his toggles. It was really a gearhead/geek car for sure.
The thing that Eric didn't consider, however, was the aesthetic value. I hated that car - it smelled, Eric was distracted while driving, it was too loud, and overall it was completely unsafe (no airbags, etc). He completely ignored the human aspect of driving in a car, which is much more than getting from A to B (namely, staying alive while in the car).
The Crappy ended up dying on the side of the road one day and Eric realized that his youthful gearhead enthusiasm was being taken over by his "newly acquired yuppy status" (as he put it). I think he actually just grew up. He ended up buying a Trooper and had the car towed to the scrap yard, where he was rewarded with $400 for all of his painful efforts.
As you can imagine, I gave him endless shit about his little tinker toy ending up in the junk yard - what was it all worth? Eric didn't really defend himself - he just said "that's how you should take care of a car". So where was the pad and pencil for the Trooper then?
"Don't need one". Crap. Nothing to hide in the freezer now except for his Costco-sized 5 pound can of MuscleMax 3000...
Are You a Digital Gearhead?
People who build things love to embrace complexity, and exercise their dominance over it. They also love to demonstrate that mastery to you - whether it's intended or not (your id always wins, no matter what).
Eric loved to watch me squirm in that car - loved to explain to me what everything did. I don't think he could even grok that I didn't care, and that I hated his car. To him that car was a perfect expression of mechanical lordliness.
I see his enthusiasm in code that I read on pretty much a daily basis. Jeff has great post today about it; the picture of the dialog box is pretty much Eric's car in dialog box form.
If the programmers who built that dialog box had taken a second to consider its impact on the user experience (total confusion) - I mean really consider it, it would have been cut in a third, I'm sure.
Is Your Code Hot or Not?
One way I like to make sure that the stuff I write is "human friendly" is to consider what it would look like if it got up off the page and walked into the local bar. Would it pick up some hotties or get it's but kicked by the locals?
I have a "code model" in my mind (seriously) - a persona if you will - that I like to focus on when I write up anything: a Tai Chi master going through various Kata.
I really love the Feng Shui "minimalist" aesthetic and the idea that the most complex things should appear to be the most simple. One thing I love to tell Eric Kemp (I'm sure he's sick of hearing it) is "ridiculously simple" and it's something that I've really, really tried to drive into SubSonic.
I think this is the main appeal behind Rails, and also the the driving factor behind the statement "it just works".
What exactly do I mean by all of this? Let's take a look at some code samples:
Using SubSonic I can express, very clearly the data I want to get from a database, all in one line -
Northwind.ProductCollection products=
new Northwind.ProductCollection().WHERE(...).ORDER_BY(..);
My goal, in creating this type of method call, was to make it as readable and concise as possible, allowing the new user to "get it" (and pick it up and run with it) by reading this one line.
Also, when reading that code, you know pretty clearly what's intended by the programmer.
This concept goes far beyond coding - it also touches on architecture as well.
I was talking to Jon Galloway about a month ago about the Provider Model, and how it's ridiculously abused. I don't think there is a more complicated way of getting data out of a database - yet people love this thing. It does indeed allow you to abstract the tar out of where your data comes from - but do you really need this most of the time? A simple AbstractFactory pattern can usually accomplish the same thing, with less code.
In addition, the System.Data.DataFactory bits (new to .NET 2.0) can abstract just about any database - as can SubSonic, NHibernate, and Gentle (or any other ORM tool out there). Why the Provider Model? Most of the time it's just not needed. I learned this the hard way with the Commerce Starter Kit - the question people asked most was "I just added a field to my DB - how do I get it to show up on the screen!".
Master of Your Domain
I've always enjoyed watching professional athletes doing what they do, and how it always looks incredibly simple. Professional surfers, in particular, blow my mind. The amount of physical skill it takes to propel yourself to those speeds - to get inside a wave and live. To fly, literally, through the air and land once again is just spellbinding. If you've ever tried surfing you know that it takes a good six months to consistently stand up, and years and years before you ever get "tubed".
Mastery of anything, to me, is refining your craft to the point where the most complex thing is ridiculously simple. What's your definition? Why?
A line of code written is a line of code to be maintained. In essence, like any human language, programming languages are about conveying meaning. Why repeat yourself five times ?
Coding beauty is about stripping away the layers of repetition and rhetoric until the essential meaning of the problem is revealed, gleaming in its elemental simplicity.
It's about finding the pieces which can be assembled in just exactly the way that leaves no waste, no rough edges.
Does it show that I think good coding is a kind of poetry ?
How many times have I been to a web site where someone has a problem and a helpful person offers advice along the lines of 'It's easy, just do ' when a single property assignment will do the same thing.
This is why Ruby on Rails is such a powerful tool - it implicitly contains the solutions to so many problems. Why should we ever have to supply more information to a development environment other than that required to minimally describe (even describing by difference) what we want to achieve, and doing so in such a way that will optimally survive subsequent change ?
Why do so few environments seem to pursue this goal ? I just don't understand.
I've been thinking about this a while, and the best analogy I could come up with is that I used to use a knife, a fork and a spoon to eat my food.
In their infinite wisdom, the creators of modern software environments decided that people needed also to use eggbeaters, spatulas, garlic presses, can openers and whisks in their kitchens. So they invented six distinct components that could be assembled in different ways to create cutlery and all of the above utensils plus quite a few more. This is called re-use, abstraction and encapsulation.
Now, I have the six components in my drawer, and every time I need a utensil, I have to spend a couple of minutes assembling all the bits to make the utensil I want.
Most of the time I just want a knife, fork or spoon, but unfortunately life's no longer that simple.
Again, I just don't understand. Of course we want re-use, abstraction and encapsulation. Of course the six components are better than twenty single purpose utensils.
But the single purpose of the whole exercise is to make life easier. If we offer the six components, we MUST offer a fully wrapped class or classes which emulate exactly what the previous simpler components did (as long as it was sensible, that is) so that the user doesn't even need to know that they are using a composite component. Otherwise, we are making the user's life harder.
For those users who need that little bit extra, the six components are always there waiting to be forged into new and more advanced composite components, which may or may not be wrapped.
So, in my opinion, we now have a range of tools which can solve a staggering range of very complex problems, but are often very poorly adapted to solving those problems which we face 95% or more of the time in a minimalist and elegant way.
I think this 'wrapped simplicity' is at the heart of the 'convention over configuration' approach of ROR, and of the vision for Subsonic.
> offers advice along the lines of 'It's easy, just do ' when a single property assignment will do
> the same thing.
Meant to be :
How many times have I been to a web site where someone has a problem and a helpful person offers advice along the lines of 'It's easy, just do (half a page of convoluted code)' when a single property assignment will do the same thing.
I won't try enclosing anything in angle brackets in HTML aware text again ...
I've been thinking about it for a while, and the best analogy I can came up with is that I used to eat my food with a knife, fork and spoon.
In their infinite wisdom, the creators of modern software environments realised that in the kitchen people also use eggbeaters, whisks, can openers, spatulas and garlic presses. So they came up with six distinct components which can be assembled to create not only cutlery but any of the above utensils, plus quite a few other utensils too. Re-use, abstraction and encapsulation.
So now, I've just got the six components in my drawer, and whenever I need a utensil, I just need to spend a few minutes assembling it out of its components.
Most of the time, I just want to grab a knife, fork or spoon, but life is no longer that simple.
Again, I just don't understand. Of course, we want re-use, abstraction and encapsulation. Of course, the six components are better than a whole swag of cutlery and single-purpose utensils.
But the whole object of the exercise is to make life easier. If we create new elements like this, we MUST also distribute a set of wrappers which exactly mimic the previous simpler components (assuming these components were sensible), so that users don't even have to know they are using the new composite components.
Otherwise, we are making the user's life harder.
Those six components are still there to be forged into more advanced composite components by those who want to use them, and new composites can be wrapped by the designer if they so choose.
So in my opinion, in .NET we now have a native set of software components which can be assembled to solve a staggering range of very complex problems, but are often not good at solving the problems we encounter 95% or more of the time in a minimal and optimised fashion.
And as you point out, many programmer types seem to revel in the needless complexity of it all. Personally, yechh, I don't want to get any on me.
But I believe this 'wrapped simplicity' approach is the essence of ROR and the vision for Subsonic.