A few years ago I had a job where every new recruit would go through a long process of shock and gradual acclimatisation to the main software product.
What it did doesn’t matter as much as how it was built: it was an application developed on top of a proprietary programming language and user interface designer. The reaction was always the same. Why? Why?! Why would you reinvent Visual Basic on Unix? Why would you inflict a programming language even worse than Basic on developers?1
The whole team got this email today. Okay, it wasn’t today and these are not the exact words, but it was something like this:
We have a serious regression in build 456. We have set the project back rather than taken it forward. We need the utmost focus and commitment on fixing it. We’ve broken it and we stay in the office until it’s fixed.
I’ve had a few of those messages over the years and while it’s intended to focus minds it often has the opposite effect. Let’s examine why.
With the fuss about the Log4Shell vulnerability finally dying down, it’s time to step back and take a good, long think about what happened and, more importantly, what can be done to stop it from happening again.
Sadly the prognosis is not good. The tl;dr is both simple and obvious: we simultaneously like free stuff and getting paid for our own work.
Most companies treat open source software exactly the same as commercial software but with a much lower purchase cost. When the software goes wrong, we want someone else to fix it for us. Unfortunately, sometimes we don’t even know where the software comes from. In the case of log4j, it’s run by volunteers. There is no 24/7 help desk with eager employees waiting to take your call.
As is common these days, I was complaining about something on Twitter.
https://twitter.com/sdarlington/status/1523588282986033152
It’s easy to complain about security practices which, if I’m honest, is why I do it. But there is an important point, one that I included in a follow-up tweet:
https://twitter.com/sdarlington/status/1523602044791115776?s=61&t=69wO28ER8NUpssCyeNkqJw
The security team in many companies models itself on the DUP. Say no to everything. But – and this is the key – offer no alternative.
Before you ask, yes, it is weird that I’m reading a bunch of “management” books.
You can watch Michael Lopp’s career by following his various books. Start with “Being Geek,” the software developer’s career handbook. The move into management resulted in “Managing Humans.” And his promotion from manager to director and executive gets you “The Art of Leadership,” which is the book I recently finished.
My career has not followed the same trajectory. I continue to be an “individual contributor,” so why would I read this book?
A couple of years ago I did a conference talk called “On Cloud Nine: How to be happy migrating your in-memory computing platform to the cloud.” I wish I’d had “Cloud Without Compromise” back then. It covers much of the same ground but, as you’d expect in a book rather than a forty minute conference talk, in much greater depth. More importantly, it puts some concepts into context much more clearly that I did, either by explaining it better or by giving it a good name.
I’m still fascinated by the computers of the eighties. Without well known standards, every machine was different, not only from those of other manufacturers but also older machines from the same company. As as user it was terrible. Back the wrong horse and you’d be stuck with a working computer with no software and no one else to share your disappointment with.
But looking back, there’s a huge diversity of ideas all leaping onto the market in just a few years. Naturally, some of those ideas were terrible. Many machines were rushed and buggy, precisely because there was so much competition. Going on sale at the right time could make or break a machine.
After university, when I first started working, I jealously noticed people leaving their desks and attending meetings. I was left sitting at my desk, bashing out code. What was going on? What exciting things were being discussed without me? Sometimes they’d come back from the meeting and ask a random question. It was all very mysterious.
A while later I started getting invited to these meetings. I found what was being discussed. I discovered the mystery.
Here’s something I’ve seen a few times recently: a startup issues a patch for a critical issue seen by one of their large customers. The “enterprise,” however, takes a week to install and test it. Clearly, the startup concludes, if it takes a week to try a patch it can’t be that urgent or the staff are dumb, or, quite likely, both.
When I see a company that has an “innovation team” or a “chief innovation officer” I immediately understand that it’s not the kind of company I want to work for.
Innovation isn’t found in a particular team, person or department. It’s your culture.
If you need a special team outside the normal management structure to innovate, what does that say?