ntschutta.com

So last night I made a mistake - in a moment of weakness, I decided to get my car washed. I was so tired of all the grime that I just had to clean the old girl up. You’d think I’d learn from past transgressions, but no. The last time I washed my car, the very next morning it snowed, turning my quiet commute into, well, a not so quiet one.

Yes, I should have known better especially when the weather person on the radio said there was a 50/50 chance of snow in the morning. But by then I was committed. Maybe not in the “pig” sort of way but there was no turning back. Oh well. The astute reader would note that I’m speaking in St. Louis today and seeing as I don’t live in or near St. Louis this implies a trip MSP. Ordinarily I’m the type that gets to the airport with plenty of time to spare…but not today.

I should have just listened to my wife. She left for work at the normal hour and called me 30 minutes later to say she’d almost spun out in Spaghetti junction. I was a bit alarmed but as my initial plan allowed me two and half hours of travel time, I wasn’t concerned. And as I headed on down 35, things seemed fine - I was clipping along thinking about the mocha I would enjoy while waiting for my plane. But then it happened.

Just south of the last exit for several grueling miles, traffic came to an almost complete stop. For about five miles I was literally idling my way along. To say it was painful just doesn’t do it justice - a stretch that normally takes 10 minutes was pushing an hour. I glanced at the clock, did some math and called my wife. At this moment I figured there was ZERO chance I’d make my flight…none. I had her call Jay and the travel guy to see what my options were. Of course if you’ve flown you pretty much know you must actually miss your flight before you have any chance at redemption.

After what I can only describe as an eternity, I was finally able to exit the parking lot that was 35E south. I figured I was home free. Oh. How. Foolish. Highway 96 wasn’t much better and again a few miles took torturous amounts of time. By now I was thirsty and the windshield wipers were working overtime. After agonizingly slow progress I was finally able to head south - towards my ultimate destination (though the idiot that decided she should plow ahead as I was turning left on a yellow arrow - I’m not sure what you were trying to prove by gunning it off the green light but good for you for almost clipping me, I’m sure that would have gotten you to work right quick).

Lexington avenue was moving right along and for the first time all morning rays of hope warmed my face. I thought there might be a chance - slim as it may be - to make my flight. Off I drove cutting over to Snelling which would take me most of the way to the airport. Woops, got a little ahead of myself. Though not nearly as bad as 35E, Snelling wasn’t good. My wipers were so bad I had to make a pit stop…but I soldiered on.

Eventually I started making good time though again, looking at the clock I was quite certain I’d have an afternoon at the airport. Eventually I found my way to West Seventh and things were nearly falling into place. FINALLY, I was at the airport…now all I need is a parking space. I mentioned the snow right? Well, the spiral drives at the parking ramp aren’t exactly “dry” by this point in the morning - something I become acutely aware of as my all wheel drive SUV starts to slide a bit going up the embankment. Of course there’s someone *right* on my tail… But I manage to get to the second floor where the signs assure me I’ll find parking.

Around and around I go wondering where these alleged spots are. Again checking the clock wondering how a mere inch of snow turns a 45 minute drive into a three hour slog… Hey, what’s that over there? A SPOT!!! Oh joy! Off I rush to the skyway frantically telling my wife I’ve arrived. At this point my flight is boarding - no doubt about that - and I haven’t cleared security. But I remember back to my last trip out of the A concourse when the very nice Northwest agent told me about the security checkpoint for carry on only.

What’s that sign say? Checkpoint this way! Off I go figuring it’ll be easy to spot. Not so much. I take the tram to the only stop and look around confused. Oh, I see, the security checkpoint sign is by those stairs over there - the ones you’d know to go up if you knew where the magic entrance was. That wasn’t quite the end of my searching but needless to say I did find what I was after.

