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.

My New Year's Resolution: Heal My Department

There's a bit of a schism in my department. Earlier in the year a silver tongued consultant slithered into my organization under the covers of an unrelated project and in the blink of an eye convinced the president the the board that the B2C side of my operation could be rebuilt from scratch on an antiquated framework by an off-shore team. The next thing I knew I was running half a department (the remaining B2B side).

The tale is as old as time and history has repeated itself a million times over. For some inexplicable reason, the powers that be always trust an outsider more than an insider. I was the harbinger of doom. I recounted to horror stories of off-shore teams. I demonstrated the deficiencies of the framework. But it was all for naught. The checks were signed and the gears were put into motion.

Fast forward to tonight. The project is months behind schedule. The code is a steaming pile of fecal matter. Half of my remaining in-house department is working themselves to exhaustion into the wee hours of the night, including weekends, trying desperately to save it. They're likely to work through X-mas and New Years. For the sake of "delivering on time" they've cut all "non-essential" steps out of the process, like formal requirements, unit testing, peer code review, etc. It's the infamous IT death march.

Come the turn of the year, the contracts are up. The consultant and the off-shore team will be sent on their merry way, and I'll be left to clean up their mess. Lucky me. But I'm up to the task. I've demonstrated with the B2B team (the half of the department that remained under my control) that I can deliver projects successfully without sacrificing the process and people. I can fix the B2C side, and make the department whole again.

Let the healing begin.

Programmers aren't the only people that need requirements

I'm a proud member of the Starbucks army. I find myself procuring their fine beverages pretty much every day of the week.

Starbucks has this pretty crude but normally effective "requirements" policy where drink order specifications are written right on the cup into which the libation will be prepared and served.

Now I'm not one of those riffraffs that consumes my coffee cocktails out of plastic or paper vessels -- I provide my own thermos (Starbucks branded, of course). They even give me a discount for using it. That's just how I roll.

However, my eccentricities come at a cost. Starbucks is wise enough to not scrawl my order on the side of my thermos, and thus the barista is left to his or her own wits to remember my order... and they get it wrong... every... single... time...