Competitive Engineering

Of course every engineer wants to be competitive, in the sense of delivering value that succeeds in the marketplace, right? The best teams to work on (and any team that I’d jump to join) strive to be the best at what they do.

We pride ourselves at coming up with the best designs possible within short time frames, at working in realms where the requirements are partly or poorly understood, and somehow coming through anyway. We code defensively, follow good OO principles, use design patterns, and drive our development with unit test.

And we do all this not quite knowing how the market is going to evolve while we work, or what the competition is up to.

“Agile” is quite a popular term these days, even le buzzword du jour. When The Agile Manifesto came out, I read it with some excitement and hope, but then increasingly with a tinge of disappointment. It’s authors got carried away, over-emphasizing the novelty of their techniques, and in so doing failed to learn some of the lessons that hard experience in iterative systems engineering could have taught. It should be a clue when a methodology labels itself ‘extreme’ that it isn’t emphacizing balance.

And yet, isn’t dynamic balance at the core of what living, even life itself, is all about? We could think of running, and even walking, as graceful, rhythmic not-quite-falling. Making progress depends on a balance between falling forward and standing upright.

The metaphor applies to engineering as well. We need to balance our ‘heads-down-and-go’ focus on code with a ‘heads-up’ vision of what’s coming and where we need to end up.

In time, the foundations of agile processes have become clearer, and some of the debt to earlier practitioners has been acknowledged from time to time.

My take on what it takes to give a team the edge it needs to succeed in this environment has been strongly influenced by Tom Gilb and his “evo” or “competitive engineering” practices which have their roots in systems engineering. I select from his work what I think is best for the team and project I’m on at the moment, and bring in many other factors as well such as test-driven development, domain model driven design, patterns, and so on.

But the bottom line is this: let’s utilize the tools and techniques and, yes, processes, lightly, with a common-sense eye for what works, and with a practiced sense of perspective while we do it. Let’s balance getting done what needs to be done right now with doing it in a way that maintains and even improves our ability to be competitive on the next project.

In other pages and posts on this blog I’ll discuss particular techniques. The larger framework, however remains Competitive Engineering, in the larger sense of the term.

Advertisement