I write software. I started my career working for a newspaper. Now I work for a book publisher. I even once tried to teach humanities graduate students at Georgetown University how to program in Python.
Like many of my colleagues, I have an English degree. I also have an MBA. I was never formally schooled in software development, aside from a few college courses here and there. Nevertheless, software development has been my trade for most of my adult life. I'm pretty good at it and there's always plenty of work to be had.
I've made a career out of being a software developer for companies that aren't software companies -- at least they haven't been software companies historically. The reality is that for these companies the times have changed and software is becoming increasingly important to their bottom line.
If publishers and media companies want to thrive in the future, then they must become better software developers.
I like working for publishers; I love words. I remember the first time I saw an HTML page load in the Mosaic web browser. It was a simple page, primitive by today's standards, but I remember it very clearly.
The reason I remember that moment is because that's when I realized that computers were more than calculators, more than a tool to be used to perform tedious mathematical chores. I think this was the very first time I vividly understood that computers represented a new means of communication. All at once, I realized that writing software was simply another way of writing. It was a wholly new way of writing and one that has inspired great changes in the way we create and communicate with one another.
When I was an undergrad, being a software developer meant getting a job at a bank. It meant writing reports and calculating sales figures for corporations. But in the mid-nineties, being a software developer suddenly could also mean being a communicator, an expresser of creativity, a writer, an artist.
In addition to writing software, I am also a manager and it is my job to manage software developers. Managing the development of software is more than simply managing developers. If it takes a village to raise a child, then it takes a cross-functional team of people to devise, develop and deploy a successful software application.
The problem is this: industries that have not historically been technology companies often do not have the institutional experience to understand and execute a software development project. And the reality is that there are a lot of people in a lot of companies that are tasked with working on software-related projects who have no interest in writing software. A lot of them don't even like to use a computer. But because software is essential to support their work, they have been forced by circumstances to become participants in the process.
It's kind of like eating Kale. It's good for you, but eating it sucks.
I think non-technical managers shouldn't be forced to learn how to write code, but they do need to learn how to participate in the software development process and they need to know enough to manage in a technology-dependent environment.
Here's the problem that occurs when a non-technical person is tasked with managing some aspect of a technical project: They manage what they understand and what they understand is how much money is being spent and how long the process is taking.
Of course, controlling costs and managing schedules are Good Things. The issue is that cost overruns and missed deadlines aren't the problem. They are symptoms of the problem. In order to be an effective participant in, or an effective manager of, a software development project, you need to care about more than how much it costs and how long it's taking.
I have a lot to say about this, but I want to focus now on something my statistics professor told me: Management is controlling variation.
What he meant by this is that one of the essential requirements of a successful product or service is that every time a customer buys your product or service, they get what they are expecting. In other words, when I order a latte in a Starbucks in Manhattan, it tastes exactly like the latte I order from Starbucks in Seattle.
Quality means consistency.
The idea applies to software development, too.
In the case of software, the goal isn't to write the same software over and over again. That's not the kind of variation I'm talking about. The kind of variation that managers of software development need to worry about is variation in the process of software development.
In the case of Starbucks, the reason the lattes taste the same wherever you are, is because they are made the same way in all of their stores. If I get a job at a Starbucks in Seattle, I'm taught to make a latte the same way that I would be taught to make a latte in New York.
Let's think about it this way: imagine you are the Starbucks management team many years ago and you are trying to train new employees in the art of latte making. The way you go about this is that you hire a few folks who are experienced baristas. You start by letting them sample a latte that you've made, and then you explain to them that you expect them to be able to make one latte every three minutes. Then you point them in the direction of the espresso makers and tell them to get to work.
What's the likelihood that all of their lattes will taste the same and be of the same quality? Not very good, I'm afraid. The reason why this is true is that you can't expect people from different backgrounds, with different tastes and experiences, to automatically know how to make a latte that tastes exactly like the latte their barista colleagues are making. In fact, the only way to insure that the lattes always taste the same is to insure that each individual barista follows the exact same steps every time they make a latte.
And if you can't make the perfect latte without managing the process by which lattes are made, how can you possibly expect to manage a software development project without doing the same thing?
The key to making a great latte is the same as the key to making great software: you have to manage the process.