Monday, August 10, 2009

The Unicorn King and his Magic Pot of Gold




I started this blog about two years ago with a brief mission statement. I then wrote a single entry and didn't make another entry for two years. So, it's worthwhile to again touch on what this blog is about and how I *hope* it differs from a lot of other blogs in the blogosphere.

Excuse me for a sec, I need to go wash my mouth out. Using the word 'blogosphere' just made me throw up in my mouth a little.

I love reading blogs like Joel on Software and Coding Horror. I've learned so much from those guys. The problem is, though, that 99% of the time I can't help coming away from those blogs wondering 'What the hell world do these guys inhabit and if I visit will they introduce me to the Unicorn King and his magic pot of gold?'

It's kinda the same feeling I get when I start talking to a hardline proponent of Scrum (I'm a certified CSM if you really care, so I do *like* Scrum). It's just so divorced from the reality I inhabit it's laughable. Mind you, I'm not saying it's *not* reality. It's just not the reality *I* inhabit.

In their reality, every company hires the top 10% of talent (Where the other 90% go, I don't know? I'm pretty sure I've worked with a bunch of them though).

In their reality, you tell people about Scrum and they get *it* right away. They don't argue with you endlessly, implement in a half-assed way, then butcher it as new client demands come in.

In their reality, every programmer on your team is great and there isn't any dead weight. And if there is dead weight, well you just get rid of those folks with a snap of your finger! Poof! Gone!

In their reality, when a project is not possible in a given time frame, you just explain how it's not possible and tell people "I can implement *something* in that amount of time, but there will be trade-offs"...and everyone's okay with that.

You certainly don't end up having to manage team that turns out to be 100% comprised of contractors with barely adequate coding skills. You don't find yourself in endless meetings about stealing resources from other teams because you don't have the right people on your team. And you don't get put on a project that should take a year and told to make it happen in three months.

Of course, if you said this to Jeff Atwood and Joel Spolsky I suspect they'd tell you one of two things. That you just have to stick to your principles and affect change or that you leave wherever it is you're at and find a company that supports your principals.

I don't disagree with that. But reality is far more nuanced. At least with many blogs, it's made to sound so easy. You rarely get ones about how things failed utterly or completely. This blog is for all the people who've *tried* to change things, but see little progress. The people who like me, don't want to just *leave* because, hey, I get paid pretty well and I like my shiny new M3.

Sure, you can chalk that up to me being a crappy agent of change or risk-averse, because I refuse to leave. I suppose I'm complicity in my own misery. But then I have to think there are bunch of people in the same position as me. People who read joelonsoftware and come away going "Okay, that's great. But what the hell does that have to do with what *I* experience"

This is the blog for them.

Now, that's not to say I might not say some of the same things. But I hope the difference is, I won't gloss over the reality. I'll give a bit of an insight into the total soul crushing inertia and the learned helplessness that I think most of us live with. I'll share my own Sisyphusian attempts to change things and hopefully occassionally I'll be able to tell you about something that really worked. But more often than not I suspect I'll be telling you about my failures.

You don't go back and rack your brain over and over after winning. You move on. "What is won too easiliy is esteemed too lightly." as the quote goes. We learn more from failure than we ever do from winning.

And this is a blog about failure.

7 comments:

Dantelope said...

I assume at some point there will actually BE a post about a failure? :)

Looking forward to some discussion... these are harsh realities and I agree -- too often they are overlooked. I suspect this is because they are "soft" (human) issues rather than "process" issues. Dealing with people can't be easily analyzed or explained in a book; each interactive complexity is entirely unique.

Adam said...

A blog about failure? I should naturally be a contributing author. My life defines failure, in both professional and personal ways.

Yesterday it took me 30 minutes to figure out where I need to insert a line of code. When I inserted it, the library failed to compile. It took me another 10 minutes to figure out why.

Last week, I did a code review for a coworker. Granted, a reviewer can't be held to the same responsibility as the author/tester of said code. However, upon deployment, the changed managed to bring down a fairly important internal service.

Two weeks ago at the gym, I got asked if I'm there to lose weight.

Failure seems so natural, especially in the workplace. I have yet to experience working for a company where the code doesn't suck, people don't make mistakes, and things don't get broken left and right despite unit tests and monitoring.

Welcome to the internet. I'll bring the string cheese.

Code Monkey said...

@Adam

Haha. Feel free to contribute. My intesnt is just to catalog failure of course, it's about learning from those failures or at the very least recognizing what caused the failures to occur.

That goes beyond just the "People are dumb" explanation too (I'll leave that to the thedailywtf.com). Having dumb people is not actionable, except i nthe broadest sense of firing them (or preferably not hiring them).

Also, if you actaully have unit tests, you're probably ahead of 90% of the code base in existence.

Code Monkey said...

@Dantelope

Fair point. Blogging about blogging (i.e. meta-blogging) is kind of a masturbatory exercise. But I did feel the need to point out that an awful lot of the pundits on the Internet seem to live in a completely different world than I do. That has some very profound implications as to how much weight their advice should be given IMO (Not saying it's not still informed, it just is informed by different factors than I see).

Yes, there will be real posts about failures: organization failures, my own failures, other peoples' failures. It'll be a failure-extravaganza.

Unknown said...

Careful this is a quick way to be labeled permanently as a malcontent. Sometimes you gotta look on the sunny side.

On the sunny side my word verification is poomzzin which is awesome.

Code Monkey said...

@shinierball

It's not meant that way really. As I touched on in a response to tedley from a previous blog, I tend to make very broad statements in an attempt to make a point but sometimes this disguise the nuance of my actual thinking.

The blog isn't *solely* about failure, it's just more that so many things I read online seem to gloss over the details.

I have no doubt people have effectively implemented Scrum in client dominated, deadline-driven companies. But usually the "success stories" you read online gloss over all the really important details that went into making it happen.

That's what I want to talk about. And successes can be important, but so many writers make it seem that if you "just do X" it magically works out. I'm sure in their cases it was just as difficult, but they have to share that, not gloss over it.

Thought I hate myself for saying it, I have come to understand a certain someone's point about "Devil's Advocates" (one has to separate the message from the messenger and the implementation). There is some real negative value generated by always *only* pointing out why things *can't* change.

Joshua DeWald said...

I think it would be good to blog about how you are actually personally handling all the realities of... real life in the corporate (or at least solutions) programming world. I know that you're not in fact a failure despite the odds, so presenting the issues (as you did in this entry) and how you try to *deal* with them.

At the end of the day, M does produce software that runs portions of other companies' business and it makes money. Something is being done right :) It's just frustrating during the process.