I ask the TSA agent if I have a shot of making my flight, he looks at his watch and says no problem (which leaves me thinking - are you going to beam me to the gate?) After going through the metal detector twice (darn cell phone) I quickly grab all my stuff and prepare for the sprint I’m about to undertake to the other side of the world. As I’ve described before, the A concourse is a bit of a hike and I’m going out 12 - which darn near is in Stillwater. I huff and puff and show up just in time… Though I wasn’t the last person on the plane, it was tight. But I made it. And I’m now in St. Louis.

Uncle Bob has a great post titled Going Fast - a theme I visited a while back. I don’t know what it is about software development that makes people so willing to cut corners…even (especially) when they know better. How much pain is caused by quick and dirty solutions? How many times have you been working through some code cussing out the developer because they didn’t take an extra hour to do the right thing? Ken Schwaber hits on some of this in his talk at Google and perhaps the move towards more productive programming environments will alleviate this somewhat.

I found myself nodding along throughout Bob’s piece and much as I hate to admit it, it comes down to professionalism. That said, there are times where we *need* to get a solution out the door today to meet a business need - still we tend to, as Bob phrases it, “treat the long term as a series of short term quick and dirty solutions.” How much of this attitude is tied to the quarterly thinking engendered by most public companies’ need to meet analyst expectations? I’m sure Cedric Beust might argue a bit about the need for 100% code coverage but I for one would like to see more clean code.

Kathy Sierra touched on this topic in her post …so it takes less time. To use a particularly apt analogy for me these days, nine women can’t deliver a baby in one month; despite the hype, multitasking doesn’t work terribly well (shocking I know). Anyway, the real money quote comes from Pat Parelli: “Take the time it takes so it takes less time.” Amen. It seems so obvious yet it’s so often ignored. Someday we’ll learn our lesson. I hope.

It really doesn’t take much to keep developers happy - fast machines, a steady supply of (good) caffeine, interesting work on moderately new technology, comfy chairs, managers that leave well enough alone…Joel Spolsky’s Field Guide to Developers anyone? Google appears to be nerdvana but I swear Rob Walling is channeling Scott Adams with his Nine Things Developers Want More Than Money (via Erik’s Linkblog from Friday). Seriously, there are more than a few great quotes in there that make me think I’ve worked with him before (anyone else smell some similarities?)

There is abundant goodness but I wanted to highlight a few bits. First regarding challenges:

Faced with the right type of challenge many developers will not stop until it’s fixed, especially if it requires a particularly creative solution. Faced with the wrong type of challenge and they’re back on instant messenger describing the toast.

I’ll never forget an experience I had a few years back, right around this time of year. It was the Wednesday before Thanksgiving and another developer and I were grinding through an issue. As was the custom at the time, after lunch the manager came around and told everyone they could head home. We nodded politely. About an hour later he came back to remind us about the early dismissal. An hour later he came over and all but ordered us to leave (we did…but not before fixing the problem).

A recent experience with a large web retailer’s customer support reminded me of the importance of having a voice but Rob really nails it:

When a developer speaks, someone should listen. When several developers are saying the same thing, someone should listen and act…quickly.

Nothing is quite as frustrating as *knowing* something is wrong, saying so and being ignored. I’m not sure what happens during the management lobotomy but many of them forget how to listen (that’s assuming any of them ever possessed that particular skill). Marriage tip - listen. It sure would have saved me some grief over the years.

When I was in school I was really naive - I assumed that people were judged on results not by how closely they followed some silly process. Boy was I wrong. So many companies value process over people to point where:

When I got my next full-time job it felt like I was dragging 50-pound weights. For every page I wanted to build I had to call a meeting with six people. Any change to the database required three approvals. It was nuts, and applications took 5x longer to build. Talk about frustrating.

Frustrating is an understatement. I’m amazed how far some companies take this and I have to wonder what would happen to a certain class of employees if meetings were reduced and we actually, you know, empowered folks to do real work. Yeah, that’ll never fly.

So I didn’t bother to actually take the quiz (take a look at Joel’s too) but I’d be curious to know how your company scores… Great post from a blog I’ll have to check back on!

