AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

No Such Thing As a Software Engineer

Mike Fisher recently blogged about all the recent activity decrying the death of software engineering in his post “Engineering or Craftsmanship”.  The two terms should never have been stuck together in the first place.  Compared to the “true” engineering disciplines, the construct is as ridiculous as the term “sanitation engineer”.

Most other engineering disciplines require school trained engineers with deep technical and scientific knowledge to accomplish their associated tasks.  There probably aren’t many ground breaking airplanes designed by people who do not understand lift and drag, few ground breaking electronic devices designed by people who don’t understand the principles of electromotive force and few skyscrapers designed by people who do not understand the principles of statics and dynamics.  This isn’t to say that such things haven’t happened (e.g. the bicycle manufacturers turned airplane pioneers named the Wright brothers), but rather that these exceptions are examples of contributions by geniuses and savants rather than the norm.

The development of software is simply different than the work performed within true engineering disciplines.  With just a little bit of time and very little training or deep knowledge, one can create a website or product that is disruptive within any given market segment.  You don’t need to learn a great deal about science or technology to begin being successful and you need not be a genius.  The barrier to entry to develop a business changing service on the internet simply isn’t the same as the knowledge necessary to send a man to the moon.  Software, as it turns out, simply isn’t “rocket science”.   To develop it we don’t need a great deal of scientific or technical experience and it’s really not the application of a “real science” (one with immutable laws etc) as is say electrical engineering.

Sure, there are some people who as a result of training are better than other people and there is still incredible value in going to school to learn the classic components of computer science such as asymptotic analysis.  Experience increases one’s ability to create efficient programs that reduce the cost of operations, increase scalability and decrease the cost of development.  But consider this, many people with classical engineering backgrounds simply walk into software development jobs and are incredibly successful.  Seldom is it the case that a software engineer without an appropriate undergraduate engineering background will walk into a chemical, electrical or mechanical engineering position and start kicking ass.

The “laws” that developers refer to (Brooks Law, Moore’s Law, etc) aren’t really laws as much as they are observations of things that have held true for some time.  It’s entirely possible that at some point Moore’s Law won’t even be a “law” anymore.  They just aren’t the same as Faraday’s Law or Bernoulli’s Principle.  It’s a heck of a lot easier to understand an observation than it is to understand, “prove” or derive the equations within the other engineering disciplines.  Reading a Wikipedia page and applying the knowledge to your work is not as difficult as spending months learning calculus so that one can use differential equations.

All of this goes to say that software developers rarely “engineer” anything – at least not anymore and not in the sense defined by other engineering disciplines.  Most software developers are closer to the technicians within other engineering disciplines; they have a knowledge that certain approaches work but do not necessarily understand the “physics” behind the approach.  In fact, such “physics” (or the equivalent) rarely exist.  Many no longer even understand how compilers and interpreters do their jobs (or care to do so).

None of this goes to say that we should give up managing our people or projects.  Many articles decry the end of management in software, claiming that it just runs up costs.  I doubt this is the case as the articles I have read do not indicate the cost of developing software without attempting to manage its quality or cost.  Rather they point to the failures of past measurement and containment strategies as a reason to get rid of them.  To me, it’s a reason to refine them and get better.  Agile methods may be a better way to develop software over time, or it may be the next coming of the “iterative or cyclic method of software development”.  Either way, we owe it to ourselves to run the scientific experiment appropriately and measure it against previous models to determine if there are true benefits in our goal of maximizing shareholder value.


