Archive
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.
Different Views
In all triangular CCHs (Command and Control Hierarchies), the DICs (Dweebs In the Cellar) directly create the value added outputs that sustain the enterprise. It’s management’s job (I think?) to ensure that the quality of those outputs is high enough for customers to want to buy the CCH’s products and services over competing CCHs. Of course, there are many ways to accomplish this. One is to inspect the outputs, a second is to get customer feedback, a third is to directly sample intermediate points in the value stream, and a trio of closely coupled others is to; personally descend to the cellar, observe what the DICs see, listen to what the DICs have to say regarding the issues/obstacles they face, and act “aggressively” (corpo-speak for “effectively”) to resolve those issues/obstacles. Note that the verbs, which require “hard work”, are emphasized.
The simple, dorky figure below tries to convey the difference in viewpoint between the DICs and the apex dwellers. Unlike the hierarchs, who operate freely and do whatever they want whenever they want, the DICs operate within a fragmented web of constraining “support” processes and “direction” from former DICs-turned-mini-hierarchs (picture mini-me in the Austin Powers movie franchise). Over time, since the hierarchs (and more importantly, the mini-hierarchs in training) stay away from the dirty and musty cellar and don’t do anything of substance to improve the environment, the stratification increases, the latency from raw input to value-added output increases, and the quality of output decreases. Bummer.
In CCHs with stay-at-home corpocrats, the deterioration in responsiveness and quality often gets detected at that point in time in which the real issues that are wreaking havoc are virtually unsolvable. Even then, the so-called leadership team stays away from the boiler room, speculating from afar at the causes of the performance deterioration. Out of all the methods for continuously monitoring and improving DIC performance, I assert (with no backing scientific evidence, of course) that frequent, periodic trips to the cellar to rub elbow grease with the DICs is the only true way of improving performance. Even if it’s impractical for the supreme hierarchs to do this, it’s not impractical for the mini-hierarchs, dontcha think?
My Company
After reviewing most of the “made up” BS entries that I’ve hoisted on this blog, I’ve noticed (like you, no doubt) that just about every other post either starts out as, or progresses towards, a rant against standard Command and Control Hierarchical (CCH) corpocracies and horrendous managers who delude themselves into thinking they are “leaders”. It’s funny how all freakin’ roads lead to Rome, no?
To set the record straight, I honestly don’t think that all hierarchically structured organizations are soulless and spirit crushing CCHs. One of those companies happens to be the company that I work for; the Sensis Corporation.
I’ve been at Sensis for a long time, and despite what you may have concluded from reading this blog (all 2 of you), I really do like working there. For the most part, I’m given more freedom than most to do what I do best and the list of pluses far outnumbers the list of minuses. Besides matching the standard benefits package that most other companies give their workforce, here are some of the uncommon plusses:
- A CEO that genuinely cares about the people who work for him
- Subsidized in-house cafeteria
- Subsidized in-house gym facility
- No special executive parking spaces
- Special, named parking places for individual handicapped people
- Company-wide profit sharing when yearly sales & profit numbers are met
- Occasional company-wide barbeques
- Quarterly disclosure of the numbers to the troops
- In-house happy hours for significant achievements
- Free lunches at all-hands meetings
- Vacation rollover
- Free coffee
- Summer Hours (Friday afternoons off)
The two biggest pluses for me are:
- No layoffs in the entire 24 year history of the company’s existence and a policy that explicitly states that “no layoffs” is a top goal.
- I haven’t been fired (whoo hoo!) despite multiple exhibitions over the years of truly disrespectful behavior toward a handful of targeted “others”.
The minuses of working at Sensis are typical of any company in our industry (military and aerospace); they’re just not practiced as badly as our bigger and more stodgy peers.
Working Software, Working Documents
Documentation is a love letter that you write to your future self – Damian Conway
The agile software development community rightly says that the best measure of progress is demonstrate-able working software that is delivered incrementally and frequently to customers for their viewing and using pleasure. For the most part, and for good reasons based on historical evidence, agile proponents eschew documentation. Nevertheless, big bureaucratic customers like national and state governments often, very often, require and expect comprehensive documentation from their vendors. Thus, zealot agilist juntas essentially ignore the requirements of a large and deep-pocketed customer base.
It’s software development, not documentation development – Scott Ambler
What if we can bring big, stodgy, conservative, and sometimes-paranoid customers halfway? Why not try to convince them of the merits of delivering frequent and incrementally improving requirements, design, construction, and user documents along with the working software builds? If we pay as we go, incrementally doing a little documentation, doing a little software coding, and doing a little testing instead of piling on the documentation up front or frantically kludging the documents together after the fact, wouldn’t the end result would turn out better?
A consequence of generating crappy documentation for big, long-lived systems is the high cost of downstream maintenance. Dumping hundreds of thousands of lines of code onto the maintenance team without handing them synchronized blueprints is an irresponsible act of disrespect to both the team and the company. Without being able to see the forest for the trees, maintenance teams, which are usually comprised of young and impressionable developers, get frustrated and inject kludged up implementations of new features and bug fixes into the product. Bad habits are formed, new product versions get delivered later and later, and maintenance costs grow higher and higher. Bummer.
Structure And Work
Under the inescapable second law of thermodynamics, fragmentation and dis-integration are natural consequence of organizational growth over time. Real leaders respect and arrest the destructive power of the second law by conscientiously applying structure and work to keep the org intact and aligned toward a higher purpose. All cookie cutter managers know how to design and impose structure. Hell, that’s the easy part because you could look one up in the standard hierarchical patterns handbook (which has only one page and one pattern – the command and control hierarchy where the kahunas at the top rule over the kingdom and ignore input from everyone else).
The “work” is the hard part. Unlike leaders, managers hate work and they’ll do anything, no matter how harmful it is to the org, to avoid it while feigning that they’re bustin’ their butt to “get things done”. Thus, after unveiling his/her latest masterpiece corpo structure, which is always an insignificant hierarchical tweak, he/she “abdicates” the day-to-day work of keeping the fragments in harmony to…….. “others”.
So, what is the “work” part of the powerful, entropy-arresting, work+structure dynamic duo? It’s a continuous and active “sampling the value stream” and a continuous monitoring of the interfaces and interactions between the org fragments to sense signals of disintegration. Without doing the work part, performance will not improve, and of course, it will deteriorate further; triggering yet another round of restructuring to “meet the changing needs of our customers”. Bummer.
Open, Closed, Inquiring
“Every man, wherever he goes, is encompassed by a cloud of comforting convictions, which move with him like flies on a summer day.” – Bertrand Russell
Out of the chute, so to speak, we’re all born with open minds. As we age and accumulate one experience after another, we naturally start forming beliefs based on those experiences. The experiences of other individuals (like our friends and parents) and institutions (like our schools, our corpocracies, and our government) are also impressed upon us. The more similar our new experiences to our previous experiences, the more attached we become to our beliefs. Unknowingly, we’ve started to construct our own very personal “unshakable cognitive burden” (UCB) from the ground up.
As our attachment to (at least some of) those beliefs hardens through exposure to more and more confirming evidence, our minds close up and we start suffering more and more. We tend to conveniently ignore, or violently reject, disconfirming evidence to the contrary in order to preserve our hard earned sense of safety and security. Each subsequent experience causes a nearly instantaneous transition out of, and back into, the closed mind state. Once a core belief (the earth is flat, the sun revolves around the earth, “they” are always right, “—-ism” is infallible) has hardened, intellectual and spiritual growth stops. Stasis sets in. Bummer.
So, how does one break the infinite loop of self-transitions out of, and then back into, the closed UCB mind state? Does another more flexible state exist? I think one may exist- the “Inquiring Mind” state, but I don’t have a clue on how to make the jump to get there. In this state, beliefs still exist but our attachment to them is not absolute. Our level of attachment is fluid and ever changing. As a consequence, our suffering, and more importantly, the suffering of those around us, decreases. The world becomes a kinder and gentler place to live in. We start to recognize our connectedness to all “things” and we empathize with people who still hold fast to their core beliefs.
The state machine below shows one speculative way out of the closed mind state and into the inquiring mind state – the experience of an instantaneous, life-changing epiphany. It’s speculation on my part because I don’t know squat and it’s just a belief that is a brick in my UCB.
Targeted Ire
What we need is more people to lose their temper in public. – Watts Wacker
When you’re dissatisified with a stagnant, risk averse, and status-quo-loving bureaucratic group, how do you blow off steam without alienating or intimidating those few people who help you do your job better and those people you are committed to helping do their jobs better? One approach, which doesn’t work but is incredibly hard to abandon , is “targeted ire“.
When I perceive smug, fat headed executives and managers (of all types) talking up a storm, sucking more out of the org than they put in, and doing nothing of substance to improve everyone’s performance, it’s hard for me to “act professionally” (lol!) and keep my freakin’ mouth shut. In the back of my tortured mind, I often hear a faint and fearful voice saying “STFU you idiot“. Sadly, I find it incredibly hard, if not impossible, to follow that advice. Besides the ever present “fear of excommunication“, I think the fact that I don’t aspire to become a self-important, meeting-loving, and game-playing corpocrat drives my self-destructive behavior. Bummer……. or not?
“Never apologize for showing feeling. When you do so, you apologize for the truth.” – Benjamin Disraeli
So, how do you express your dissatisfaction with a stationary and fading organization when the world is crying out for movement and emergence? Do you do anything about it? Do you assume that you‘re powerless, ignore your passion, and force yourself to STFU? Do you put on “the mask of political correctness” such that your potentially sacred-cow-busting ideas and thoughts get obscured by all the sugar that you coat them with? Are you paralyzed by fear? What do you advise?
Scaleability
The other day, a friend suggested plotting “functionality versus size” as a potentially meaningful and actionable measure of software development process prowess. The figure below is an unscientific attempt to generically expand on his idea.
Assume that the graph represents the efficiency of three different and unknown companies (note: since I don’t know squat and I am known for “making stuff up”, take the implications of the graph with a grain of salt). Because it’s well known by industry experts that the complexity of a software-intensive product increases at a much faster rate than size, one would expect the “law of diminishing returns” to kick in at some point. Now, assume that the inflection point where the law snaps into action is represented by the intersection of the three traces in the graph. The red company’s performance clearly shows the deterioration in efficiency due to the law kicking in. However, the other two companies seem to be defying the law.
How can a supposedly natural law, which is unsentimental and totally indifferent to those under its influence, be violated? In a word, it’s “scaleability“. The purple and green companies have developed the practices, skills, and abilities to continuously improve their software development processes in order to keep up with the difficulty of creating larger and more complex products. Unlike the red company, their processes are minimal and flexible so that they can be easily changed as bigger and bigger products are built.
Either quantitatively or qualitatively, all growing companies that employ unscaleable development processes eventually detect that they’ve crossed the inflection point – after the fact. Most of these post-crossing discoverers panic and do the exact opposite of what they need to do to make their processes scaleable. They pile on more practices, procedures, forms-for-approval, status meetings, and oversight (a.k.a. managers) in a misguided attempt to reverse deteriorating performance. These ironic “process improvement” actions solidify and instill rigidity into the process. They handcuff and demoralize development teams at best, and trigger a second inflection point at worst:
More meetings plus more documentation plus more management does not equal more success. – NASA SEL
Is your process scaleable? If so, what specific attributes make it scaleable? If not, are the results that you’re getting crying out for scaleability?
Percent Complete
In order to communicate progress to someone who requires a quantitative number attached to it, some sort of consistent metric of accomplishment is needed. The table below lists some of the commonly used size metrics in the software development world.
All of these metrics suffer to some extent from a “consistency” problem. The problem (as exemplified in the figure below) is that, unlike a standard metric such as the “meter”, the size and meaning of each unit is different from unit to unit within an application, and across applications. Out of all the metrics in the list, the definition of what comprises a “Function Point” unit seems to be the most rigorous, but it still suffers from a second, “translation” problem. The translation problem manifests when an analyst attempts to convert messy and ambiguous verbal/written user needs into neat and tidy requirement metrics using one of the units in the list.
Nevertheless, numerically-trained MBA and PMI certified managers and their higher up executive bosses still obsessively cling to progress reports based on these illusory metrics. These STSJs (Status Takers and Schedule Jockeys) love to waste corpo time passing around status reports built on quicksand like the “percent done” example below.
The problems with using graphs like this to “direct” a project are legion. First, it is assumed that the TNFP is known with high accuracy at t=0 and, more erroneously, that its value stays constant throughout the duration. A second problem with this “best practice” is that lots, if not all, non-trivial software development projects do not progress linearly with the passage of time. The green trace in the graph is an example of a non-linearly progressing project.
Since most managers are sequential, mechanistic, left-brain-trained thinkers, they falsely conclude that all projects progress linearly. These bozelteens also operate under the meta-assumption that no initial assumptions are violated during project execution (regardless of what items they initially deposited in their “risk register” at t=0). They mistakenly arrive at conclusions like: ” if it took you two weeks to get to 50% done, you will be expected to be done in two more weeks”. Bummer.
Even after trashing the “percent complete” earned-value-management method in the previous paragraphs, I think there is a chance to acquire a long term benefit by tracking progress this way. The benefit can accrue IF AND ONLY IF the method is not taken too seriously and it’s not used to impose undue stress upon the software creators and builders who are trying their best to balance time-cost and quality. Performing the “percent complete” method over a bunch of projects and averaging the results can yield decent, but never 100% accurate, metrics that can be used to more effectively estimate future project performance. What do you think?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 