Monday, April 13, 2015

Managing for Software Quality

In my previous post, I said that to be an effective manager, you need to control variation and that the key to managing software development is to control variation in the process.

There are a lot of books about software development processes. Unfortunately, these books are written by software developers. The books are often quite good. Especially if you are a software developer. What they don't address is how to manage a software development project from the perspective of the business itself. They claim that following the process will help the business that uses it, but the perspective is too skewed and the focus is too narrow for someone who isn't a software developer herself to get the information they need to understand the process and to operate the "levers of control" that we learn about in business school.

Here are a few thoughts on the process of writing software. I plan to write about each of these in more detail in subsequent posts.
  1. Hire the very best programmers. The degree of variability in productivity between programmers is nothing short of miraculous. All programmers are not created equal. A small group of three really good programmers beats a dozen average programmers every time.
  2. The development team should be able to demonstrate that their code works by the execution of automated tests that generate a report that you can read and understand.
  3. The process should include code reviews, automated tests and continuous integration. 
  4. Words like "agile" and "waterfall" don't mean anything. Really. 
  5. The architecture should be well-defined and understood by the team.
  6. Design patterns matter. No matter what you are doing, chances are that someone has done it before, learned from their mistakes and then did it again. Listen to their advice.
  7. And the most important rule of all: The fewer the moving parts there are, the fewer the errors there will be. Do the simplest thing that works.
I'm already talking like a software developer and not a business manager. In order to flesh out these ideas, I'll revisit each one and try to put it in terms that make sense to the non-developer.

Sunday, April 05, 2015

How to Manage Software Development

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 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. However, the reason I remember that moment is because that's when I realized that computers were simply another mode of communication and that writing software could simply be another way of writing, an enhanced form of writing that could reach readers (and viewers and listeners) all over the world.

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 meant 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 business, they have to become participants because the company needs it.

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 process, 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 takes exactly like the latte I order from Starbucks in Seattle. One of the fundamental tasks of the Starbucks management team is to make sure my latte tastes the same whenever and wherever I make the purchase.

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. In the case of Starbucks, the reason the lattes taste the same wherever you is because they are made the same way in all of their stores. The variation that is controlled is the variation of the process.

If management is controlling variation, and you're managing a software development project, then the way you manage is by managing the process. The process must be constructed in such a way that each software developer follows the process and the process itself must be built around insuring that the output of the process meets the needs of the consumer.

Software development is a process. In order to manage software development, you have to manage the process. In order to control variation in the outcome of the process, you have to control variation in the process. The process itself must be consistently applied and be rigorous enough to insure compliance by all parties.

Let's think about it this way: imagine you are the Starbucks management team many years ago and you are trying to develop the perfect latte. The way you go about this is that you hire a few folks and tell them to start making lattes.  You've selected these baristas because they have experience making lattes at other companies so you show them how your espresso machines work and tell them that you expect them to be able to make one latte every three minutes.

What's the likelihood of success? Not very good, I'm afraid. And if you can't make the perfect latte by managing the process that why, how can you possibly expect to manage a software development project in the same way?

The key to making a great latte is the same as the key to making great software: you have to manage the process.

I'll write about the process in future posts...