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.
- 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.
- 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.
- The process should include code reviews, automated tests and continuous integration.
- Words like "agile" and "waterfall" don't mean anything. Really.
- The architecture should be well-defined and understood by the team.
- 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.
- 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.