Software Engineer vs. Software Developer
The whole Software Engineer vs. Software Developer debate fascinates me. A lot of the arguments I hear/read seem to focus on the maturity of software development. The main argument being that software development is/isn't mature.
My father worked as a Chemical Engineer for Dow Chemical for 26+ years. To me he is an engineer. If I went to him and ask can you tell me how to convert raw crude oil to low grade automotive gas he could come back with a formula that would do it:
g = crude/(inputA * inputB) * heat 175 degrees (an example only)
In reality of course it isn't that simple, but it would be a formula. Now If I ask 'is that the only way to do it?' His response would be that yes, otherwise the formula wouldn't work. Now you could create a new formula, but the industry has adopted this one because it is the most efficient/least risky/etc.
Now take that question to a software developer. One of the first things the developer is going to want to know is where is he going to get the data? Is it coming from a DB, an end user, what? What types of object(s) are going to represent the data? Will I have to convert it from/to something? To the Chemical Engineer these questions don't matter. He has an abstract problem and has given an abstract solution. To a developer it is a concrete problem. He must know where the data comes from, what form it will take.
To me the two engineers are operating in completely different spaces. The software engineer rarely deals in the abstract yet the chemical engineer can do it fairly easily.
So what does that say about maturity? Well, not much really, but lets explore it a little further. To the chemical engineer this formula represents how you do this process. The industry has adopted it because failure to do so can have dire consequences (safety, revenue). The software engineer might not want to adopt the "standard". Maybe he is in a commodity market so cost is about as low as it will go. Now if he can speed up the algorithm by 20% with a 5% failure rate that may within his tolerance. No one is going to get killed and if the results are outside of tolerance he can always recalculate. It is a win. You simply can't do that with real physical product.
Now what about the software factories approach? To me software factories represent the mature sort of model. The developer is told we need to make crude oil. Go get the crude oil algorithm and then put a really fancy UI on it so that we can differentiate ourselves. The point is that the developer is using a known and predefined set of code. Instead of worrying about rebuilding the algorithm he is creating a better product/UI.
By that definition I would say that software development is mature; after all there are reams and reams of code already written and available that solve almost all everyday common problems, but that code is rarely used. The problem is that we work with numbers/code not physical items. The constraints that drove adoption of a single approach in the physical engineering sciences don't necessarily mean as much in software. As long as companies believe they can drive value out of customization/optimization of well known problems I don't see how we will ever get to the factories approach. That's too bad, because I think it has a lot of merit.