Software engineering is one of those semi-mathematical technical professions that is just chock full of numbers. Our machines run at so many gigahertz and produce some exact number of mega-flops. We have deal in the hard physical reality of memory in kilobytes and the more ethereal idea of so many big O’s for each sub N. But I’ve been thinking that there are some numbers that we have been neglecting. For example:
The optimum number of software engineers that can collaborate on a single project. As Fred Brooks pointed out long ago, people are simultaneously the power source and one of the main impediments to writing code. Add some more people to your project and they might make things spin faster, but more people can also slow progress down, since more people means more meetings, more memos and more misunderstandings. I know that there are lots of projects out there that require more than three people, but I do think that three is an optimal point on the curve.
The number of uniquely correct solutions to any given software problem. The key word here is ‘uniquely’: Just about all real word problems have many fine solutions, not just one. The belief that my solution is the one true way is almost certainly wrong and is quite likely to drive down another important figure: the number of working solutions that we actually manage to produce.
The number of incorrect solutions to any given software problem. Just because I think that are many good solutions doesn’t mean that yours happens to be one of them.
An estimate of the number of ways that any given programming problem might be solved, at least within the borders of the United States. As it happens, there are also about half a million coders working in the US at the moment. This estimate might be high, since not every coder will have an opinion on every problem. On the other hand it might be low: I tend to change my mind six times before lunch. On a good day.
Six hundred and twenty five is approximately the number of programming languages found on wikipedia list of programming languages. Lately I have been playing with Erlang which is a functional programming language designed for concurrency. It is such a weird language that I’ve nearly given up three or four times, but I have each time I come back to it with that – Oh, I see! – feeling. At this point the jury in my head (it’s amazing we can all fit in there) is still out, but I am sure of one thing: learning about Erlang has changed the way that I think about programs and computing, changed it in some subtle ways.
But Erlang is just one of 625 and each of those languages represents a unique view of the computing terrain as well as a vehicle for crossing that terrain. Most of those 625 languages are destined to live out their lives in well deserved obscurity, but taken as a group they sum up much of the thinking that we have done in the past half century on how to build programs. Have you learned a new language lately?
The number of programmers who will write most of the code in a system developed by a team of 24 engineers, two project managers, three group leaders, a quality lead and an office manager.