Software Doesn’t Really Exist

?

Software Doesn’t Really Exist

Chad LaVigne

SoFTWARE EnginEERing iS oFTEn CoMpAREd to well-established dis- ciplines such as civil engineering. There’s a problem with these analogies; unlike the very tangible products created by these traditional practices, soft- ware doesn’t really exist. Not in the traditional sense anyway. Those of us in the world of ones and zeros aren’t constrained by the same physical rules that bind classic engineering paradigms. While applying engineering principles to the software design phase works well, assuming you can implement the design in the same manner used by more traditional engineering approaches is unrealistic.
Both business and software are living, moving entities. Business requirements change rapidly due to things like newly acquired business partners and market- ing strategies. This makes it very difficult to approach a software project in the same manner as a traditional engineering pursuit such as bridge construction. It is highly unlikely that you’ll be asked to move the location of a bridge halfway through a construction project. However, it is very likely that the acquisition of a business partner will require you to add support for organization-based content management to an application. This comparison should put things into perspective. We often say that software architecture decisions are difficult to change but not nearly so much as things that are literally and figuratively set in stone.
Knowing the products we build are pliable and that the requirements sur- rounding them are likely to change puts us in a different position than someone building an immovable object. Engineering endeavors of the physical flavor are much easier to implement in a “plan the work, work the plan” nature. With software, things need to be tackled in more of a “plan the work, massage the plan” fashion.
?
??These differences aren’t always bad news—at times they can be advantageous. For example, you’re not necessarily constrained to building the components of a software system in a specific order so you can tackle high-risk issues first. This is in direct contrast to something like bridge construction, where there are many physical limitations surrounding the order in which tasks are accomplished.
However, the flexibility of software engineering does present some issues, many of which are self-imposed. As architects, we are very aware of the “soft” nature of our craft and we like to solve problems. Worse yet, the business own- ers are vaguely aware of these facts. This makes it easy for them to push big changes. Don’t be too eager to accommodate large architectural changes just because it appeals to your solution-providing nature. Decisions like that can break an otherwise healthy project.
Remember that a requirements document is not a blueprint, and software doesn’t really exist. The virtual objects that we create are easier to change than their physical-world counterparts, which is a good thing because many times they’re required to. It’s OK to plan as though we’re building an immovable object; we just can’t be surprised or unprepared when we’re asked to move said object.