Archive
Design Disclosure
Recently, I had to publicly disclose the design of the multi-threaded CSCI (Computer Software Configuration Item) that I’m currently bringing to life with a small group of colleagues. The figure below shows the entities (packages, CSCs (Computer Software Components), Classes) and the inter-entity relationship schema that I used to create the CSCI design artifacts.
As the figure illustrates, the emerging CSCI contains M packages and K top level CSCs . Each package contains from 1 to N 2nd level CSCs that associate with each other via the “communicates” (via messages) relationship. Each CSC is of the “passive” or “active” class type, where “active” means that the CSC executes within its own thread of control.
Using the schema, I presented the structural and behavioral aspects of the design as a set of views:
- The threads view (behavioral )
- The packages view (structural)
- The class diagrams view (structural)
- The sequence diagrams view (behavioral)
Like any “real” design effort (and unlike the standard sequential design-code-test mindset of “authorities“), I covertly used the incremental and iterative PAYGO methodology (design-a-little, code-a-little, test-a-little, document-a-little) in various mini sequences that, shhhh – don’t tell any rational thinker, just “felt right” in the moment.
As we speak, the effort is still underway and, of course, the software is 90% done. Whoo Hoo! Only 10 more percent to go.
Invisible, Thus Irrelevant
A system that has a sound architecture is one that has conceptual integrity, and as (Fred) Brooks firmly states, “conceptual integrity is the most important consideration in system design”. In some ways, the architecture of a system is largely irrelevant to its end users. However, having a clean internal structure is essential to constructing a system that is understandable, can be extended and reorganized, and is maintainable and testable.
The above paragraph was taken from Booch et al’s delightful “Object-Oriented Analysis And Design With Applications“. BD00’s version of the bolded sentence is:
In some ways, the architecture of a system is largely irrelevant to its end users, its developers, and all levels of management in the development organization.
If the architecture is invisible because of the lack of a lightweight, widely circulated, communicated, and understood, set of living artifacts, then it can’t be relevant to any type of stakeholder – even a developer. As the saying goes: “out of site, out of mind“.
Despite the long term business importance of understandability, extendability, reorganizability, maintainability, and testability, many revenue generating product architectures are indeed invisible – unlike short term schedulability and budgetability; which are always highly visible.
A Bunch Of STIFs
In “Object-Oriented Analysis and Design with Applications“, Grady Booch argues that a successful software architecture is layered, object-oriented, and evolves over time as a series of STIFs – STable Intermediate Forms. The smart and well liked BD00 agrees; and he adds that unsuccessful architectures devolve over time as a series of unacknowledged UBOMs (pronounced as “You Bombs“).
UBOMs are subtle creatures that, without caring stewardship, can unknowingly sneak up on you. Your first release or two may start out as a successful STIF or a small and unobtrusive UBOM. But then, since you’ve stepped into UBOM-land, it can grow into an unusable, resource-sucking abomination. Be careful, very careful….
“Who advocates for the product itself—its conceptual integrity, its efficiency, its economy, its robustness? Often, no one.” – Fred Brooks
“Dear Fred, when the primary thought held steadfast in everybody’s mind is “schedule is king” instead of “product is king“, of course no one will often advocate for the product.” – BD00
Movement And Progress
In collaboration with a colleague, I’m currently designing, writing, and testing a multi-threaded, soft-real-time application component for a distributed, embedded sensor system. The graph below shows several metrics that characterize our creation.
The numbers associated with the most recent 9/22/11 time point are:
Of course, the pretty graph and its associated “numbers” don’t give any clue as to the usefulness or stability of our component, but “movement” is progressing forward. Err, is it?
Don’t confuse movement with progress – Tom Peters
What’s your current status?
Ubiquitous Dishonorability
While reading the delightful “Object-Oriented Analysis and Design with Applications“, Grady Booch et al extol the virtues of object-oriented analysis over the venerable, but passe, structured analysis approach to front end system composition. As they assert below, one of the benefits of OOA is that it’s easier and more natural to avoid mixing concrete design details with abstract analysis results.
Out of curiosity (which killed the cat), I scrolled down to see what note [4] meant:
WTF? Do they mean “because that’s the way the boss sez it must be done!” and “because that’s the way we’ve always done it!” aren’t honorable reasons for maintaining the status quo? If so, then dishonorable behavior runs rampant within the halls of most software shops the world over. But you already knew that, no?
Home Grounds
In Barry Boehm and Richard Turner‘s book, “Balancing Agility And Discipline“, they present the concept of the “home ground“. Agile and plan-driven (a.k.a. waterfall) software development methodologies each have their own turf where one is superior to the other for getting the job done within time, budget, and quality constraints.
As the figure below shows, the Boehm/Turner definition of “home ground” is based on 5 dimensions: personnel (experience/expertise), criticality, dynamism, size, culture.
At the origin of the 5 dimensional chart, where dynamism is high, culture is liberally open, project size is small, criticality of application is low, and the majority of the project staff is highly competent, agile approaches are more effective and efficient and efficacious. At the extremes of the 5 axes, plan-driven approaches are more effective and efficient and efficacious.
Do you think Boehm and Turner have got it right? Are there any dimensions missing from their model; like level of management humility, quality of management-knowledge worker relationships, quality of tools, quality of physical work environment?
Definition Of Done
When the definition of “done” for a software development project is solely based on allocated time and budget, it’s relatively easy to be perceived as successful. When the schedule and budget are exhausted: the work stops, the software is delivered/released/deployed, and victory is unequivocally declared. Whoo Hoo! As long as the software runs, regardless of its quality and usefulness, all is well – in the short run.
When the achievement of one or more difficult-to-measure, but meaningful, quality metrics is added as a third criterion to the easily measured time and budget metrics, the meaning of “done” becomes less vague and more realistic. That’s why it’s rarely done in practice.
Ya see, CLORGs and DYSCOs are full of themselves. By not measuring the things that matter for long term viability, they can stay infallibly full of themselves till the fit hits the shan.
No, I’m Argyle
When something is so over-hyped like, say, “agile“, if you try it out and don’t find it to be effective, the high priests will tell you that you’re doing it wrong. If you don’t try it out because your common sense and experience tell you it won’t work effectively in the context you’re in, then the high priests will call you a Luddite. The high priests of anything over-hyped always have their bases covered, no?
The Elephants In The Room
One of the originators of RUP and the creator of the 4+1 view modeling approach, Phillippe Kruchten, has written a terrific article on the “twenty elephants in the room” that haunt the agile movement. Here’s a subset of his infamous list that resonates with me:
- Commercial interests censoring failures (tell me about the failures).
- Failure to dampen negative behaviours (no analysis of failures).
- Context and contextual applicability of practices (can you say “safety-critical systems“?)
- Anarchism (preventing a more systematic organization of the body of knowledge).
- Elitism (blame failure on the “unenlightened” others)
- Certification (effective tool to assess maturity for individuals and organization, or commercial ploy from trainers and consultants to rake in the dough?)
- Role of architecture and design (they are still often equated to BUFD, and rapidly brushed aside with claims of YAGNI, or “we’ll refactor it later”)
- Scaling naïveté (with a bit of imagination all agile practices scale up, and if this does not work it is because you have not tried hard enough).
- Technical debt (while agile practices could help control technical debt, they are also often at the root, the cause of massive technical debt).
- Effective ways of discovering information without writing source code (uh, can you say “modeling“?).
Of course, because of his involvement in the development of the perceived horrible, heavyweight, RUP process, extreme agilistas will not even listen to Phillippe’s ideas – let alone ponder the validity of any of them.
Learn To Estimate?
Item number 50 in “97 Things Every Programmer Should Know” is titled:
Since most schedules magically appear from the heavens without any input from below, why is there a need to learn how to estimate? If, by chance, schedule inputs ARE solicited from those who will do the work, they’re often ignored since heavenly commitments have already been made behind the scenes.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 