ShopTalk Blog

I knew that being an entrepreneur would involve becoming product-focused instead of engineering-focused. But I've spent so much of my life shaping my brain around the discipline of programming and system architecture that it's requiring a concerted effort to keep the product and its users' interests foremost in my mind. It's just so easy to fall back on old priorities and practices--especially when they're as elegant and easily validated as these particular ones are.

See, problem-solving in the realm of code usually wraps itself up into neat little packages:

1. A requirement exists
2. A system design is established/extended to support it
3. That design is implemented
4. Validation is done to ensure that the requirement has been satisfied

Make sense? Great. Now, for the sake of clarity, allow me one extended hamburger metaphor. Let's call that nice little endorphin-releasing four-step process the hamburger patty.

If only the world were all patties... no carbs! But it's not quite that simple:

1. Gather user feedback, do user studies, maybe talk to company stakeholders, weight everyone's priorities, maybe make enemies
2. Elect and spec some requirements as The Ones We're Going With Right Now
3. patty()¹
4. Deploy said requirements and desperately try to measure their effectiveness (assuming you actually figured out what their goal was in the first place)

There's a quite a bit of messy, but critical stuff in that bun. When you're all patty, you're missing a lot of the burger.²

"But I'm bought into all that!" Joe Hacker says from his cube at Big-Widget-Co. "I'm sympathetic to the product design part of the process!"

Yeah, in your regular coding gig, you might be in a few bun meetings... but if you're anything like me, you're probably sitting there thinking "arg, this crap is really gonna screw up my patty!"

Well, I'm a bun man now, Joe.³ There are no longer proxies between the user's satisfaction and my paycheck. They have the credit cards, and they don't know or care if my functions fit under one hand, if I used a recursive or imperative approach to that algorithm, or if an armadillo is frantically doing modular arithmetic in the machine room. They just want the software to satisfy some subset of their needs vastly more effectively than their existing methods. And "effective" usually has more to do with UI than OO.

The sad realization is that in most cases the code only has to be good enough to be extensible (we can add features!) and not break publicly (we won't embarrass ourselves).⁴ But the quality of the product experience has a direct impact on the company's success.

In the well-known essay The Rise of Worse is Better, Richard Gabriel argues that in commercial programming, pragmatism has for all practical purposes won the battle against purity. "The right thing" philosophy is dead or dying--take your pick.

But I'm not sure that's the whole story--it seems to me we now recognize that "the right thing" is better applied in that space where the user actually notices.