Song of The Day: What’d I Say - Artist: Ray Charles

Software engineering is an interesting beast.

On the one hand it is similar to various other engineering disciplines like hardware, civil, or mechanicial engineering. It’s similar in that it requires some engineering fundamentals to “get started.” Furthermore, some of the software development life cycle resembles other engineering life cycles (e.g., design, construction, testing, etc.).

However, it is unique in many aspects.

Firstly, software engineering projects are organic IMHO, and they mutate. Although it is good to spend time up-front to get a high-level conceptual design using something like UML, ERD, or some derivative, the design may not be entirely complete until the project “ships” or gets certified. I think this makes software engineering “fairly” unique, and an avenue of frustration, for folks. If you have difficulty with this supposition, try reading an older, but still good, article that declares the source as the ultimate design document. Although other engineering fields have adopted hybrid approaches, I think the article still stands–at least in some development circles.

Secondly, because of its organic nature, software engineering does not always fit well in a strict waterfall model of “15% design, 55% construction, 20% testing, and 10% deployment”–or some familar derivative like in other engineering fields. For evidence of this one only needs to review the plethora of agile methodologies out there. All of them attempt to foster frequent communication and frequent review of what is being developed throughout a “generic” SDLC, thus trying to improve any deficiencies of a strict waterfall approach.

So a team today spends 10-15% of their time making boxes and connections in Visio or in something like Visual Paradigm and then another 50% or more of their time designing during the construction/coding and testing. This can be uniquely surprising to developers, as an organic code base mutates, overwhelming the most experienced; moreover, the experience can also be uniquely frustrating for others as they wonder why there are “new found” design issues in QA?

The comparison and contrast could continue, but what is one to do about this apparent quandary? Well, pray comes to mind :) and/or retain and hire experienced folks, but I think there are a few good rules of thumb that can help in general (i.e., from a developer’s perspective):

  • Use time up-front to do some design-only discussions with diagrams, etc. 10% seems like a good number even in “agile cycles” (see below).
  • Ensure that the folks that are writing the software have some design and communication skills since a majority of design may come during construction.
  • Along with “designing,” developers should be continuously debugging and testing their “designs” (i.e., algorithms, structures, interfaces, etc.)
  • Adopt an agile development process, XP of late or Scrum of yesterday, a specific one may not matter that much, but adopting a “process” that gets folks communicating and collaborating throughout a software development life cycle is key.
  • Good programmers and agile processes are not a substitute for engineering fundamentals. The bullets above are for “wrapping” underlying principles. For example, if one does the above but doesn’t have a way to manage source code, the project may become more fragile than agile.
  • All teams, not just technical, need to be on the “same page” regarding the SDLC and its execution.

Delivering software can still be an unnatural act of course with all guidelines followed, so there may be something to just grinding it out too. :) Happy developing!

Tags: ,