Let's Bury the Term Software Engineering


Softwareengineering is not an accurate way to describe what software designers anddevelopers do. We create software in an environment that is constantly changingto fulfill the expectations of businesspeople who aren't exactly sure what theywant. Does that sound like engineering? As I'll discuss in this article, physicalengineers deal with the universal laws of physics, but software designers and developersdeal with unrelenting change. By using the word engineering to describe our profession, we set ourselves up for staticprocesses and brittle team structures that tend to discourage change, ratherthan folding it into our everyday lives. Once we can shift our mindsets awayfrom engineering our software, people, and processes, we'll find that our teamsare more responsive, productive and change-readythan ever before.


As a point of comparison, let's look briefly at physical engineers who areresponsible for designing and building bridges. Similar to software developers,they look to define a problem (a road needs to cross a river), design asolution (blueprints), and build the solution (the finished bridge). There isalso significant materials testing that goes on throughout the process.

Building Bridges Versus BuildingSoftware

A bridgeengineer's central concern is less about the aesthetic of the bridge and moreabout making sure that the bridge will last and will not collapse. The engineermust grapple with a set of constraints to ensure that he is successful. Theconstraints include certain expectations from the client, but his focalconstraints have largely to do with the science of physics. Where every beam isplaced and the position of every bolt is dictated by physical laws which willwork to strengthen the design or destroy it.

Now let's flip to software developers. We are also employed to solve aparticular problem, which we analyze, design, build, test, and deploy. So far,this is similar to the role of a bridge engineer. But now we examine the issueof constraints. Physics isn't a big concern for software designers, because ourend product is intangible, but we do have other constraints. Our constraintscome from the business rules and the information needs of our stakeholders.These provide the boundaries/scope for our development efforts.

{sidebar id=1}Now let'scompare the two sets of constraints. The bridge engineer works with the laws ofphysics. We work with the expectations of stakeholders. The laws of physics arewell-known, well-documented, are non-situational, and do not change. Theexpectations of software stakeholders, however, are usually not well-known(even to the stakeholders), not well-documented, very situational, andextremely volatile. I've even seen projects that were drastically altered inmidstream based on a magazine article that an executive read on an airplane!You probably have too. Sometimes the changes seem frivolous and sometimes theyare clearly business necessities, but the volume of change is a certainty withsoftware development.

This is a major contrast. Software developers have to deal with a lot morechange in the lifecycle of a project than does the engineer with the bridge.Yes, the engineer will learn more about the problem domain as he proceeds. Hemight find out that a particular piece of ground is less firm than he wasexpecting and have to change his strategy because of that, but the originalproblem and the constraints of physics remain the same.

Please note, I am not saying the job of a bridge engineer is easy. This work isextremely difficult and requires great intelligence, discipline, andcreativity. Imagine what it's like to have the responsibility for creating aphysical structure that society will depend upon! But my point is that it isfundamentally different than what we do in software development.


People Are Different, Too


Thedifference in the amount of change is only one factor. Think about thequalities you want to see in a bridge engineer. What does"professionalism" mean in bridge engineering? It is hard tocategorize any profession, but you could see how engineers really need to bepeople who are exacting, precise, and methodical. They will usually beproduct-oriented and not people-oriented.

Now what about professionalism in software development? Again, there issignificant contrast. Most of us are far more people-oriented thanproduct-focused. The best programmers I've seen have not been overwhelminglymethodical and meticulous. They are more often creative, love change, and can evenbe a bit nutty. Certainly the best requirements analysts are not heads-down,detail-obsessed, engineering-types. They have to understand the often fuzzyfeature requests and deal with the uncertainty and change that comes with theterrain of business departments and business people. Testers can be somewhatmore methodical, but they also must adapt to the changes


AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.