I began my collegiate career as a Chemistry major - the shinny new chem center combined with the fact that a degree in Computer Science required more than a minor in math got me thinking that mixing known carcinogens was as good a way as any to spend four years. But then I hit O chem and the powers that be reduced the math content significantly so off I went to the land of compilers. Needless to say, I took a rather, ahh unique, path through the major and while the finer points of circuit design have been lost to the ether, bits of my chemistry training still stick. For some reason, I still remember when the concepts of entropy and enthalpy were introduced during that first year chem class…

Needless to say, I was taken in by Neal Ford’s Entropic Software post. Neal uses an interesting example to discuss the similarities between the technical definitions of entropy and information to support his central tenant that “software breeds entropy”. He continues by comparing the design of Unix and it’s history of “mini languages” to Windows and its (I’ll say it - clunky) approach to interoperating (I couldn’t help but think of Martin Fowler’s keynote from RailsConf along with his discussion of DSLs). The moral of the story? Keep it simple…ah you know the rest.

The nature of the universe is towards disorder (told you I remembered something from that chem class) and I have to agree with Neal that software tends towards complexity. Some of this is our fault - for whatever reason people in this line of work reallllly like complexity (often for it’s own sake) but the ephemeral nature of software doesn’t help (c’mon how many of us have added just “one more feature” since it wouldn’t be _that_ hard). Though he doesn’t explicitly mention it (until the comments) part of why Rails rocks is that it adheres so strongly to the principle of simplicity.

While I certainly don’t know *what* technology will be the king in five years (even if I did I’d keep it quiet until I was able to write the definitive book on the subject) it is clear that Rails has had a major impact on how we write software. As I mentioned in my JavaOne recap, everyone is trying to “prove” that their approach is just as easy as Rails (or they try point out how it isn’t enterprisey enough). Neal’s dead right - software wants to be complex and it takes a concentrated effort by engaged developers to do that. Let’s hope more of us are inspired by the diligence of the Rails team towards this end.

Like many geeks I’m pretty sure Dilbert is just about the greatest comic ever (right up there with The Far Side and Calvin and Hobbes) but today’s strip just rang so true! Of course some of these hit so close to home that it is just scary - seriously I think there are days that he’s just down the hall. And more than a couple of people found the latest coffee series reminded them all too much of me…

The glamours life that is the speaking circuit. Last night around 8 PM I picked my lovely wife up at exotic MSP only to return 12 hours later to fly to Toronto for the NF event. In general I like MSP - well, I’m familiar with it - but I have to say, “they” have really sucked the romance out of travel. Off with your shoes, take off your belt, put your laptop through separately please, take out your little plastic baggy full of travel size liquids and gels, throw that water away… Man - these new rules *must* be a boon for the in airport kiosk industry.

But you know what the secret is? Never forget, the people working here are doing their best (mostly) and their just following orders. Be civil to them and you’ll be amazed at what you get in return. I know, some of them are, well, dinks, but a smile and a warm comment go a long way. At least it does for me - YMMV.

Today I’m flying out of good old concourse A, a relatively new part of MSP and one I’ve never been to. The kindly woman who checked me in (and also shared a neat little trick, what did I say about that smile? No, I’m not telling…) was right - it is half way to Stillwater! I hope I’m not flying on the plane I see out the window…what was that I said about glamour?

Most of the time I’m traveling out of the main part of the airport where you can’t go fifty feet without running into a Caribou or a McDonald’s but when you’re at A, you better be ready for the duration. Or have the time to run back to C. Seriously, vending machines are you options down here (but they are cheaper…) One thing I can’t figure out though - why does the “the walkway is ending” voice have a British accent? Is that particular vernacular more comforting to international travelers? Oh well, in a few hours I’ll be in Toronto settled in for what I’m sure will be a great weekend and then off to Boston for *the* event of the fall. Other than missing my wife, I’m pumped!

