Software Development and Engineering Design


Having spent 3 weeks on the road talking to different customers about software development and coming back in to look fresh at our on processes has got me thinking about our development methodologies.  That coupled with the fact that my Dad, who is a “real” engineer, is out visiting for a few days.    We got talking tonight about the essence of real engineering and attempted to understand if software development is approaching the level of say mechanical or chemical engineering in terms of maturity of the field.  Rico and I have discussed this before as well, check out his thoughts.


 


It is not a completely idle conversation as my Dad knows a thing or two about engineering as he has taught it 30+ years.  In fact the latest class he is teaching covers this exact topic.   I am struck by how the principles in the paper are drawing for a 1954 work Engineering Analysis: An Introduction to the Professional Method of Problem Solving. yet we still struggle to “rediscover” them in the software world. 


 


By my reading there seems to be lots of synergy here.. my hope is that software is just in a maturing state.   These principles apply equally well to software and will play out more as the field develops more deeply… but what I can’t tell is are we on track?  Are engineering fields as young as software in the same state of flux?  


What is your take?

Comments (9)

  1. Barry Kelly says:

    If you haven’t already, I recommend you read these essays:

    http://www.developerdotstar.com/mag/articles/reeves_design_main.html

    I have more comment on my own blog.

  2. Luca Minudel says:

    > These principles apply equally well to software

    I do agree just partially about this.

    1- software is flexible: this is the *main* advantage (i.e. compared to electronics) of software but it is also the main challenge in software engineering [1]

    2- software is intangible: it is easy to observe the progress while a ship or a skyscraper is been built up but it’s quite hard to measure the real progress when building a software product [2]

    3- attributes of good software: we are just starting now to understand the relations between internal software attribute and external/perceived software quality [2]

    [1] http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

    [2] http://www.software-engin.com

    P.S while software engineering it’s a young disciplite it was born in 1968, I mean… it is 18teen for the 2nd time this year 😉

  3. theCoach says:

    I am getting the sense that the necessary tools are just becoming practical to do real engineering in software.

    Of course, "getting a sense" does not make me feel like we are their yet.

  4. Rico Mariani says:

    I’ve tried to make this very simple but I’m on a similar path.

    -Budget

    -Plan

    -Verify

    If you listen to how I describe those steps I think you’ll find they are even more similar to the PMPS than they first appear. Could it be they were on to something? :)

  5. The main difference I see is communication: software is a communication medium from developer to developer, or between a developer at point A in time to the same developer at point B. The communication aspect is as important or more important than the engineering side often; otherwise, we would still be writing software in machine code, instead of using high level languages.

    user->developer and developer->developer communication is so important, yet so hard to quantify in many ways. We have numerous attempts to quantify, yet without any baseline implementation (simple yet elegant) how can we measure a given implementation, to determine if it is a "good document" or a stinker?

  6. Jeff Atwood says:

    > We got talking tonight about the essence of real engineering and attempted to understand if software development is approaching the level of say mechanical or chemical engineering in terms of maturity of the field

    It’s a fundamentally specious comparison; those engineering disciplines are based on God’s rules– physics. Absolute and unchanging. Compare with software "engineering", which is based on the rules of.. whatever some bunch of guys thought was a good idea at that particular time. God didn’t invent x86.

    It’s certainly more art than science. IMHO.

  7. Are programmers Engineers? About every few months this is usually something I bring up because I’m part of an IT group for the College of Engineering, and because I manage a group of IT staff/system administrators. It’s probably largely out of guilt…