Archive
James YAGNI
In the software world, YAGNI is one of many cutely named heuristics from the agile community that stands for “don’t waste time/money putting that feature/functionality in the code base NOW cuz odds are that You Ain’t Gonna Need It!”. It’s good advice, but it’s often violated innocently, or when the programmer doesn’t agree with the YAGNI admonisher for legitimate or “political” reasons.
When a team finds out downstream and (more importantly) admits that there’s lots of stuff in the code base that can be removed because of YAGNI violations, there are two options to choose from:
- Spend the time/money and incur the risk of breakage by extricating and removing the YAGNI features
- Leave the unused code in there to save time/money and eschew making the code base slimmer and, thus, easier to maintain.
It’s not often perfectly clear what option should be taken, but BD00 speculates (he always speculates) that the second option is selected way more often than the first. What’s your opinion?
Cribs And Complaints
HCL Technologies CEO Vineet Nayar‘s “Employees First, Customers Second” is one of the most refreshing business books I’ve read in awhile. One of the bold measures the HCLT leadership team considered implementing to meet their goal of “increasing trust through transparency” was to put up an intranet web site called “U & I“. After weighing the pros and (considerable) cons, the HCLT leadership team decided to go for it. Sure enough, the naysayers (Vineet calls naysayers the “Yes, But“s) were right:
The U&I site was clogged with cribs and complaints, harangues and imprecations that the company was wrong about everything. The continents and questions came pouring in and would not stop. Most of what people said was true. Much of it hurt.
However, instead of placing draconian constraints on the type of inputs “allowed“, arbitrarily picking and choosing which questions to answer, or taking the site down, Vineet et al stuck with it and reaped the benefits of throwing themselves into the fire. Here’s one example of a tough question that triggered an insight in the leadership team:
“Why must we spend so much time doing tasks required by the enabling functions? Shouldn’t human resources be supporting me, so I can support customers better? They seem to have an inordinate amount of power, considering the value they add to the customer.”
This question suggested that organizational power should be proportionate to one’s ability to add value, rather than by one’s position on the pyramid. We found that the employees in the value zone were as accountable to finance, human resources, training and development, quality, administration, and other enabling functions as they were to their immediate managers. Although these functions were supposed to be supporting the employees in the value zone, the reality was sometimes different.
That question led to the formation of the Smart Service Desk (SSD), which helped the company improve its operations, morale, and financial performance.
So, how did the SSD work, you ask? It worked like this: SSD. Not like this:
Software Development Cost Saving Tip
It’s easier (read as lower cost) to retest existing code with an “updated” requirement that was wrong or impossible to satisfy than it is to change and retest code in order to match an “unquestioned” requirement.
Tools List
Out of the blue, I tried to list all of the tools that we are currently using on our distributed software system development project:
What do you think? Too many tools? Too few tools? Redundant tools? Missing tools? What tools do you use?
Ooh Ooh, Pick Me, Pick Me!
Quiz time! Who’s this kid….
In “You’re Not So Smart“, David McRaney describes how to overcome the debilitating scourge of “groupthink” in hierarchical organizations:
True groupthink depends on three conditions—a group of people who like one another, isolation, and a deadline for a crucial decision. It turns out, for any plan to work, every team needs at least one asshole who doesn’t give a shit if he or she gets fired or exiled or excommunicated. For a group to make good decisions, they must allow dissent and convince everyone they are free to speak their mind without risk of punishment.
Tome Peters said much the same thing is one of his bazillion books: “Put someone on your staff you don’t like“.
Semi-enlightened orgs hire consultants to fill the asshole role. Even though that’s a viable alternative, it’s only going half-way. The fact that an inside employee (or rotating employees) isn’t (aren’t) placed in the role says as much about the org’s culture as not “allowing” the role at all.
BD00 just had an epiphany! He’s concluded that he was put on this earth to fulfill “The Yes Asshole Rule“, and he’s willing to take job offers from far and near to fulfill his destiny. How many offers do you think will be forthcoming?
Related articles
- You Are Not So Smart: A Field Guide to the Psychology of Our Stupidity (brainpickings.org)
- Clanthink, Groupthink, Spreadthink (bulldozer00.com)
Behavior Compression
I’m gonna be an “absolutist” in today’s post. I’m gonna use the word “all” instead of “most“.
In all man-made orgs, as one ascends the hierarchy, the range of behaviors exhibited by members of a given level is compressed relative to the level below it:
So, why is this? It’s because org members unconsciously understand that as one’s stature rises via anointed promotion, an unseen pressure to project an image of infallibility increases. In order to be perceived as perfectly omniscient and omnipotent, behaviors that can be interpreted as less than impeccably pristine by the population below must be jettisoned. So, why is this? Well, it’s just… because BD00 said so.
The sad thing about this system behavior is that it takes a lot of energy and work to shed deviant behaviors and exude a false image of perfection. Instead of asking “Do you have what it takes to get to the top?“, maybe the question that should be asked is “Do you have what it doesn’t take to get to the top?“.
An Epoch Mistake
Let’s start this hypothetical story off with some framing assumptions:
Assume (for a mysterious historical reason nobody knows or cares to explore) that timestamps in a legacy system are always measured in “seconds relative to midnight” instead of “seconds relative to the unix epoch of 1/1/1970“.
Assume that the system computes many time differences at a six figure Hz rate during operation to fulfill it’s mission. Because “seconds relative to midnight” rolls over from 86399 to 0 every 24 hours, the time difference logic has to detect (via a disruptive “if” statement) and compensate for this rollover; lest its output is logically “wrong” once a day.
Assume that the “seconds relative to the unix epoch of 1/1/1970” library (e.g. Boost.Date_Time) satisfies the system’s dynamic range and precision requirements.
Assume that the design of a next generation system is underway and all the time fields in the messages exchanged between the system components are still mysteriously specified as “seconds since midnight” – even though it’s known that the added CPU cycles and annoyance of rollover checking could be avoided with a stroke of the pen.
Assume that the component developers, knowing that they can dispense with the silly rollover checking:
- convert each incoming time field into “seconds since the unix epoch“,
- use the converted values to perform their internal time difference computations without having to check/compensate for midnight rollover,
- convert back to “seconds since midnight” on output as required.
Assume that you know what the next two logical steps are: 1) change the specification of all the time fields in the messages exchanged between the system components from the midnight reference origin to the unix epoch origin, 2) remove the unessential input/output conversions:
Suffice it to say, in orgs where the culture forbids the admittance of mistakes (which implicates most orgs?) because the mistake-maker(s) may “look fallible“, next steps like this are rarely taken. That’s one of the reasons why old product warts are propagated forward and new warts are allowed to sprout up in next generation products.
Levels, Components, Relationships
In the Crosstalk Journal, Michael Tarullo has written a nice little article on documenting software architectures. Using the concept of abstract levels (a necessary, but not sufficient tool, for understanding complex systems) and one UML component diagram per level, he presents a lightweight process for capturing big software system architecture decisions out of the ether.
Levels Of Abstraction
Mr. Tarullo’s 5 levels of abstraction are shown below (minor nit: BD00 would have flipped the figure upside down and shown the most abstract level (“Global“) at the top.
Components Within A Level
Since “architecture” focuses on the components of a system and the relationships between them, Michael defines the components of concern within each of his levels as:
(minor nit: because the word “system” is too generic and overused, BD00 would have chosen something like “function” or “service” for the third level instead).
Relationships
Within a given level of abstraction, Mr. Tarullo uses a UML component diagram with ports and ball/socket pairs to model connections, interfaces (provides/requires), and to bind the components together. He also maintains vertical system integrity by connecting adjacent levels together via ports/balls/sockets.
The three UML component diagrams below, one for each of the top, err bottom, three levels of abstraction in his taxonomy, nicely illustrate his lightweight levels plus UML component diagram approach to software architecture capture.
But what about the next 2 levels in the 5 level hierarchy: the Application/Library and Classes levels of the architecture? Mr. Tarullo doesn’t provide documentation examples for those, but it follows that UML class and sequence diagrams can be used for the Application/Library level, while activity diagrams and state machine diagrams can be good choices for the atomic class level.
Providing and vigilantly maintaining a minimal, lightweight stack of UML “blueprint” diagrams like these (supplemented by minimal “hole-filling” text) seems like a lower cost and more effective way to maintain system integrity, visibility, and exposure to critical scrutiny than generating a boatload of DOD template mandated write-once-read-never text documents, no?
Alas, if:
- you and your borg don’t know or care to know UML,
- you and your borg don’t understand or care to understand how to apply the complexity and ambiguity busting concepts of “layering and balancing“,
- your “official” borg process requires the generation of write-once-read-never, War And Peace sized textbook monstrosities,
then you, your product, your customers, and your borg are hosed and destined for an expensive, conflict filled future. (D’oh! I hate when that happens.)
The D’oh Threshold
The figure below introduces the concept of the “D’oh Threshold“. Every institution has their own purely subjective “D’oh Threshold“. It is arbitrarily set by whoever is in charge.
The more bureaucratic or dictatorial the org, the more the threshold shifts to the left (the less the positive safety margin and the more the negative safety margin). Since bureaucrats and dictators care more about conformance to their arbitrary and personally concocted rules than contribution to the “whole“, the “D’oh Threshold” wobbles all over the place. Its setting can vary month to month, day to day, minute to minute, group to group, individual to individual – depending on the emotional state and perceptions of those who run the circus.
When humans are involved in organized group efforts, there is no escape from subjectivity. But in high performing orgs, the “D’oh Threshold” set point is relatively stationary, far to the right, and everybody knows where they stand.
B and S == BS
About a year ago, after a recommendation from management guru Tom Peters, I read Sidney Dekker’s “Just Culture“. I mention this because Nancy Leveson dedicates a chapter to the concept of a “just culture” in her upcoming book “Engineering A Safer World“.
The figure below shows a simple view of the elements and relationships in an example 4 level “safety control structure“. In unjust cultures, when a costly accident occurs, the actions of the low elements on the totem pole, the operator(s) and the physical system, are analyzed to death and the “causes” of the accident are determined.
After the accident investigation is “done“, the following sequence of actions usually occurs:
- Blame and Shame (BS!) are showered upon the operator(s).
- Recommendations for “change” are made to operator training, operational procedures, and the physical system design.
- Business goes back to usual
- Rinse and repeat
Note that the level 2 and level 3 elements usually go uninvestigated – even though they are integral, influential forces that affect system operation. So, why do you think that is? Could it be that when an accident occurs, the level 2 and/or level 3 participants have the power to, and do, assume the role of investigator? Could it be that the level 2 and/or level 3 participants, when they don’t/can’t assume the role of investigator, become the “sugar daddies” to a hired band of independent, external investigators?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 