Posts Tagged ‘software design’

Time For A Toga Party!

December 21, 2012 4 comments


Three Degrees Of Distribution

December 19, 2012 2 comments

Behold the un-credentialed and un-esteemed BD00′s taxonomy of software-intensive system complexity:

Three Degrees

How many “M”s does the system you’re working on have? If the answer is three, should it really be two? If the answer is two, should it really be one? How do you know what number of “M”s your system design should have? When tacking on another “M” to your system design because you “have to“, what newly emergent property is the largest complexity magnifier?

Now, replace the inorganic legend at the top of the page with the following organic one and contemplate how the complexity and “success” curves are affected:

Social Legend

Defect Density

December 13, 2012 1 comment

ln “Software’s Hidden Clockwork: A General Theory of Software Defects“, Les Hatton presents these two interesting charts:

The thing I find hard to believe is that Les has concluded that there is no obvious significant relationship between defect density and the choice of programming language. But notice that he doesn’t seem to have any data points on his first chart for the relatively newer, less “tricky“, and easier-to-program languages like Java, C#, Ruby, Python, et al.

So, do you think Les might have jumped the gun here by prematurely asserting the virtual independence of defect density on programming language?

Proximity In Space And Time

December 7, 2012 Leave a comment

When a failure occurs in a complex, networked, socio-technical system, the probability is high that the root cause is located far away from the failure detection point in time, space, or both. The progression in time goes something like this:

fault ———–> error———-> error—————–>error——>failure discovered!

An unanticipated fault begets an error, which begets another error(s), which begets another error(s), etc, until the failure is manifest via loss of life or money somewhere and sometime downstream in the system. In the case of a software system, the time from fault to catastrophic failure may take milliseconds, but the distance between fault and failure can be in the 100s of thousands of lines of source code sprinkled across multiple machines and networks.

Let’s face it. Envisioning, designing, coding, and testing for end-to-end “system level” error conditions in software systems is unglamorous and tedious (unless you’re using Erlang – which is thoughtfully designed to lessen the pain). It’s usually one of the first things to get jettisoned when the pressure is ratcheted up to meet some arbitrary schedule premised on a baseless, one-time, estimate elicited under duress when the project was kicked-off. Bummer.

Code First And Discover Later

November 28, 2012 1 comment

In my travels through the whacky world of software development, I’ve found that bottom up design (a.k.a code first and “discover” the real design later) can lead to lots of unessential complexity getting baked into the code. Once this unessential complexity, in the form of extraneous classes and a rats nest of unneeded dependencies, gets baked into the system and the contraption “appears to work” in a narrow range of scenarios, the baker(s) will tend to irrationally defend the “emergent” design to the death. After all, the alternative would be to suffer humility and perform lots of risky, embarrassing, and ego-busting disentanglement rework. Of course, all of these behaviors and processes are socially unacceptable inside of orgs with macho cultures; where publicly admitting you’re wrong is a career-ending move. And that, my dear, is how we have created all those lovable, “legacy” systems that run the world today.

Don’t get BD00 wrong here. The esteemed one thinks that bottom up design and coding is fine for small scoped systems with around 7 +/- 2 classes (Miller’s number), but this “easy and fun and fast” approach sure doesn’t scale well. Even more ominously, the bottom up coding and emergent design strategy is unacceptable for long-lived, safety-critical systems that will be scrutinized “later on” by external technical inspectors.

Faking Rationality

November 24, 2012 8 comments

I recently dug up and re-read the classic Parnas/Clement 1986 paper: “A Rational Design Process: How And Why To Fake It“. Despite the tendency of people to want to desperately believe the process of design is “rational“, it never is. The authors know there is no such thing as a sequential, rational design process where:

  • There’s always a good reason behind each successive design decision.
  • Each step taken can be shown to be the best way to get to a well defined goal.

The culprit that will always doom a rational design process is “learning“:

Many of the details only become known to us as we progress in the implementation (of a design). Some of the things that we learn invalidate our design and we must backtrack (multiple times during the process). The resulting design may be one that would not result from a rational design process. – Parnas/Clements

Since “learning“, in the form of going backwards to repair discovered mistakes, is a punishable offense in social command & control hierarchies where everyone is expected to know everything and constantly march forward, the best strategy is to cover up mistakes and fake a rational design process when the time comes to formally present a “finished” design to other stakeholders.

Even though it’s unobtainable, for some strange reason, Spock-like rationality is revered by most orgs. Thus, everyone in org-land plays the “fake-it” game, whether they know it or not. To expect the world to run on rationality is irrational.

