Karl Gallagher (selenite) wrote,
Karl Gallagher

  • Mood:

Licensing Software Engineers

I just finished reading my birthday present from bkseiver and rlseiver, Steve McConnell's Professional Software Development. It's a good book with a lot of useful advice on how to run software projects. But one axe he wants to grind with it is pushing a licensing regime for software engineers. That I'm not so sure about.

I'm all for developing better methods for building software, and engineering is a good model for that. But let's not get carried away with the formality of it all. Real engineering has a lot of craft and artistry in it. Some people try to pretend it's all science, especially in academia, but that doesn't survive real-world problems.

One way that some software people want to be more like "real engineers" is getting licenses along the lines of the "Professional Engineer" licenses awarded by states. A PE signs off on the design of bridge or other structure, formally taking responsibility for its quality. McConnell wants software PEs to be the leaders in their organizations, enforcing the processes needed to produce good software. These are very different things.

I work in an engineering field--aerospace--that has hardly any PEs. I'm not sure how many because it doesn't come up as part of the job. We don't have a single engineer stamping a design document as the end of the process. This is a team project, with multiple layers of review on a design. Once the designer's boss approves it there'll be a design review of the subsystem (and higher levels). Then when it's built there's formal testing to make sure it works as performed. This is something you usually can't do with a bridge. Sure, you could drive heavier trucks over it until it breaks and then rebuild it. But that doesn't answer how well it'll stand up to peak windstorms and twenty years of rust. You have to design it right.

Bridges, buildings, generators, and other standalone devices often are designed by one or a handful of engineers. Without extensive reviews or comprehensive testing to wring out the design you have to have a person, not an organization, accept responsibility. That's what the PE license is for. An engineer who is the last word on a design because there aren't any other engineers around to back him up. The government takes a hand in approving licenses because bad engineering gets people killed.

Now which of those models is McConnell's vision of proper software development (i.e., the first sixteen chapters of the book) closer to? Clearly the aerospace model. Lots of teamwork, reviews of designs, and extensive testing. No individual is going to be the sole word on the quality of the code. If there's no document to be stamped, what's the point of the PE? Just a way to proclaim some engineers better than others. That can be done without dragging the government into the process.

(And if you think I'm hostile to the idea, try Tom DeMarco's take on it. He clearly thinks "Those who can do, those who can't teach, those who can't teach administrate" and sees licensing as a power-grab by the administrators.)
Tags: books, engineering
  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
Have you seen this book on software development:
Software Development for Small Teams: A RUP-Centric Approach?

The development team to which I belong is doing a "group read" of this book. We've just started. Bear in mind that this group has 10 members. Currently, one is located in Vancouver, BC, one in Seattle, WA, one in NJ somewhere, one in Quincy MA, one (just hired) in FL somewhere, one north of Toronto, ON, and three in Mississauga, ON (in two different locations). All but one of us work out of home offices.

Suggested books, along with comments about why they are suggested, would be welcome!
I'm not sure I'd have that much useful for your group--my software experience is in custom-built analysis tools or doing requirements for multi-billion dollar architectures. Doesn't give me much experience to judge the practical advice books. That said, here's a few I consider worth reading:

The classics are Peopleware and The Mythical Man-Month. Peopleware may be particuarly useful in discussing how to make your group a cohesive team.

I'm fond of disaster stories as reminders of what not to do. Software Runaways is a bunch of case studies in failed projects.

The same author also wrote Facts and Fallacies of Software Engineering, a collection of 65 principles. I don't agree with the whole list, but discussing them would be a good way to bring out everyone's philosophical differences.

Joel on Software is more focused on your size of project. He's got a book out, but most of the essays in it are on his website. Lots of practical suggestions from a hands-on developer.
Thanks. We've been watching Joel, and a lot of his stuff is really interesting. I'll take a look at the others. Much appreciated.
p.s. I work in an engineering field--aerospace. Can I send my son to visit you some time? :) He's really interested in getting into aerospace engineering. Currently half way through Grade 10.
Sure. I may not be able to give him a visit to the office though, depending on the level of paranoia towards furriners. This isn't the usual xenophobia towards Canadians--it's ITAR. Everything on this project is ITAR. Including the bits being worked on by non-US citizens in the same row of cubicles. I don't even want to think about how much that paperwork is driving up our costs.

I can certainly show him examples of stuff from my previous jobs, talk about school, and answer any questions he's got.
Thanks. I was sort of kidding about sending him for a visit, but will keep that in mind if it looks like it might be helpful. Ok for me to give him your email address (which I have from posts to the Creche group)?
Sure. He might also want to read some of my papers:
I suspect software is rather more complex than all but the most complicated engineering projects, if you consider the tools and systems as well as the actual code.

In order to sign off on a project in the way a PE does, I'd have to trust the compiler, the language, the CPU, everything that interfaces with it, the storage system, etc...
But you're not a pointy haired manager.

Your point of view is CLEARLY defective...

( There would be smilies, but this is the real deal and it's NOT real funny sometimes. )
I wholeheartedly agree with you that conventional engineering includes a lot of art and craft, and of course, so does software engineering. That's where the fun is ;-)

But conventional engineering is, by and large, a mature profession. There are books that tell you the right way to design a widget, and books printed 5 years ago, or even 25 years ago, are still useful today. You can go to college, take 5 years to get an engineering degree, and what you learned as a freshman is still relevant.

Aerospace engineering is not a mature profession. You're still pushing the envelope of what can be done. Every new design is not a variation on what's been done a hundred times before, and the answers aren't in the back of the book. Your multiple layers of design review, and multiple layers of testing, are a reasonably mature process for coping with an immature discipline.

Software engineering, even after 50 years, is far less mature than even aerospace engineering. It's still at the toddler stage, exploring everything that looks interesting, and occasionally poking wires into live outlets. As long as the hardware guys keep giving them faster CPUs, more complex instruction sets, and bigger hard drives, the list of things that can be done, and are therefore interesting to look into, just keeps getting longer.

Even the processes for coping with the immaturity are immature. Any competent software development team should by now at least include a separate formal testing team, but lots of them don't. There's a lot of talk about formal code reviews, but in 20 years in the field I never saw one actually done.

To sum up a long rambling post, IMHO, any attempt to produce a licensed software engineer is doomed for quite a while yet. Best practices for testing are still fluid, best practices for design review are almost non-existent, best practices for coding techniques and security techniques change every time that Microsquish issues a new release of Windows, ActiveX, ADO, SOAP, etc. ad nauseum. By the time a state licensing agency developed, approved, and signed off on a licensing test, it would be obsolete. Even the certification tests that Microsoft itself produces and touts are usually at least one release behind.

Of course, that doesn't give us permission to throw up our hands and give up. Unfortunately, we're getting to the point where bad software engineering, just like bad bridge engineering, can get people killed (the plasma electrophoresis procedure, which took out all of phoenixsinger's blood, filtered it, and put it back, was partially computer-controlled - see if that makes you sleep better at night). We have to at least develop the processes to oversee, test, and guide the underlying software development process. That's where books like McConnell's come in, and that's why we were happy to make it your birthday present. Looks like we both got quite a bit of food for thought from it.
I hate to admit "Aerospace engineering is not a mature profession." But when a professor asked for papers on the standard rules of thumb for our field, I produced one listing the major disputes of mine. So I can't argue it.

McConnell does make a case that software is maturing, but that's bringing it up to the level of aerospace, not civil.