Back at dear old SJU, John Gagliardi (recent inductee to the College Football Hall of Fame) was fond of saying “speed kills.” Of course this was in relation to quick footed running backs or wide receivers but the adage works in other contexts as well. As I mentioned earlier, Uncle Bob has been getting into the Ruby space and today he posted a very interesting comparison of the speed of an algorithm written in Java, C++, and Ruby. While Ruby code is relatively slow (and the C++ wasn’t highly optimized) there’s more to this game than raw processing speed.

I’m not saying we should write slow code - far from it. But, there are other considerations such as developer productivity and long term maintenance costs. While there certainly are some applications that absolutely *must* run full bore, I suspect quite a few businesses would take a moderately slower application if it meant their development staff could deliver working code faster. And I can’t second this notion fast enough:

I’d rather have simple, clean, maintainable code over even 1.5 orders of magnitude in many cases.

Amen.

Have you seen that EarthLink commercial, you know, the one where they tell you that geeks get the job done? Well, Charles Nutter is a geek - plain and simple. His recent post, On Coding, is definitely worth a read. While I’m not nearly the night owl he is (well, when I do stay up late, I certainly don’t wake up at 7 am!) I certainly identify with a lot of what he’s saying. Charles is dead on when he talks about passion and while I think it’s good to have more developers with customer affinity, I want those with some zeal, dang-it!

In the late ’90s, a lot of people entered this profession - if you could spell Oracle, you were golden. While I certainly appreciated this attitude during the period I was looking for that all important first job, it was quite a shock when I started working with folks for whom software was just a job. Don’t get me wrong, I don’t think people have to eat, breathe, sleep this stuff (I really appreciate being able to carry on a conversation about, you know, sports or something) but to really excel at this stuff, it has to be more than a passing fancy. Yes, coders are mocked and software is incredibly artistic. And yes, companies that “get it” do extremely well. The sad thing though - few places seem to really want the passionate among us…wonder why that is.

Joel put out a flurry of posts in the last few days including this interesting look at a recent Travelers Insurance ad that depicts geeks in a rather stereotypical light. I’m guessing a lot of folks will agree with Joel’s assessment that the add is offensive - what do you think? All I know is it sounds like he’s shopping for a new policy:

You probably forgot that most of the people that read Inc. are geeks. And we buy insurance. Lots of insurance. Like me. And in fact I used to buy it from you. But not any more.

Now, I have no idea just how many geeks are covered by Travelers, but I do know that a lot of them read Joel’s blog…wonder how many will join him in his boycott? Smacks a bit of Microsoft’s recent evolve campaign and we know how popular that has been!

Michael Mahemoff picked up on my recent ramblings about functional specs and adds his own 5 cents (in my mind, his thoughts are worth more than just a couple of pennies). I agree with Michael with regards to the dichotomy - like most things in life, docu needs exist on a continuum. If I’m just writing a simple little app for my own use, I probably won’t write much of anything beyond the code but if I’m reworking the software that keeps planes in the air, well, chances are I’ll need to jot a few things down!

While needs vary, as Michael says, it’s quite difficult to nail down software requirements down with any degree of accuracy.

The problem here, of course, is that Definitive-style docs require an almost impossible task of pinning down requirements, and furthermore, fixing requirements runs counter to the modern organisation’s goal of being agile.

I’m not sure why companies continue to try and use waterfall like methodologies when agile appears to be the only approach that really works. The idea that process can somehow replace people is as old as the Model T. But then when was the last time you drove one of those to the office?

The real solution doesn’t lie with more process or templates - it rests with better people. I went to a small liberal arts school in central Minnesota. Beyond my studies in 0s and 1s, I took quite a few courses from the outside the sciences, considerably more than I was “required” to take to fulfill my core credits. That was fine with me, my interests were diverse but it always struck me as odd that science folk were required to take far more humanities stuff than the non-science types were required to take in our disciplines. My point?

There’s obviously no one solution, but one essential ingredient comes from multi-talented people.

In today’s marketplace, we need more geeks with customer affinity (and fewer that dig plumbing)…but we also need customers with some appreciation for technology. But then that’s just my two cents.