The company I'm working for at the moment is suffering from a bad case of "everyone's a software engineer".  The reasons why this is such a bad idea are all over the net, so rather than sit quietly, content with my enlightened understanding, I'll hopefully try and convince you of a theory of mine that links the maintainability of source code to the "engineering" metaphor - and why I really dislike the "Software Engineer" job title.

So why aren't all developers software engineers and why does it matter?  Simple.  The engineering metaphor that was used in the 80's (and even 90's) to describe the activities performed by those who construct software is partially to blame for the spectacular failure of many projects and most importantly for the reams of unmaintainable code produced on a daily basis. 

How can I make this outrageous claim?  Think about how a team of engineers constructs a building.  In brief, they're provided with the plans, they carefully plan the construction then they build it.  Once the walls are up, the doors go in and the paint dries it's done.  They get it right first go, because they've built similar structures before.

"Software Engineers" if the role name is truly descriptive, would work in a similar way wouldn't they?  A bit of design and planning up front, then some coding and when it works...it's finished.  This is where it all starts to go wrong.  The concept of "finished" in engineering is very different to what "finished" software should look like, and I think that many developers miss the point and take the metaphor too literally.

The act of designing and constructing software should be more like composing a song, or writing a book.  You start with a rough idea of what the program is going to look like.  After a couple of drafts and a little experimentation (including, of course the associated unit tests) a structure starts to emerge.  You add the remaining features to the structure and all the tests pass.  Excellent!  Now we move onto the next task...don't we?  NO!  NO! NO! NO!  We've only just completed the draft!

What's left to do?  The tests pass...isn't that enough?  Not usually.  The key to writing maintainable code that is as easy to read as your favourite book is that last missing step in the process.  The step that construction engineers can't usually perform - a complete restructuring of the internals of the program.  You can't (usually) take a building that's just been finished and say "now lets's just move all the rooms around to the left, move the elevator shaft over to the right"....e.t.c).  But with software, that last step is where the professional developers just get started.

Once the program is working and we've got a comprehensive set of tests, we can start to refactor the structure of the program into an optimal state.  Rename variables that might have changed meaning on the journey from draft to complete, reduce dependencies on non-essential classes, move methods into classes that better reflect the intent, relocate responsibilities to better reflect the domain, break up large classes into smaller classes with specific responsibilities....the list goes on and on. 

You're not complete until someone else can read the source code top-to-bottom (almost) and understand it's purpose immediately, without digging around for answers.  Is your code like this?  Try getting a peer to read the code for that last bit of functionality you added to the application, did they understand it first go?

So after that little rant, what job title would I have bestowed on our boldest and brightest software developers?  How about Software Designer? Software Author? Software Artist?  The analogy could all go horribly wrong too....but perhaps the emphasis on creativity would encourage us to keep working until our code is clean, balanced and beautiful in addition to being green.