Archive
Process Nazis
Unlike most enterprise software development orgs where “quality assurance” is equated to testing, government contractors usually have both a quality assurance group and a test engineering group. Why is that? It’s because big and bloated government customers “expect” all of its contractors to have one. It’s the way it is, and it’s the way it’s always been.
It doesn’t matter if members of the QA group never specified, designed, or wrote a line of software in their life, these checklist process nazis walk around wielding the process compliance axe like they are the kings of the land: “Did you fill out this unit test form?” “Do you have a project plan written according to our template?“, “Did you write a software development plan for us to approve?“, “Did you submit this review form?“, “Did you submit this software version definition form?“, “Do you have a test readiness form?“, “If you don’t do this, we’ll tell on you and you’ll get punished“. Yada, yada, yada. It’s one interruption, roadblock, and distraction after another. On one side, you’ve got these obstacle inserters, and on the other side you’ve got nervous, time-obsessed managers looking over your shoulder. WTF?
Since following a mechanistic process supposedly “proven to deliver results” doesn’t guarantee anything but a consumption of time, I don’t care much about formal processes. I care about getting the right information to the right people at the right time. By “right“, I mean accurate, unambiguous, complete, and most importantly – frreakin’ useful. For system engineers, the right information is requirements, for software architects it’s blueprints, for programmers it’s designs and source code, for testers it’s developer tested software. How about you, what do you care about?
Shallmeisters, Get Over It.
If you pick up any reference article or book on requirements engineering, I think you’ll find that most “experts” in the field don’t obsess over “shalls”. They know that there’s much more to communicating requirements than writing down tidy, useless, fragmented, one line “shall” statements. If you don’t believe me, then come out of your warm little cocoon and explore for yourself. Here are just a few references:
http://www.amazon.com/Process-System-Architecture-Requirements-Engineering/dp/0932633412/ref=sr_1_3?ie=UTF8&s=books&qid=1257672507&sr=1-3
With the growing complexity of software-intensive systems that need to be developed for an org to remain sustainable and relevant, the so-called venerable “shall” is becoming more and more dinosaurish. Obviously, there will always be a place for “shalls” in the development process, but only at the most superficial and highest level of “requirements specification”; which is virtually useless to the hardware, software, network, and test engineers who have to build the system (while you watch from the sidelines and “wait” until the wrong monstrosity gets built so you can look good criticizing it for being wrong).
So, what are some alternatives to pulling useless one dimensional “shalls” out of your arse? How about mixing and matching some communication tools from this diversified, two dimensional menu:
- UML Class diagrams
- UML Use Case diagrams
- UML Deployment diagrams
- UML Activity diagrams
- UML State Machine diagrams
- UML Sequence diagrams
- Use Case Descriptions
- User Stories
- IDEF0 diagrams
- Data Flow Diagrams
- Control Flow Diagrams
- Entity-Relationship diagrams
- SysML Block Definition diagrams
- SysML Internal Block Definition diagrams
- SysML Requirements diagrams
- SysML Parametric diagrams
Get over it, add a second dimension to your view, move into this century, and learn something new. If not for your company, then for yourself. As the saying goes, “what worked well in the past might not work well in the future”.
I’m Finished
I just finished (100% of course <-LOL!) my latest software development project. The purpose of this post is to describe what I had to do, what outputs I produced during the effort, and to obtain your feedback – good or bad.
The figure below shows a simple high level design view of an existing real-time, software-intensive, revenue generating product that is comprised of hundreds of thousands of lines of source code. Due to evolving customer requirements, a major redesign and enhancement of the application layer functionality that resides in the Channel 3 Target Extractor is required.
The figure below shows the high level static structure of the “Enhanced Channel 3 Target Extractor” test harness that was designed and developed to test and verify that the enhanced channel 3 target extractor works correctly. Note that the number of high level conceptual test infrastructure classes is 4 compared to the lone, single product class whose functionality will be migrated into the product code base.
The figure below shows a post-project summary in terms of: the development process I used, the process reviews I held, the metrics I collected, and the output artifacts that I produced. Summarizing my project performance via the often used, simple-minded metric that old school managers love to use; lines of code per day, yields the paltry number of 22.
Since my average “velocity” was a measly 22 lines of code per day, do you think I underperformed on this project? What should that number be? Do you summarize your software development projects similar to this? Do you just produce source code and unit tests as your tangible output? Do you have any idea what your performance was on the last project you completed? What do you think I did wrong? Should I have just produced source code as my output and none of the other 6 “document” outputs? Should I have skipped steps 1 through 4 in my development process because they are non-agile “documentation” steps? Do you think I followed a pure waterfall process? What say you?
Guilt And Coercion
In a classic CCH (Command and Control Hierarchy), the only two tools of motivation known to BMs (Bozo Managers) for getting people to sign up for no-win projects are Guilt and Coercion. Bad CCH BMs use both, and really bad BMs with a sweatshop mentality use coercion exclusively. Attempts to instill guilt are often prefaced with “Don’t you wannabe a team player?” or “It’s very important for the company”. A classic coercive one-liner is “Do this project or else!”
So, why don’t many smart DICs (Dweebs In the Cellar) step up and volunteer to lead tough projects? One reason is because smart DICs know that the toxic, fragmented, and stifling environment (created and nurtured by the very same BMs who are coercing and inflicting guilt) guarantees failure. Another reason is because textbook CCHs are bureaucracies and not meritocracies – regardless of what they espouse. Thus, all work is treated the same and everyone gets the same 3% raise no matter how hard they work or how much they neglect their own lives to “get the job done” . Can you think of other reasons?
Orchestrated Reviews
If you think your design is perfect, it means you haven’t shown it to anyone yet – Harry Hillaker
Open, frequent, and well-engineered reviews and demonstrations are great ways to uncover and fix mistakes and errors before they grow into downstream money and time sucking abominations. In spite of this, some project cultures innocently but surely thwart effective reviews.
Out of fear of criticism, designers in dysfunctional cultures take precautions against “looking bad“. Camouflage is generated in the form of too much or too little detail. Subject matter experts are left off the list of reviewers in order to uphold a false image of infallibility.
Another survival tactic is to pre-load the reviewer list with friends and cream puffs who won’t point out errors and ambiguities for fear of losing their status as nice people and good team players. In really fearful cultures, tough reviewers who consistently point out nasty and potential budget-busting errors are tarred and feathered so that they never provide substantive input again. In the worst cases, reviews and demonstrations aren’t even performed at all. Bummer.
Man, I Love This Guy
I’m not gay (not that there’s anything wrong with that), but I love Scott Berkun. I’ve spoken about him before, and it’s time to speak about him again. Scott’s got a new book out titled “Confessions Of A Public Speaker“. Like all of his other work, it’s a funny and insightful page turner.
It’s incredibly hard to be original, but everyone has the innate capability to be authentic. Scott is authentic. Check out this quote from the new book:
“In the interest of transparency and satisfying your curiosity, I average 25–30 lectures a year. Sometimes I’m paid as much as $8,000, depending on the situation. Maybe one-third are paid only in travel expenses or small fees, since they’re selfpromotional or for causes I’d like to help. Roughly 40% of my income is from book royalties and the rest from speaking and workshop fees. So far, I average around $100,000 a year, less than I made at Microsoft. However, I work fewer hours, am free from the 9 to 5 life, and have complete independence, which is worth infinitely more. I limit travel to once or twice a month, which means I turn away many gigs; I’d prefer to have more time than money, since you can never earn more time.”
Do you think many people have the cajones to expose that amount of detail about how much money they make? I don’t. Maybe I don’t because I feel guilty that I’m an overpaid and underperforming slacker. Scott follows up that trench coat opener with:
“I also think it would be good if salaries were made public, which is why I offered my fees and income. If more people did this, the overpaid and underpaid would be visible and more likely to be corrected. Or, total anarchy would ensue and civilization would end. Either way, it would be fun to watch.”
LOL! I love that idea and I would sign up to it any day. Then I, and everyone else, especially the corpocrats that run the show, would have a reference point of relativity for determining whether or not they’re overpaid.
There’s at least one company that I know of that operates this way – Semco. I know this because CEO Ricardo Semler said so in his book “Maverick“. How about you and your company? Would you try it out? Why not? If the result turned out to be FUBAR, you could always revert back to the same-old same-old and do what everybody else in the moo-herd does.
Few people are capable of expressing with equanimity opinions which differ from the prejudices of their social environment. Most people are even incapable of forming such opinions. – Albert Einstein
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?
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.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 