Archive
Linear Culture, Iterative Culture
A Linear Think Technical Culture (LTTC) equates error with sin. Thus, iteration to remove errors and mistakes is “not allowed” and schedules don’t provide for slack time in between sprints to regroup, reflect and improve quality . In really bad LTTCs, errors and mistakes are covered up so that the “perpetrators” don’t get punished for being less than perfect. An Iterative Think Technical Culture (ITTC) embraces the reality that people make mistakes and encourages continuous error removal, especially on intellectually demanding tasks.
The figure below shows the first phase of a hypothetical two phase project and the relative schedule performance of the two contrasting cultures. Because of the lack of “Fix Errors” periods, the LTTC reaches the phase I handoff transition point earlier .
The next figure shows the schedule performance of phase II in our hypothetical project. The LTTC team gets a head start out of the gate but soon gets bogged down correcting fubars made during phase I. The ITTC team, having caught and fixed most of their turds much closer to the point in time at which they were made, finishes phase II before the LTTC team hands off their work to the phase III team (or the customer if phase II is that last activity in the project).
It appears that project teams with an ITTC always trump LTTC teams. However, if the project complexity, which is usually intimately tied to its size, is low enough, an LTTC team can outperform an ITTC team. The figure below illustrates a most-likely-immeasurable “critical project size” metric at which ITTC teams start outperforming LTTC teams.
The mysterious critical-project-size metric can be highly variable between companies, and even between groups within a company. With highly trained, competent, and experienced people, an LTTC team can outperform an ITTC team at larger and larger critical project sizes. What kind of culture are you immersed in?
What The Hell’s A Unit?
- CSCI = Computer Software Configuration Item
- CSC = Computer Software Component
- CSU = Computer Software Unit
In my industry (aerospace and defense), we use the abstract, programming-language-independent terms CSCI, CSC, and CSU as a means for organizing and conversing about software architectures and designs. The terms go way back, and I think (but am not sure) that someone in the Department Of Defense originally conjured them up.
The SysML diagram below models the semantic relationships between these “formal” terms. An application “contains” one or more CSCIs, each of which which contains one or more CSCs, each of which contains one or more CSUs. If we wanted to go one level higher, we could say that a “system” contains one or more Applications.
In my experience, the CSCI-CSC-CSU tree is almost never defined and recorded for downstream reference at project start. Nor is it evolved or built-up as the project progresses. The lack of explicit definition of the CSCs and, especially the CSUs, has often been a continuous source of ambiguity, confusion, and mis-communication within and between product development teams.
“The biggest problem in communication is the illusion that it has taken place.” – George Bernard Shaw.
A consequence of not classifying an application down to the CSU level is the classic “what the hell’s a unit?” problem. If your system is defined as just a collection of CSCIs comprised of hundreds of thousands of lines of source code and the identification of CSCs and CSUs is left to chance, then a whole CSCI can be literally considered a “unit” and you only have one unit test per CSCI to run (LOL!)
In preparation for an idea that follows, check out the language-specific taxonomies that I made up (I like to make stuff up so people can rip it to shreds) for complex C++ and Java applications below. If your app is comprised of a single, simple process without any threads or tasks (like they teach in school and intro-programming books), mentally remove the process and thread levels from the diagram. Then just plop the Application level right on top of the C++ namespace and/or the Java package levels.
To solve, or at least ameliorate the “what the hell’s a unit?” problem, I gently propose the consideration of the following concrete-to-abstract mappings for programs written in C++ and Java. In both languages, each process in an application “is a” CSCI and each thread within a process “is a” CSC. A CSU “is a” namespace (in C++) or a package (in Java).
I think that adopting a map such as this to use as a standard communication tool would lead to fewer mis-communications between and among development team members and, more importantly, between developer orgs and customer orgs that require design artifacts to employ the CSCI/CSC/CSU terminology.
As just stated, the BD00 proposal maps a C++ namespace or a java package into the lowest level element of abstract organization – the CSU. If that level of granularity is too coarse, then a class, or even a class member function (method in Java), can be designated as a CSU (as shown below). The point is that each company’s software development organization should pick one definition and use it consistently on all their projects. Then everyone would have a chance of speaking a common language and no one would be asking, “what the hell’s a freakin’ unit?“.
So, “What the hell’s a unit?” in your org? A member function? A class? A namespace? A thread? A process? An application? A system?
Standard CCH Blueprint
The figure below is a “bent” UML (Unified Modeling Language) class diagram of a standard corpo CCH (Command and Control Hierarchy). Association connectors were left off because the diagram would be a mess and the only really important relationships are the adjacent step-by-step vertical connections. Each box represents a “classifier”, which is a blueprint for stamping out objects that behave according to the classifier blueprint. The top compartment contains the classifier name, the second compartment contains its attributes, and the third compartment houses the classifier’s behaviors. Except for the DIC Product Development Team, the attributes of all other classifiers were elided away because the intent was to focus on the standard cookie-cutter behaviors of each object in the “system”. Of course, the org you work for is not an instantiation of this system, right?
What Would It be Like?
In this TED video, Sir Ken Robinson asks: “What would the world be like if all knowledge was instantaneously accessible to everyone at any time?” My less ambitious question is “What would the workplace culture be like if every manager, from the pinnacle of power all the way down the chain, made it his/her top (but obviously not only) priority to ensure that every one of his/her direct reports has continuous access to the tools, training, and information to get their jobs done?
Malcontents
Everyone’s heard of the stereotypical, disgruntled, malcontented, long time employee (SDMLTE) who “can’t wait to retire”. Why is this Dilbertonian image a stereotype? Because it’s so ubiquitous that it’s unquestioningly accepted by the vast majority of people as “that’s the way it is everywhere”. Well, is it? Do you really think that every organization on this earth has a surplus of SDMLTEs? Call me idealistic, but I assert “no”.
I opine that there are few (very, very, very, very, few) companies whose old warhorses, graybeards and bluehairs are uncommon, happy, content, long time employees (UHCLTE). Compared to the moo-herd of corpocracies that litter the land, these scarce diamonds in the rough have a huge UHCLTE to SDMLTE ratio. I’ll also profer that as a company gets larger, its UHCLTE to SDMLTE ratio decreases. That’s because as a company grows in size, bad management increases while great leadership decreases within the citadel walls – regardless of what the corpo stewards repeatedly espouse. Bummer.
Useless Cases
Despite the blasphemous title of this blarticle, I think that “use cases” are a terrific tool for capturing a system’s functional requirements out of the ether; for the right class of applications. Nevertheless, I agree with requirements “expert” Karl Wiegers, who states the following in “More About Software Requirements: Thorny Issues And Practical Advice“:
However, use cases are less valuable for projects involving data warehouses, batch processes, hardware products with embedded control software, and computationally intensive applications. In these sorts of systems, the deep complexity doesn’t lie in the user-system interactions. It might be worthwhile to identify use cases for such a product, but use case analysis will fall short as a technique for defining all the system’s behavior.
I help to define, specify, design, code, and test embedded (but relatively “big”) software-intensive sensor systems for the people-transportation industry. The figure below shows a generic, pseudo-UML diagram of one of these systems. Every component in the string is software-intensive. In this class of systems, like Karl says, “the deep complexity doesn’t lie in the user-system interactions”. As you can see, there’s a lot of special and magical “stuff” going on behind the GUI that the user doesn’t know about, and doesn’t care to know about. He/she just cares that the objects he/she wants to monitor show up on the screen and that the surveillance picture dutifully provided by the system is an accurate representation of what’s going on in the real world outside.
A list of typical functions for a product in this class may look like this:
- Display targets
- Configure system
- Monitor system operation
- Tag target
- Control system operation
- Perform RF signal filtering
- Perform signal demodulation
- Perform signal detection
- Perform false signal (e.g. noise) rejection
- Perform bit detection, extraction, and message generation
- Perform signal attribute (e.g. position, velocity) estimation
- Perform attribute tracking
Notice that only the top five functions involve direct user interaction with the product. Thus, I think that employing use cases to capture the functions required to provide those capabilities is a good idea. All the dirty and nasty”perform” stuff requires vertical, deep mathematical expertise and specification by sensor domain experts (some of whom, being “expert specialists”, think they are Gods). Thus, I think that the classical “old and unglamorous” Software Requirements Specification (SRS) method of defining the inputs/processing/output sequences (via UML activity diagrams and state machine diagrams) blows written use case descriptions out of the water in terms of Return On Investment (ROI) and value transferred to software developers.
Clueless Bozo Managers (BMs) and senior wannabe-a-BM developers who jump on the “use cases for everything” bandwagon (but may have never written a single use case description themselves) waste company time and money trying to bully “others” into ramming a square peg into a round hole. But they look hip, on the ball, and up to date doing it. And of course, they call it leadership.
Doing And Being
Echkart Tolle has stated that every human being has an inner purpose and an outer purpose. According to Mr. Tolle, our inner purpose is “being” and our outer purpose is “doing”. Along similar lines, Mother Theresa once said something to the effect that “the west is materially rich (from doing) but spiritually poor (from not being)”. I’m on-board with these related insights because I’ve realized them through personal experience. How about you?
A problem that I see with western cultures is that most people have their self worth totally fused with “doing”, while “being” is often disdained, looked down upon, and interpreted as sloth/laziness. There is no balance, and I’m one of those unabalanced (lol!) people. Do I have “factual evidence” to back this up? Of course not. I’m not a world renowned expert and I only speak from personal experience. Plus, I like to make stuff up.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 