What separates software engineers from programmers? I'm not talking about the job title here (because some people have hijacked it), I'm talking about a person that thinks about software from an engineering point of view. What's different between how he thinks of a solution to a customer's problem and how a programmer might think of a solution to the same problem?

Software engineers like my classmates and I were trained (at least given a solid introduction) in software project management and quality assurance. Honestly, these two subjects can and do take the fun out of programming but they also give valuable perspective to a software engineer. As far as your customer is concerned software isn't fun, it's actually costing them a lot of money. They want you to be effective, maybe happy and then you can have fun if you have time between milestones.

This, I think, is somewhat difficult for programmers to swallow. A lot of these programmers started out writing code in their spare time for fun and now they have to do the same type of work in a clinical, bug-sterilized and heavily monitored environment. It's completely different than their hacking at home. It's not much fun, it's hierarchial. It's responsible.

A software project manager worth his salt will try to monitor the heck out of his project because you can't control what you aren't measuring. That's a pretty basic control engineering concept I learned back in one of my electrical engineering classes.

The software engineer may understand the reasons for all of this monitoring better, though it may not make him a happy programmer per se. People want control over their work, room to be creative or innovative and most of all: they want to be trusted. They want responsibility as well as a challenge. Monitoring the unit test suite and blaming someone when the build breaks is not that trusting, to be honest. But it's engineering and this is the way the profession is heading.

Bridge building one thousand years ago may have been a casual affair but today it's taken quite seriously and is probably a monotonous and well-scripted task with expected checks and double-checks and triple-checks and balances. There are still people going into civil engineering even though they expect this, so it can't be all that bad of a future for software engineering.

How do you keep free-spirited programmers happier in an environment that needs high quality and thus, heavy monitoring? The trick as a software project manager may be to examine the project as a whole and divide it into pieces based on quality requirements and/or code complexity and/or testability. Then monitor (very important) the code quality using unit testing results, code coverage tools or profilers, etc. The bug-reporting database should also be monitored to see which of the pieces gets the most bug reports in an iteration, which is most fragile, which changes the most (code turnover can mean more defects) and factor those numbers in as well.

Then the project manager will know where the critical pieces of the software are and what state of health they are in at any given time. He'll also know where the less-critical areas are, and give people more freedom in those areas. If a piece suddenly becomes very unhealthy, the project manager should know right away from his monitoring and start some corrective action. Allowing for a certain degree of experimentation and creativity can solve problems in new ways, which is good too. Knowing where to allow creativity and flexibility is important.

Strictly from an engineering point of view though, monitoring the health of your project can lower your overall project risk and also put you in a position to take further risks (like large refactorings or whole component replacements) as well. But first you have to be testing your application in order to gather numbers to monitor project health.

You are testing, aren't you?