Commented Code

Nov 28, 2012

Add some Doomsday to your Design

While walking through a basic security model with one of the developers at work I overheard a conversation being had about the concepts for a new platform. The project starting months ago as a single Hardware/Software platform for an expanding product line, but recently moved to multiple CPU architectures for the low and high end versions and two completely different Operating Systems due to power requirements that could not be fulfilled with the single architecture. My scalp burned as I could sense the hair in that cubical was being pulled with extreme prejudice.

After having spent the previous hour going through a project risk assessment trying to come up with every inconceivable problem that could occur, I started to think of every time my design had to do a complete 180 because some major, unforeseen change occurred.

Most of the projects I work on start with requirements from Marketing which Engineering takes and attempts to refine down to a well defined list of developmental tasks. "The widget should do this, the widget should not do that..." Hopefully after months of massaging you end up with a pretty good road map of how to get the project done.

Inevitably, the proverbial wrench will be thrown into the works. Hardware and software will need to be modified or completely redone. In the best case scenario you accounted for this in your project plan. All you can hope for is enough time to resolve the change.

Listening to the two developers try to resolve their externally induced technical issue I could tell they had never thought of the new scenario as it was not directly scoped into the project. When doing the risk analysis of the overall project we added a generic "Project Scope Change" risk but didn't go any further. What if we had?

When you design a User Interface you try to visualize all sorts of crazy ways user might click or type to make sure they can't break your system. When designing a communication protocol you perform Fuzz Testing to eliminate security holes. In all our attempts to cater to the least common denominator in all facets of our application we never truly considered our development process as an effect on our project. Marketing can change scope, cost and power requirements can change our hardware choices, a library may deprecate part of its API. If we knew that half way through our project the processor we selected for all our platforms wouldn't fit our low end customers our design may have been different.

Hardware and OS extraction layers exist to reduce the dependencies of our application for a fixed system. We tend not to use them unless we know in advance (or run into an issue) that we will have differing systems. Why do we wait until that point to decide that this is a viable model? Sure you loose direct contact with the system and it may cause additional overhead but we don't venture down that path unless there is an obvious need.

In Risk Management, however, we are looking for the non-obvious cases. We dream up risks with both high and low probabilities and high and low impacts to come up with the best case resolution. During our design and implementation phase the worrisome dreamer seems to fade away. Maybe we need to incorporate a little "self-imposed" Doomsday Prophecies into our design and implementation. Your office may not be in a 100-Year Flood Plain but the yearly Marketing Scope Creep is right around the corner.

<perm> | /devel | 2012.11.28-06:50.00 | <comments> | <reddit> | <digg> | <stumbleupon> | <tweet>