Please don't mug me

My mind was wandering this morning and it dawned on me that I carry a ridiculous wealth of electronics in my backpack when I travel:

+ Take.TV, 4GB, $100

+ DS Lite, $150 (with at least $100 in games)

+ PSP, $170 (with at least $100 in games)

+ iPod Nano, 4GB, 2nd gen., $250

+ Amazon Kindle, $400

+ Macbook Pro, 15", refurb. w/ram upgrade, $2500

Unless my math is wrong -- and keep in mind my degree is in music composition, so it's well withing the realm of likelihood -- that sums up to nearly $4,000, not accounting for depreciation.

Lest you get the wrong impression that I'm mister moneybags, all but the laptop were gifts.

Here's to hoping none of my faithful readers are tempted to mug me at the next convention.

Book Review: Dreaming in Code

I'm probably not the first (or the last) person to say Dreaming in Code is the Soul of a New Machine for my generation. The author chronicles the trials and tribulations of a fledgling start-up struggling to develop a piece of software that will change the world. Sound familiar? Yeah, that's pretty much the mission statement of every software start-up I've come across in the last decade and a half.

Unfortunately, these guys have it all messed up right out of the gate. Where most companies start out with a gung-ho entrepreneur and investors and profit expectations, this company starts out with a "socially responsible" "thought leader" philanthropist who has enough money from former successes (Lotus 1-2-3) to fund the venture himself and whose primary goals are to be open source and leverage peer to peer technology. The founder rounds up a few like-minded geniuses from his past endeavors and they start thinking about what to develop.

What happens when you get a bunch of "thinkers" in a room together? You have endless hours of thought-provoking intellectually-stimulating conversation and debates and draw lots of neat diagrams on the white board, hypothesizing solutions to the problems with software design which have have plagued the industry for decades... then you poke your head out of the conference room one day and realize a couple years have passed and you haven't written a single line of code. Been there, done that, have the worthless stock certificates framed and hanging on my office wall as a reminder of a hard-learned lesson.

The company eventually has to come to terms with developing and delivering software, meeting deadlines, making compromises, dealing with feature creep, and the whole gamut of "business as usual" debacles, and that's where things start to get interesting. But, sadly, the author's seemingly self-imposed three-year deadline for going to press came a lot sooner than the launch of the product he was chronicling. On an amusingly serendipitous note, the project in question popped into the news while I was writing this review. The article notes, "It's still very early beta, and there's a lot of polish missing from the current builds." So there's sadly no closure in the book.

Nevertheless, it's a good read. It starts strong, and the author peppers the biographical chapters with tangents on the philosophies of other big wigs in the software industry, trying to tie them all together into a sort of moral tale on how "software is hard" and we're doomed to never really master it. I don't agree with those sentiments, but he covers the topics well in an unbiased manner.

Quotables

In a tense meeting late last night, I had to stifle a laugh when the quality assurance director asked the president, "Which one do you want to control: requirements or delivery date? I control the other one."

Wait for the third one-off to build the framework

I have quite a talented and ambitious young crew working for me, and they're always chomping at the bit to show off their skills at using and abusing design patterns. I used to be the same way... a decade ago, now that I think of it. Wow. Give me a second to catch my breath; that knocked the wind out of me.

Now that I'm the stuffy old boss, I have to see the big picture, look out for the greater good, consider long-term goals, and all those other enterprise-y cliches. With that in mind, there's one mole that keeps popping up no matter how many times I whack it: the "let's build a framework" mentality.

We are an ASP. We host a centralized service that multiple clients integrate into their web sites. All of the clients reference the same code on the same servers. Whenever a client calls us up and wants to alter the way a feature looks or works, we have to create a branch in the code to accommodate them. Since all clients call the same code, that branch has to be tested across all clients. These "one-offs" have a high risk factor which increases as we accept more clients.

The way I run my shop, I hand these projects off to my developers to think up a solution and pitch it back to me (before they write a line of code). Rather than acting as the architectural overload, handing down designs like stone tablets, I give them a chance to show me what they're made of.

In most cases, the young whippersnappers use every one-off as an excuse to abstract the discrepant functionality into a full-blown framework. They come into my office and start drawing boxes and lines on my board. Factories here, Inversion of Control there, a sprinkle of Singletons and a dash of Decorators, throw in a Composite for good measure. I sit there quietly and hear them out. Then I ask the questions they dread to hear:

"Is this the first one-off for this feature?"

Yes.

"Can this be handled by a simple little if-else clause?"

Yes.

"Do you understand how the introduction of a new framework will complicate testing now, maintenance later, and the learning curve for new hires?"

Yes.

I remember the countless times I was on the other end of that inquisition. It's tough to swallow. But business and business, and we're not in the business of building cool new frameworks, we're in the business of delivering solid software on schedule. However, there is a light at the end of the tunnel.

Were they to answer the first question, "no, this isn't the first one-off for this feature," then it's a whole other story. Three is the magic number. When two clients want two different behaviors, an if-else branch is sufficient. But when the third one comes along, it's time to start talking abstraction.

Three is the threshold where you need to start asking if these are different variations on the same theme, or perhaps a new theme altogether? How flexible does this feature need to be, or can it be, before you have to break it into different features for the sake of sanity, clarity, testing, and maintenance? There are features in our system which are incredibly abstract, so much so that they differ for every single client. And, there are features in our system where the client's request was so far from the mark we had to create a completely separate version, essentially giving us sibling features that live side by side.

There's a time and place for abstraction and frameworks, but when a simple if-else clause will do the trick, be done with it and move on.

Book Review: Maverick

Maverick: The Success Story Behind the World's Most Unusual Workplace is the autobiographical braggadocio of Ricardo Semler and his Brazilian company Semco. Long story short: rebel son inherits company from traditional father and turns it into Willy Wonka's Chocolate Factory where the employees set their own hours and their own salaries and there's no org charts and no secretaries and everybody rides a unicorn to work. OK, that might be a bit of a hyperbole, but you get the gist of it.

After suffering a perspective-on-life-changing physical breakdown, Semler decides to break all the rules, think outside of the box, try new things, and manages to create a rather unique workplace where employee morale is high, turnover is low, changes are quick and painless, and tough financial times don't require drastic downsizing... as long as all the employees vote on it.

It's a rather impressive tale, but I took it with a grain of salt. I know Semler's type. Or, to be fair, I should say that I know guys that talk the way Semler writes. They are successful self-made men and to listen to them talk you'd believe they can do no wrong and everything good in their lives and their company's history has been the direct result of their foresight and perseverance, but they seem to gloss over the bad stuff and completely omit the really embarrassing screw-ups.

But all cynicism aside, the book is an entertaining read, and I do recommend it. Semler is a solid writer and weaves a good tale. The chapters are very short easily-consumed parables. Who knows, after reading it, you might be able to convince your boss to let you set your own salary and work hours.

As an aside, Semco is very much a blue-collar business, responsible for manufacturing industrial machinery for shipyards and biscuit factories -- I wonder how Semler's ideologies would fare in a large software company.