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. 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 par Adigms. While applying engineering principles to the Software design phase works well, assuming can implement the design in th E same manner used by + traditional engineering approaches is unrealistic.
Both business and software is 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 a S bridge construction. It is highly unlikely so you'll be asked to move the location of a bridge halfway through a construction project. However, it's very likely that the acquisition of a business partner would require you to add support for Organization-bas Ed Content management to an application. This comparison should put things into perspective. We often say that software architecture decisions is difficult to change but not nearly so much as things that is Litera Lly and figuratively set in stone.
Knowing the products we build is pliable and that the requirements sur-rounding them is likely to change puts us in a D Ifferent position than someone building an immovable object. Engineering endeavors of the physical flavor is much easier to implement in a ' plan the work, work the plan ' nature. With software, things need to being tackled in more than a "plan the work, massage the plan" fashion.
?
?? These differences aren ' t always bad news-at times they can be advantageous. For example, your ' re not necessarily constrained to building the components of a software system in a specific order so Can tackle high-risk issues first. This was in direct contrast to something like bridge construction, where there be many physical limitations surrounding th E order in which tasks is accomplished.
However, the flexibility of software engineering does present some issues, many of which are self-imposed. As architects, we is very aware of the "soft" nature of our craft and we like to solve problems. Worse yet, the business own-ers is 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 the can break an otherwise healthy project.
Remember A requirements document is a blueprint, and software doesn ' t really exist. The virtual objects that we create was easier to change than their Physical-world counterparts which was a good thing Beca Use the 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.

Software doesn ' t really Exist