Comments RSS TrackBack 14 comments

  • Len

    in December 30th, 2009 @ 10:17

    So computer science isn’t, in your words, “rocket science.” By “rocket science” we take you to mean the stuff done by “true” engineers like the ones who decided O-rings were the best way to build the solid rocket boosters that blew up the space shuttle Challenger.

    Your proof? An assertion that anyone can make a web page. Honestly, the depth of your lack of understanding of what software engineers do is so profound that it would take hours for me to write a thorough explanation as to why making a web page is a stupid argument to refute that software engineering is a valid engineering discipline.

    Let’s take any one of your “true” engineers and see them fail miserably at engineering data provability systems via distributed hash tables with a keyless cryptographic component.


  • Wabb

    in December 30th, 2009 @ 10:43

    Thanks for the (rather aggressive) comment Len :) But you haven’t argued or made a point that software development is traditional engineering. And if that’s not your point, then why should we use the term engineer? You’ve simply said that we don’t know what we are talking about because many software engineers are smart and can develop complex systems. We absolutely agree with that point, being former software engineers ourselves and having worked on everything from radio operating systems to manufacturing control systems and artificial intelligence.

    Put another way, our point is that there are incredible people developing software with very little engineering or science education. Many of the best in fact, in our experience, haven’t completed a traditional university curriculum. Many do not have the science background that would allow them to apply it to real world needs (part of the traditionally accepted definition of an engineer). We cannot think of many examples like that in the electrical, mechanical or civil engineering fields.

    What, then, would be your definition of an engineer?


  • Neil

    in January 22nd, 2010 @ 08:22

    The term “computer programming” encompasses a broad spectrum of activities.

    At one end of the spectrum, it’s a mere craft skill involving the gluing together of bits of functionality into simple devices; analogous to carpentry or basket-making.

    At the other end of the spectrum, it’s a rigorous discipline involving mathematical rigour that goes well beyond the sophistication level of that involved in most conventional engineering; as Len says, cryptography is one of those fields.

    What’s needed is a spectrum of terms to match this broad spectrum of activities. At one end, “computer programmer” is the appropriate term.

    At the other end, the term “computer scientist” is entirely warranted — the work being done in these fields is actually at the forefront of mathematical research.

    Somewhere in the middle are the true software engineers, who approach computer programming in a disciplined and rigourous knowledge-based manner, similar to that of engineers in other fields. Programmers working on life-critical systems in aerospace applications come to mind.

    Right now computer programming is such a young field that it’s still not clear where the boundaries of these terms should lie.


    • Wabb

      in February 18th, 2010 @ 15:23

      Thanks Neil – great thoughts and comments.


  • Ben

    in February 17th, 2010 @ 20:14

    Well, there really is such a thing as software engineering, but not all people who write code are software engineers, just like not every schmuck who connects a home entertainment system together is an electrical engineer.

    As an EE and sometime software developer, I’d say the critical areas of knowledge to be a SE would be digital logic, data structures, computer architecture, digital communications, operating systems theory, and one or more programming language du jour (preferably one in the C-Java syntactic tradition as a minimum). If you don’t know what 2s complement is and can’t understand hex, you’re just a code monkey, not an SE. An SE knows how a computer works down in the guts and consequently understands how to make it do both common and uncommon tasks in a reliable and efficient way.


    • Wabb

      in February 18th, 2010 @ 15:22

      Thanks for the post Ben. The post was meant to create discussion rather than emotion. I actually agree with your points – at least that there CAN be such a thing as software engineering if we truly held people to a set of domain knowledge that would help make them successful.


  • PaulG

    in February 18th, 2010 @ 14:59

    “many people with classical engineering backgrounds simply walk into software development jobs and are incredibly successful.” – Yes, we put them in sales.

    The term that makes me grind my teeth is Software Architect. When architects screw up, people get killed, as in Haiti. It’s whole nother level.


    • Wabb

      in February 18th, 2010 @ 15:21

      Thanks for the post Paul!
      I believe the same can be true for most other engineering disciplines. If mechanical engineers screw up, cars crash or seat belts don’t work. If civil engineers screw up, you get the Tacoma Narrows Bridge disaster, or New Orleans levees breaking. Aerospace engineers screw up and planes crash.
      There are cases where software causes problems too – flight control systems for instance.
      But the real point we are trying to make is that you don’t have to understand “laws” (or at least applied science) as you do in other engineering disciplines. It’s difficult to think that people without a proper background in applied sciences could become successful electrical engineers, chemical engineers, mechanical engineers, etc in the same volume they do in programming. There are, however, many successful programmers with no more than a high school education.


  • Heath Hunnicutt

    in March 1st, 2010 @ 15:05

    Of course, there is a big difference between “programming” and “the study of computer science”. In Europe, the latter is sometimes called, “the study of computation.”

    Within the study of computation are many, many areas full of mathematical rigor and with tie-ins to traditional engineering disciplines.

    For example, rocket guidance systems are nowadays composed in part of algorithms. Some military jets attain speeds using active control which are not possible without the participation of computation. In these case, obviously the person implementing the firmware is some kind of engineer.

    The root word of “engineer” being “engine”, surely any person who writes software which controls an engine should be an engineer.

    The problem is that the term “software engineer” was co-opted by industry (M) and abused through application to trained programmers. There is no Professional Engineer for software engineers, no legal weight behind the word.

    The abuse of the word “engineer” and the loss of its narrowly legal meanings is agreeably lamented.

    Computer science with its O() notation, entropy, complexity (Kolmogorov, for example), and other theory should be seen as an engineering discipline.

    The test for admission to software engineer should have little to do with pursuit of an Internet-based business, we would agree.


  • Pr In Los Angeles

    in April 20th, 2010 @ 11:55

    Hello, really liked this post! Well written. Will read your other posts.


  • Nick

    in April 22nd, 2010 @ 08:52

    This is a well written and interesting article, though I disagree with your conclusion that (a) Software Engineer is a misnomer, and (b) Software Technician is a more apt title. (at least, universally applied). No doubt, there are those programmers who “…have a knowledge that certain approaches work but do not necessarily understand the ‘physics’ behind the approach,” just as there are children who are given model airplanes to build and fly without understanding lift and drag.

    However, I do disagree with the claim that “such ‘physics’ (or the equivalent) rarely exist.” The “physics” of the world of software are the rules governing the syntax/use of the programming language. What _is_ different in the field of Computer Science is that those rules/physics which govern what we code/engineer did not exist before us.

    Not only do some in the field of Computer Science engineer within those laws, but they also create them. Imagine an electrical engineer who had to not only operate knowing Ampère’s law, but who first has to define the law (as opposed to discovering it) ensuring it does not conflict with the other laws governing electric current and magnetism. Software engineers who write programming languages do precisely that, and in fairness to your point _do_ differ from other engineers in that respect.

    The laws do exist, and those who write code according to them are engineering. Now, what can we say about those who crafted the laws? Perhaps Software Deity is a more appropriate title, though certainly not technician. ;)


  • Wabb

    in April 22nd, 2010 @ 15:01

    Hi Nick,
    These are some great points and thanks for the comment.
    As a counterpoint – if language syntax is a law, then wouldn’t that make English majors English engineers? While I don’t think I really understood the English language until I took my first compilers course in college, I’m not certain that an understanding of language construction (programming or writing/speaking) makes one an engineer. Compilers made me better understand how all languages are constructed – but didn’t make me an engineer.

    I do believe that if one takes the laws to mean the constraints of the overall system (CPU, multi-threading, interpreter or compiler, operating system, bus speeds, I/O, etc) then the laws as you mention them start to approximate the “laws” of physics in our world. I’m just not certain that most developers understand those laws anymore.

    I’ll concede that there are some great people out there applying an engineering like discipline to the development of high scale systems, etc. I’m just not sure that the bar to develop software is nearly as high as the bar to develop micro-circuits or planes.

    Thanks for the well written and thoughtful response!


  • Nick

    in June 4th, 2010 @ 09:24

    Very interesting counter-point, it certainly made me take a second look at my stance. However, there is a distinction between engineering and the arts which applies to your example. Tt seems to me that the final cause throughout engineering disciplines is to create solutions for practical problems, whereas with literature (and the other arts) it seems to be the stimulus of emotion.

    Without a doubt, there are examples which blur this line (see: tourbillon). The realm of computer science certainly is not without such examples (see: IOCCC). The distinction exists, for me, in purpose.

    While software engineers do not manipulate and work with entities in the corporeal realm (aside: not quite true, as “software” only exists as different states of hardware, though that seems a discussion for another time) they are quite often creating solutions to practical problems. That is what is necessary to satisfy the IsEngineer(x) predicate, for me.


  • giełda walutowa

    in October 12th, 2012 @ 16:34

    Well-optimized web page, I haven’t observed such a well-prepared glimpse. Perhaps were forced to spend much time over it. Together with the records, something astounding. Congratulations are in order!