From the metrics on this blog, I see that many of you are either software developers or are database administrators involved with developing software solutions, either for your own company or for sale. I have often seen the process of creating applications called “Software Engineering”. In fact, in the U.S,, Microsoft programmers are called “Software Development Engineers”. You cannot use this term in some countries, since “Engineer” is used to denote a specific certification recognized by the government. (I kind of like that, but I wouldn’t refuse the people here the title)
Regardless of the political baggage, I’ve often thought about development in Engineering terms. I’ve worked in Engineering companies before, such as NASA and a pharmaceutical company, and the disciplines and processes I learned there fit nicely with how I learned to write code. However, as I was watching “How it’s made” on Television last evening for a few minutes, I began to see parallels with software development and distribution (that last part is key) and the manufacturing process. I’ve also worked in large and small manufacturing shops (yeah, I’ve had a lot of jobs), and now I’m not sure which term to use.
Here are the arguments for each: The dictionary tells us that engineering is “the application of science in the design, planning, construction, and maintenance of buildings, machines, and other manufactured things”. Interestingly, a synonym of engineering is – Manufacturing! The argument for an engineering analogy for software is a great deal of research, thought, preparation, planning and design work. The argument against using that analogy is that there is little regulation, and the science required for modern software development is not normally anywhere near what is involved in engineering.
On the “Manufacturing” side of the argument, the shade of meaning is a little different. The dictionary says that manufacturing is “transitive and intransitive verb – to make something into a finished product using raw materials, especially on a large industrial scale”. Normally a series of machines automate the manual steps in changing some raw material into a usable good. There are strict processes that must be followed to ensure consistency, safety and quality. There are machines at the end of the row, bay, or area that perform automatic tests on the finished good before it goes out. The process is very automated, mechanized and routine.
I think at least the holistic end-to-end view of the manufacturing process fits well for software. True, we do not have the same physical objects we work on, but when you think about it, our “manufacturing machines” are really the high-end languages we use. We have standardized blocks of code we use for quality and consistency. We have automated and manual testing at the end of the process. The argument against a manufacturing analogy is that our development is not as automated, since each application is a “one-off” object.
Perhaps it does not really matter, or perhaps neither of these terms is completely accurate. I think that the true “development” of software is in fact an engineering exercise, and the creation and distribution processes have a lot to do with manufacturing. I do think it matters to have a paradigm in mind, because all of the research over humanity’s history can be leveraged by a new discipline like ours to jumpstart our processes and help us develop our practices by learning from others. If you don’t agree, then I invite you to do a study of the manufacturing process and engineering disciplines and see if there are any ideas you can adapt to your own work today. I’ll wager you’ll find out that there are some real benefits in each that will give you practical guidance. It has for me.