Posts Tagged ‘design’

Emergent Design

I’m somewhat onboard with the agile community’s concept of “emergent design“. But like all techniques/heuristics/rules-of-thumb/idioms, context is everything. In the “emergent design” approach, you start writing code and, via a serendipitous, rapid, high frequency, mistake-making, error-correction process, a good design emerges from the womb – voila! This technique has worked well for me on “small” designs within an already-established architecture, but it is not scalable to global design, new architecture, or cross-cutting system functionality. For these types of efforts, “emergent modeling” may be a more appropriate approach. If you believe this, then you must make the effort to learn how to model, write (or preferably draw) it up, and iterate on it much like you do with writing code. But wait, you don’t do, or ever plan to do, documentation, right? Your code is so self-expressive that you don’t even need to comment it, let alone write external documentation. That crap is for lowly English majors.

To religiously embrace “emergent design” and eschew modeling/documentation for big design efforts is to invite downstream disaster and massive post delivery stakeholder damage. Beware because one of those downstream stakeholders may be you.

BS Design

Sorry, but I couldn’t resist naming the title of this post as it is written. However, despite what you may have thought on first glance, BS stands for dee man, Bjarne Stroustrup. In chapter 23 of “The C++ Programming Language“, Bjarne offers up this advice regarding the art of mid-level design:

To find out the details of executing each iterative step in the while(not_done){} loop, go buy the book. If C++ is your primary programming language and you don’t have the freakin’ book, then shame on you.

Bjarne makes a really good point when he states that his unit of composition is a “component”. He defines a component as a cluster of classes that are cohesively and logically related in some way.

A class should ideally map directly into a problem domain concept, and concepts (like people) rarely exist in isolation. Unless it’s a really low level concrete concept on the order of a built in type like “int”, a class will be an integral player in a mini system of dynamically collaborating concepts. Thinking myopically while designing and writing classes (in any language that directly supports object oriented design) can lead to big, piggy classes and unnecessary dependencies when other classes are conceived and added to the kludge under construction – sort of like managers designing an org to serve themselves instead of the greater community. 🙂

The figure below shows “revision 0” of a mini system of abstract classes that I’m designing and writing on my current project. The names of the classes have been elided so that I don’t get fired for publicly disclosing company secrets. I’ve been architecting and designing software like this from the time I finally made the painful but worthwhile switchover to C++ from C.

The class diagram is the result of “unconsciously” applying step one of Bjarne’s component design process. When I read Bjarne’s sage advice it immediately struck a chord within me because I’ve been operating this way for years without having been privy to his wisdom. That’s why I wrote this blowst – to share my joy at discovering that I may actually be doing something right for a change.

Processes, Threads, Cores, Processors, Nodes

May 27, 2010 3 comments

Ahhhhh, the old days. Remember when the venerable CPU was just that, a CPU? No cores, no threads, no multi-CPU servers. The figure below shows a simple model of a modern day symmetric multi-processor, multi-core, multi-thread server. I concocted this model to help myself understand the technology better and thought I would share it.

The figure below shows a generic model of a multi-process, multi-threaded, distributed, real-time software application system. Note that even though they’re not shown in the diagram, thread-to-thread and process-to-process interfaces abound. There is no total independence since the collection of running entities comprise an interconnected “system” designed for a purpose.

Interesting challenges in big, distributed system design are:

  • Determining the number of hardware nodes (NN) required to handle anticipated peak input loads without dropping data because of a lack of processing power.
  • The allocation of NAPP application processes to NN nodes (when NAPP > NN).
  • The dynamic scheduling and dispatching of software processes and threads to hardware processors, cores, and threads within a node.

The first two bullets above are under the full control of system designers, but not the third one. The integrated hardware/software figure below highlights the third bullet above. The vertical arrows don’t do justice to the software process-thread to hardware processor-core-thread scheduling challenge. Human control over these allocation activities is limited and subservient to the will of the particular operating system selected to run the application. In most cases, setting process and thread priorities is the closest the designer can come to controlling system run-time behavior and performance.

Pick And Own

