Orcmid's Lair status 
privacy 
 
about 
contact 

2008-05-08

Don't Call Me a Coder!

Recently, an acquaintance phoned me, looking for some advice about business-service software (for CRM and those other TLAs) and the APIs that some packages and services have.  He says to me, "You're a coder, aren't you?"

I felt myself bristle, as if I had been insulted and dismissed all at once.  My chum, an IT and training guy that I know through our wives, had a problem he thought someone with coder chops would understand.  Neither of us really knows what the other does, but we quickly got over that little speed-bump enough to have an useful conversation.  It was vaguely clear what he was looking for and he had some casual idea that I was the sort of bloke who would know about Application Programming Interfaces (APIs) into hosted business-service software packages.  He wanted to know more about how (and which of) those could be used to integrate a system the way he wants it for his business.

Indeed I do know a bit about APIs and integration, but I have no domain knowledge abut business-service integration generally and his application specifically.  Still, I was able to ask questions and do a little digging around on my own.

So what cheeses me off about "coder?"

Let's back up a little.

This month, May 2008, is the 50th anniversary of my first line of code.  It was in Fortran [I on an IBM 704], it compiled, it ran, and it blew up with a "divide check" on the first and obvious test case.  ("Divide Check" was a hardware halt in those days, so I effectively crashed the machine with a division by zero.)  I was employed as an engineering aide in Renton, Washington, and my engineer and I were teaching ourselves Fortran from the manual.  This little program was one that I had made up myself as an exercise.

In 1958, coders might have been thought of as interchangeable with programmers and software developers as we now think of them, but coder was also a particular job classification for some. 

In the beginning, coders were often human compilers of the designs created by others.  This was not a tribute to creativity, since the creativity is presumably in the detailed and specific design, handed down on the '50s version of clay tablets: the computer-program flowchart.  In this context, a coder would not know the requirements or the problem being solved or even understand the method of solution.  The idea is just to code the logic using the available language of the machine (at whatever level it is).  Thus was code-and-fix mindless development begat.

Now, I have in fact worked with code where the flow-charts were created by Grace Murray Hopper, and that is interesting for its own sake.  Fortunately, I was not the coder.

The need for coders in this sense disappeared with the availability of better hardware and good software-development tools, even ones for machine-language assembly.

It is not as if there aren't still efforts to routinize and deskill big chunks of software development.  That is what is pejorative about "code monkey."  That this is happening at all is a great misunderstanding on the part of the erstwhile code monkey and even more-so on the part of the IT (even ISV?) management that thinks this is a successful way to develop robust application software (ideally by eliminating programming altogether and begrudgingly sending code monkey work off-shore in the meantime).  Those who think that any sort of automated, model-driven development is going to eliminate the need for "coders" have a surprise coming.  The amazement will be around how does one test, debug, validate, and then maintain, upgrade, re-engineer, refactor, and re-integrate those beasts.  I can't wait to see what the Total Cost of Development and Deployment audits will reveal as the return on those investments.

So I never cottoned to "coder."  And I never did it.  I cannot recall any time in my career, not even that first time, when I ever coded in the sense that it was meant then and in whatever sense it is meant now. 

I have written code, but that is not the same.  Writing code is, as you might suspect, an increasingly small part of what I do, even when I am the sole developer on a project.  There is actually something odd about that.  I very much enjoy developing little programs, yet I find that my attention is usually consumed by other aspects of delivering an architected, well-crafted result.  In particular, the problem these days, as Fred Brooks noticed over 20 years ago, is not knowing how to code but knowing what to code and knowing what is important in the coding [1].

You can call me an architect as long as you're smiling when you say it.

You can call me a cybersmith all you want.


[1] Frederick P. Brooks, Jr.: The Mythical Man-Month: Essays on Software Engineering Anniversary Edition.  Addison-Wesley (Boston: 1995).  ISBN 0-201-83595-9 pbk.
The 1986 "No Silver Bullets" paper is reprinted here, with some retrospective chapters on reactions to the original book and the no-silver-bullets thesis.  Perhaps today's coder-equivalent is someone who has never actually seen this book, is not interested in reading it, and thinks software engineering is all about control and waterfalls and is certain they have no need to know more.  I suppose this level of cluelessness is something that we must all work through one way or another.

 
Comments:
 
Dear Cybersmith, nice piece. I, too, want to see real data on Total Cost of Development and Deployment. Until we're reguarly measuring that I don't think there will be much progress on understanding exactly what it takes to build reliable and robust software-based systems.

And you can call me a "socio-technical systems engineer" ... for now.

-Bill
 
Post a Comment
 
Construction Zone (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2002-10-28-07:25 -0800 (pst) by orcmid
$$Author: Orcmid $
$$Date: 08-10-07 13:22 $
$$Revision: 1 $