Executives preach “evidence-based decision-making“, but in reality they practice “decision-based evidence-making“.

Annoying And Disappointing

November 23, 2012 4 comments

Atego’s Artisan Real-Time Studio, Sparx’s Enterprise Architect, and IBM’s Rational Rhapsody are big and expensive UML  modeling tools. You would think they support all of the basic visual modeling elements of the UML, no?

On the left side of the figure below, I show the four fundamental, visual UML symbols for conjuring up (wrong, incomplete, and inconsistent) structural views of an object-oriented software system in the form of class diagrams, deployment diagrams, component diagrams, etc.

It blows BD00′s already incoherently twisted mind that Artisan Studio doesn’t provide visual elements for a UML Node or a Component. As can be seen on the right side of the figure, the work-around is to use stereotyped Classifier elements to fill the void. It’s annoying and disappointing, dontcha think?

But hey, not many people (especially extreme left-wing agile zealots) buy into the potential of the UML for shortening the development time and long-term cost of big, sprawling, long-lived software systems . So, “meh” to this irrelevant post.

Note: I’m a relatively newbie user of Artisan Studio. If you’re an advanced user and you know that I’m mistaken here, then please speak up and tell me how to find these two seemingly-hidden buggers.

Too Detailed, Too Fast

October 16, 2012 Leave a comment

One of the dangers system designers continually face is diving into too much detail, too fast. Given a system problem statement, the tendency is to jump right into fine-grained function (feature) definitions so that the implementation can get staffed and started pronto. Chop-chop, aren’t you done yet?

The danger in bypassing a multi-leveled  analysis/synthesis effort and directly mapping  the problem elements into concrete, buildable functions is that important, unseen, higher level relationships can be missed – and you may pay the price for your haste with massive downstream rework and integration problems. Of course, if the system you’re building is simple enough or you’re adding on to an existing system, then the skip level approach may work out just fine.


October 13, 2012 Leave a comment

Unsurprisingly, one of BD00′s posts irritated a reader who stumbled upon it. For some strange reason, BD00′s scribblings have that effect on some people. In the irritating post, “The Old Is New Again“, BD00 referred to Data and Control Flow diagrams as “old and obsolete“. In caustic BD00 fashion, the reader commented:

Use Cases and Activity Diagrams, in contrast (to the Data Flow diagram), offer little guidance in effective partitioning. They rely upon the age old “sledge hammer” approach to partitioning” (ie, just break-er-up any way you can). Sledge hammer partitioning is what cave men used to partition entities. So in a critical sense, DFD’s are new and hip, while Use Cases and Activity Diagrams are based upon logic that is older than dirt.

BD00 likes all visual modeling tools – including the DFD hatched during the heyday of structured analysis. BD00 only meant “old and obsolete” in the sense that DFDs pre-dated the arrival of the UML and the object-oriented approach to system analysis and design. However, BD00 did feel the need to correct the reader’s misunderstanding of the features and capabilities that UML Activity Diagrams offer up to analysts/designers.

Both the DFD and UML activity diagram pair below equivalently capture an analyst’s partitioning design decision (where DFD Process X == Activity Diagram Action X). Via “swimlanes“, the lower activity diagram makes the result of a second design decision visible: the conscious allocation of the Actions to the higher level Objects that will perform them during system operation. So, how are UML activity diagrams inferior to DFDs in supporting partitioning? A rich palette of other symbols (forks, joins, decisions, merges, control flows, signals) are also available to analysts (if needed) for capturing design decisions and exposing them for scrutiny.

DFDs and UML diagrams are just tools – job performance aids. Learning how to use them, and learning how to use them effectively, are two separate challenges. Design “guidance” for system partitioning, leveling, balancing, etc, has to come from somewhere else. From a mentor? From personal experience learning how to design systems over time? From divine intervention?

Bounded Solution Spaces

September 29, 2012 2 comments

As a result of an interesting e-conversation with my friend Charlie Alfred, I concocted this bogus graphic:

Given a set of requirements, the problem space is a bounded (perhaps wrongly, incompletely, or ambiguously) starting point for a solution search. I think an architect’s job is to conjure up one or more solutions that ideally engulf the entire problem space. However, the world being as messy as it is, different candidates will solve different parts of the problem – each with its own benefits and detriments. Either way, each solution candidate bounds a solution space, no?


Get every new post delivered to your Inbox.

Join 438 other followers

%d bloggers like this: