Strategy is a system of expedients; it is more than a mere scholarly discipline. It is the translation of knowledge to practical life, the improvement of the original leading thought in accordance with continually changing situations.
– Helmuth von Moltke the Elder
Ages ago, when I was an intern at Microsoft, I attended a big open lecture given by the (then-president of Microsoft Windows) Steven Sinofsky. Sinofsky waxed philosophical about the organization, his vision for the company, and why Windows 8 was going to crush it. Towards the end, he opened it up for questions. Sitting in the back, my hand shot up and I asked, “Microsoft is famous for Waterfall software development, but these days (2011), all the rage is with Agile technologies. What gives? Why aren’t we, Microsoft, great inventor of the modern software company, using Agile?”
Sinofsky, without missing a beat, answered: “If software development were building bridges, we’re at the point in history where people are chopping down trees to cross rivers.” He believed that it would cost too much to implement this change, and too much about software engineering was still ad-hoc and/or unknown magic, so he couldn’t be sure that the benefits would be worth it.
For years, that viewpoint of how we approach software engineering as a discipline has stuck with me. Chopping down trees. Looking around in the forest, finding something that can get the job done, doing it quickly and cleanly, then bravely walking across the flowing rapids.
Before getting back into coding this summer, I had decided that I was going to engineer our web application architecture from the ground up. I was going to make plans for exactly how I wanted our project to be built and deployed. In fact, it would be so perfectly documented, automated, and repeatable that all you would need was a repository with a README and a one-click AWS CodeStar environment, and SmarterCloud would work.
Getting back into it though, I’ve discovered that this is nearly impossible in modern software environments. My intentions were good. My start was promising. But before long, I was adding custom configurations for my load balancers, downloading third party tools locally to my machine and invoking them in my build system, and doing all the things I promised I wouldn’t.
Don’t get me wrong, things have gotten much much better in the last decade (since back when I had to implement my own CSS grid system in college). But one major irony I learned in my life as a software engineer was that I wasn’t really an engineer. I mean, let’s be honest: what civil engineers can use multiple hemorrhaging-edge paving techniques to build our bridges? A lot fewer people would survive the daily commute if they did.
I’m encouraged by the open source movement and the stellar projects I’ve been using to help build SmarterCloud. Projects like Galen and Codacy have great open-source support and the ability to be quickly and easily extended. These products have employed software strategy well, and combined it with strong leadership to keep quality high. But still, with all the tools I’ve interacted with or built I’m reminded of Von Moltke’s other, more famous quote: “No plan survives contact with the enemy.”
So here’s my outlook: if you are building a product, or hiring developers to build it for you, understand that there is software engineering is still 90% art and only 10% science. Have patience with software, and put more of an emphasis on quality. That way, if you aim high and provide ample time for work to get done, when tradeoffs inevitably have to be made the ramifications won’t be catastrophic.
EDIT: There’s a great piece from Dr. Dobb’s I encountered from HackerNews that speaks to this subject in a more scientific way that’s worth the read.