No, the title of this blost (short for blog-post and pronounced “blow-ssst”) is not “pick your nose“. It’s “pick and own“. My friend Bill Livingston uses the following catchy and true phrase throughout his book “Design For Prevention“:

He who picks the parts owns the behavior. – Unknown

This is certainly true in the world of software development for new projects. For maintenance projects, which comprise the vast majority of software work, this dictum also holds:

He who touched the code last owns the stank. – Unknown

Bill also truly but sadly states that when something goes awry, the dude who “picks the parts” or “owns the stank” is immediately sought out for punishment. When everything goes smoothly, the identity of the designer/maintainer magically disappears.

Punishment but no praise. Such is the life of a DIC. BMs, CGHs and CCRATS on the other hand, clever as they are, flip everything upside down. Since they don’t pick or maintain anything, they never get blamed for anything that goes wrong. Going one step further, they constantly praise themselves and their brethren while giddily playing the role of DIC-punisher and blamer.

WTF you say? If you fellow DICsters didn’t know this already, then accept it and get used to it because it’ll sting less when it happens over and over again. Tis the way the ancient system of patriarchical CCH institutions is structured to work. It doesn’t matter who the particular cast of characters in the upper echelons are. They could individually be great guys/gals, but their collective behavior is ubiquitously the same.

The Best Defense

April 19, 2010 4 comments

In “The Design Of Design“,  Fred Brooks states:

The best defense against requirements creep is schedule urgency.

Unfortunately, “schedule urgency” is also the best defense against building a high quality and enduring system. Corners get cut, algorithm vetting is skipped, in-situ documentation is eschewed, alternative designs aren’t investigated, and mistakes get conveniently overlooked.

Yes, “schedule urgency” is indeed a powerful weapon. Wield it carefully, lest you impale yourself.

Unconstrained To Constrain

April 13, 2010 1 comment

As I continue to slowly inhale Fred Brooks‘s book, “The Design Of Design“,  I’m giddily uncovering  all kinds of diamonds in the rough. Fred states:

“If designers use a structured annotation or software tool during design it will restrict the ease of having vague ideas, impeding conceptual design.”

Ain’t that the truth? Don’t those handcuffing “standard document templates, processes, procedures, work instructions” that you’re required to follow to ensure quality (lol!) frustratingly constrain you from doing your best work?

Along the same lines, Fred hits another home run in my ballpark (which is devoid of adoring and paying fans, of course):

“I believe that a generic diagramming tool, with features such as automatic layout of trees, automatic rerouting of relationship arrows, and searchable nodes, is better suited to (design) tree capture. Microsoft Visio or SmartDraw might be such a choice.”

Man, this one almost made me faint and lose consciousness. I live, eat, and breath “Visio”. Every picture that you’ve seen in this blog and every design effort that I undertake at work starts with, and ends with, Visio – which is the greatest tool of expression I’ve ever used. I’ve tried “handcuffers” like Artisan Studio and Enterprise Architect as software design aids, but they were too frustratingly complex and constraining to allow me to conjure up self-satisfying designs.

All designs must eventually be constrained so that they can be built and exploited for profit. But in order to constrain, one must be unconstrained. How’s that for a zen-like paradox?

Conceptual Integrity

April 8, 2010 1 comment

Like in his previous work, “The Mythical Man Month“, in “The Design Of Design“, Fred Brooks remains steadfast to the assertion that creating and maintaining “conceptual integrity” is the key to successful and enduring designs. Being a long time believer in this tenet, I’ve always been baffled by the success of Linux under the free-for-all open source model of software development. With thousands of people making changes and additions, even under Linus Torvalds benevolent dictatorship, how in the world could the product’s conceptual integrity defy the second law of thermodynamics under the onslaught of such a chaotic development process?

Fred comes through with the answers:

  1. A unifying functional specification is in place: UNIX.
  2. An overall design structure, initially created by Torvalds, exists.
  3. The builders are also the users – there are no middlemen to screw up requirements interpretation between the users and builders.

If you extend the reasoning of number 3, it aligns with why most of the open source successes are tools used by software developers and not applications used by the average person. Some applications have achieved moderate success, but not on the scale of Linux and other application development tools.

%d bloggers like this: