Developers or engineers?

I’ve had quite a few job titles where I basically did the same function: Software Engineer, Software Developer, Technical Lead, and so on.  In some companies, a Software Developer is a completely different position than Software Engineer, and in others they’re used interchangeably.

The connotations and implications from each title are strikingly different.  The term “engineer” has a much different meaning than “developer”, taken outside the context of software. A Developer might lay out the plan of a new subdivision, where its green areas are, what style homes should be built and what theme the neighborhood should adhere to.  The Engineer lays out the water and sewage lines, elevations, roads, utilities and other functions vital for sustainable human habitability.  A Developer creates the vision and designs the implementation, while the Engineer ensures that quality, regulatory and ethical standards have been met.

That’s not to say an Engineer isn’t creative.  In a family full of Engineering graduates (including myself), no Engineer would have a job if they weren’t creative.  Every problem is an implementation of a different pattern, but the details make each challenge completely different than the one before.

Having worked with many types of real Engineers (i.e., they’re doing the job they went to school for), I didn’t see what they were doing was much different than me.  They were concerned with:

  • Safety
  • Reliability
  • Maintainability
  • Aesthetics
  • Usability

As well as a host of other “ilities”.  One critical difference between me as a Developer and they as an Engineer was that Engineers are licensed by an independent group.

In many fields and jurisdiction, including Civil Engineering in Texas, licensing is required by law when performing engineering services for the public.  Licensing isn’t easy, either.  To become a licensed Professional Engineer PE, you must:

  • Graduate from an accredited engineering program
  • Take an initial exam to become an Engineering-in-Training (EIT)
  • Have a minimum of 4 years experience as an EIT, preferably as an apprentice to another PE
  • Take a rigorous exam, which takes 6-8 hours to complete

Licensing isn’t a one-time affair, you have to renew your license, which has its own requirements including continuing education.  Even if not working in the public sector, licensing is considered a career necessity.

But we have certifications, right?

Anyone that has interviewed candidates for positions knows the sad state of software certifications.  At best, software certifications signify that your are certified to be an absolute beginner for that topic.  For some reason, software certifications still hold value, though all involved, managers, HR and candidates, know that the certifications aren’t worth bytes it was emailed with.

Would licensing help our industry?  We live in a sad state of affairs when identities are not stolen because of sifting through your mail or stealing your wallet, but because of careless, ignorant developers.  In a Twitter conversation with an ex-colleague, Terry noted that software development lacked discipline, respect and accountability.  Can licensing help prevent the ridiculous failures, by both raising the bar and raising the stakes for individual failure?

If a bridge fails, the engineers can be held liable if they are found to cut corners, or even sheer ignorance.  Oversight in the form of inspectors is supposed to help, but in the end, the engineers are held accountable.

