At a recent conference, Alan Cooper, the father of the Visual Basic programming language, made the following statement: “The act of constructing software is, in fact, not an engineering process. Engineering to me is problem-solving, which is very different from solution implementations, which is what programmers [do].” [see this Infoworld article for the details]

Cooper’s definition of engineering as problem-solving is probably a good one. There is a clear distinction between “coding” and “problem-solving”, but as an engineer (software currently, electrical formerly), I believe that what I do in software is engineering. My job is not just to design a solution but to implement it, sometimes fully, sometimes up to the point where someone else can pick up the process. The key difference here is that typical engineering of atoms results in a manufacturing process, a line the clearly the separates the engineering process from the production process. In the world of bits, that line is not so obvious. So a certain percentage of software is “problem-solving” — bread boarding, prototyping, building version 1 — and another percentage is “manufacturing” — building UI features, some product enhancements, etc.

Cooper’s perspective is probably based on the idea that all software is designed by architects and engineers and that coders type in the program code like the proverbial monkeys attempting to produce Shakespeare. Mostly this isn’t true. Programmers are always working on solving problems since software production is fractal — macro problems break up into smaller problems. Even component-based development doesn’t eliminate problem solving as part of the process. If that were the case, then building software would be like building houses — just stack up the bricks (components) and a house (application) would pop out. Of course, that isn’t how things work. It doesn’t work that way for silicon either. Electrical engineers today use all sorts of silicon compilers and component technology and they are still considered engineers.

Web developers exist on a different level. Those who are primarily responsible for designing web content probably fall more into the category of content designers than software engineers. There job isn’t to create software to solve a particular problem set — rather, they need to create the most appropriate layout for a page of content. The programming language is no more relevant to them than it is to a print press typesetter. On the other hand, those who use the web fundamentally as a user interface to access some other problem solution are software engineers.

This really brings us to the trickiest part of all of this — what is a “problem”? Of course, there’s no real answer to this. The key is to make a qualitative distinction between the trivial and non-trivial. Trivial problems have obvious solutions, non-trivial ones don’t. If the problem is assessed to be non-trivial, then it is probably a problem in the engineering sense of the word. Setting up a web log is a trivial problem with obvious solutions. Designing and implementing a software system that asynchronously replicates files between systems is not. The distinction here should be clear — the latter requires software engineering to create a solution. The former doesn’t.

In my opinion, use of the title “software engineer” is appropriate. The problem solving using software is just as real an engineering task as using atoms to solve a problem. Software development, like development of electronics, is a large combination of tasks, some mundane (coding simple functions, wire wrapping a prototype) and some not. But in now way should the production of software be trivialized as solution implementation when real problem solving occurs.