I see Developers as code monkeys, slapping code out without regard to reliability and maintainability.  Engineers have a much longer horizon too look at, they must ensure the bridge they build lasts 100 years, not six months.  Shouldn’t we hold ourselves up to the same standard?

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Misc. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • one problem is the shortage of labor..while there exists such a gap in the employment market (people vs work)..a license process wouldn’t make it anywhere..companies are dying for people right now..

    although it would be nice if there were an optional license process for people working/wanting to work on large-scale, mission critical systems (ie..not the average .NET treehouse)

  • @hoff: Why is there a shortage, though? I would contend that the biggest problem w/r/t to hiring shortage is not the actual lack of bodies, it’s the ridiculous hiring practices that most companies go through.

    They hire smart people who have no clue and put them into ridiculous situations and expect ridiculous things of them. Engineers will refuse stupid work, but most software developers happily accept it and then everyone wonder why failure ensues.

    Many companies respond by hiring more people and doing the wrong things wronger, faster, and more expensive usually with more spectacular failures. They THINK they need more bodies because they THINK that working harder is the answer.

    Everyone needs to work smarter. My eyes have been seriously opened — going through this interview circus I’ve been going through the past few weeks — as to the sorry state of affairs in craft of soft dev, specifically in the .NET space.

  • i half expected your link to be a rickroll, but i entirely agree with you. not sure if licensing would give us much legitimacy, but it’d be nice for some entity to hold us to some sort of standards. like wearing pants. nvm.

    i’m not sure when a person changes in my eyes from a codemonkey slapping code that only half the time works to an engineer where they just pwn everything they do. you can definitely tell the difference, though. there’s the guy who says “it’ll work” and you trust and the guy who says “it’ll work” and you ask, “but what about in this case?”

    maybe it’s number of gray hairs.

  • @chad

    I think I have to chalk it up to our industry being so young and moving so quickly. It’s a spastic, knee-jerk mercurial world, where people are re-assigned before any accountability happens. I’ve seen more people moved for incompetence that should have been fired than I can shake a mouse at.

    It really is a sad state of affairs, but I don’t have the perspective to know if it’s worse in the .NET space. Could be a “grass is always greener” situation.

    I think we have to come to terms with the fact that there are no experts, no one knows what they’re doing and no one has all the answers. There’s just us.

  • I’ve given this some thought both as someone looking for a job and as someone hiring. I keep coming back to the conclusion that – for now – what we do is too loose to be managed by a process such as licensing but too important/complex to be treated like development/architecture. Until (if) software matures into a practice where a select few build the blocks and monkeys assemble the pieces we will continue to have more parallels with a craft.
    I consider myself a craftsman and a journeyman at that. I’ve spent and still spend enough time learning from people I consider masters to know the difference between slapping code together and crafting well-formed software. I’d love to see some kind of software guild where acknowledge masters could tutor and ‘certify’ apprentices who could then work as journeyman and (perhaps) eventually masters themselves.
    . . . or we could hold annual contests to see who could write the most coherent code after beer-bonging a six pack.

  • It seems in the world of software engineering today, its all the rage to declare that your process is ‘_DD’. Whether the leading letter in the TLA is T for Test-Driven Development, M for Model-Driven Development, or even B for Behavior-Driven Development, there seems an increasing and never-ending stream of these ‘something-driven’ methodologies, each one promising success for your project if only you adopt and follow its core principles at least somewhat religiously.

    Personally I feel this whole thing is largely a sign of our industry desperately trying to codify the work it does into a coherent, documented, repeatable process in what is ultimately a futile attempt to put the ‘engineering’ into ‘software engineering’ as though developing software could become more like engineering a bridge.

    Part of the reason that the process of engineering something like a bridge can be decomposed into a set of repeatable steps is that the forces acting on all bridges are fundamentally the same (gravity, wind, weather, — budget! –, etc.) and are almost always present in roughly the same relative magnitude. In two different bridge engineering projects, wind-shear might be present in differing amounts, but it will never be the case that a bridge will be designed where the primary constraint is wind-shear and gravity becomes a secondary constraint. At a basic level one can codify the engineering process for a bridge such that “if I follow this process each time, I will end up with a successful bridge engineering project”. Yet one doesn’t find bridge engineers falling all over each other to declare that their process is actually one of ‘GDD” (Gravity-Driven-Design), ‘WDD’ (Weather-Driven-Design) or even ‘BDD’ (Budget-Driven-Design).

    Instead, they are simply ‘bridge engineers’ and their industry has long-ago settled on a common set of practices that can reasonably be expected to result in a successful bridge (note that in this context I am declaring a ‘successful’ bridge as one that is of structurally sound design, carries appropriate traffic, etc. over it, and comes in on-budget). This is the basis of most all engineering principles in any engineering discipline: given a predictable set of (similar) inputs (gravity, weather conditions, span length), we should be able to produce a predictable set of (similar) outputs (the structural design of the bridge). But software engineering doesn’t work this way because the underlying premise of the above statement is inherently unachievable: we can almost never have a similar set of inputs twice and as a result it makes pre-determining the outputs with any certainty just as impossible.

    (Note this post is not intended to trivialize the complexity and effort required to engineer a bridge, merely to point out that any two bridge engineering projects are likely to have much more in common with each other than any two software engineering projects selected at random).

  • IEEE does have a Certified Software Development Professional certification. It’s relatively new, but does certify people at a higher level than most certs (like MCSD, etc.)


  • Brad Mead

    Odball: “Why don’t you knock it off with them negative waves? Why don’t you dig how beautiful it is out here? Why don’t you say something righteous and hopeful for a change?”

  • @Steve

    xDD may not be the panacea, but whats the alternative? Cowboy coding?


    I think I missed something. Are you referring to me or another commenter? Sarcasm doesn’t really come through in comments, unfortunately.

  • Brad Mead

    I don’t know I thought the sarcasm came through ok. I stopped there as a pre-emption to a larger rant – but, indeed, doing so felt rather passive-aggressive. So let’s just get to it.

    Seldom considered in these discussions is the market segment in question. What niche did .Net fill – or for that matter VB and VBScript before it? I think some of the “whys” of the less-than-stellar crop of candidates are rooted in the target market for .Net development. Visual Studio wasn’t hugely marketed to enterprise development, regardless of the advertising copy – the “easy button” (VS, RAD, Webforms) is not an engineering pillar principle – it is merely a more engineer’ish permutation (spin) of an era of Dreamweaver-like desktop tools that create the varieties of those Treehouses variously mentioned. Java was the mainstay for the enterprise engineering market – and imperfect in its own ways. But Java and C have been the languages of choice in university CS programs for the last decade not C# and VS. Yet .Net is making inroads into the engineering-grade market – hooray! This is good not bad. But it also, necessarily, gives rise to the mixed bag of talent and skillsets. That’s just reality.

    I guess I don’t buy into this professed, ostensibly altruistic goal of improving the accountability and good outcomes for .Net software development through certification. Not that I doubt the practical effectiveness of such a tool. What I doubt are the assumptions made about those outside the fold of this group – that they are unaccountable, massively ill-informed, uncaring and hazardous to the health of their organizations and users. We could go on for hours about facts and circumstances that support or detract from such implied claims. I can say right up front I’d fail your certification test. But I can also say that at this stage of market and practice evolution, I am having a hard time resisting the perception of the discussion as somewhat disingenuous to the professed goal.

    Rather than lamenting the imcompetence of your (non?) peers and reflexively prescribing ltimus-test group membership certificates, why not continue to engage intellectually and creatively and point them in the right direction? The idiots will get their due and some users and orgs will be “had” in the process. But do you folks really want to take on a goal that entails a significant elimination of this with the traction gained thus far? Isn’t that a little over ambitious at this point? What happened to simply continuing the construction of a critical mass for such a transformation by shepherding the curious and willing down the path of light? That’s when you people shine: when you’re enlightening me, not when you’re eliminating me. If I look the gift horse in the mouth, that’s my problem and my liability to those concerned. And if they don’t know better, aren’t we talking about a much larger and more systemic problem? One that isn’t easily remedied by yet another certification. Agile, for example, seems to me just as much a state of mind as it is a formalized set of rules.

    In many ways agile thinking parallels progressive business operations methodologies like Senge’s Learning Organization, Tichy’s Teaching Organtization, LEAN etc. Without the harmony of an organization aligned along those lines can we really expect the software people to be the anchor for correction of resultant inefficiency and error? Maybe… but I’m not completely convinced at this point.

  • @Brad

    Heh, sarcasm only comes through 50% of the time in text media.

    In big companies I’ve worked for, security classes were required. I personally see it a matter of time before licensing is needed for projects that deal with critical information (such as SSNs, etc). When it’s a matter of public safety in preventing identity theft, licensing (which is different than certification) could help in setting a bar.

    I’m not advocating required licensing for the -ilities, but for public safety issues where oversight could help prevent these occurrences.

    I do agree with your assessments on the primary source of .NET developers. I don’t believe security gaffes are specific to .NET. I see design principles and values as a completely different issue than public safety concerns. Two problems tackled in completely different ways.

  • Lucas Goodwin

    @Steve Bohlen
    Having been a Mechanical Engineer/Manufacturing Engineer I can attest you have things correct.

    @bogardj, et-al
    Software “Engineering” is more akin to permanent r&d work in other engineering professions. The inputs/outputs fluctuate from project to project (And with-in the same project) to much for it be otherwise. I don’t see this ever changing; otherwise it wouldn’t be software.

    The difference, as I see it, between Programmer and Engineer in our profession is merely how far ahead the two look. An Engineer looks towards the future issues of a project (maintinance, cost of ownership, etc) and factors that into his solutions for today, while a Programmer just looks at the problem at hand.

    Developer and Engineer are synonymous in this industry because both do the same thing (mostly). The confusion comes from giving both titles to programmers (AKA code-monkey) as well.

    Also, a clarification. Most engineering professions have licensing programs, but very few are any more required then software certification in this market. Civil Engineering and Structural Engineering are their own little worlds as most of the work is for the public sector and we all know how Beauracrats are…

  • Brad Mead

    Jimmy, my bad.

    Certianly anywhere you find a fiduciary duty mandate special considerations apply. As mentioned above, IEEE certifications usually apply wherever a government agency is concerened – obviously this wasn’t enough for the Veterans Administration. IMO the whole process should be specially subject to certification where the compromise of security or identity is in question.

  • Lucas Goodwin


    HIPA regulations is supposed to protect us from these security holes in an organization already. If that organization chooses to protect themselves from violating HIPA by using certification requirements during hiring seems reasonable, but to make it an industry wide requirement to even work in that field of software or to put liability on the engineer is ludicrous.

    The liability lies with the company/agency who works for them (unless he is the company). IMO alot of these security issues would be better mitigated if entities faced real repercussions for violating the existing regulations.

  • It would be a bit easier, if managers at large companies who “manage” software developers were software developers themselves – good ones.

    Ever seen engineering companies led by accountants or sales people?

  • This kind of stark separation between what a developer is and what an engineer is may be too extreme to be reflected in practice and in reality.

    You’ve defined the roles uniquely enough, but I think you’ve made a mistake interpreting the uniqueness of the roles as unique human profiles.

    Few engineers or developers are not a blend of both – among other – profiles.

  • jdn

    “xDD may not be the panacea, but whats the alternative? Cowboy coding?”

    Why the assumption that those are the only two possibilities. Successful software development existed prior to any of the xDD methodologies that are all the rage in certain current circles.

  • @jdn

    xDD ideas have merely consolidated values, principles and practices. They aren’t new. Maybe successful software development do exist without these underlying ideas, but I haven’t seen any yet. I find it easier to call out principles than leave them unspoken and tacit.

  • John,

    “Successful software development existed prior to any of the xDD methodologies that are all the rage in certain current circles.”

    I’ve been writing software for 18 years. Expectations for software keep getting higher. xDD it’s an appropriate adaptation that has been made to meet expectations.

    I can still choose to use the techniques I used 5 or 10 years ago, but I wouldn’t be as effective.

    There is indeed a “rage” in play, but it’s not an aspect of folks practiced in xDD. It’s part of teh perspective of folks who are looking in from the outside. It’s their emotional content in regards to xDD.

    It’s a response the the lethargy that has grown around software in the past five years, making stuff like xDD seem revolutionary rather than merely evolutionary. For folks who have kept abreast of the changes and who haven’t come under the influence of the lethargy, these changes have indeed been logical, small steps forward.

    From the perspective of folks who are now only becoming aware of an entire new field of software development, xDD can appear to be all the rage. It’s an unfortunate side effect of market influencers that don’t have the capital, the volition, or even the permission to adapt evolutionarily, and who work hard to keep their constituents from out-pacing them.

    Many of us started down this path almost 10 years ago. We certainly don’t see this as anything akin to a rage. We’re just following the continual, slow and steady path of continuous improvement, just as we always have.

    I do feel rage in regard to the entitlement to remain increasingly resistant to change as even more change gets delayed. The more change that piles up, the greater the resistance that is growing in the people who have barely just begun.

  • @Scott
    “I do feel rage in regard to the entitlement to remain increasingly resistant to change as even more change gets delayed. The more change that piles up, the greater the resistance that is growing in the people who have barely just begun.”

    Yeah that bothers me too, especially as many of the people who rail against xDD and agile haven’t taken the time to get the understanding necessary to comment.

  • jlockwood

    Whew Bogard, you sure opened a can of worms, no?