Archive
Gatling Gun
Starting from the bottom and progressing upward, check out this rat-tat-tat gatling gun salvo of irrationality emitted by BD00 recently, uh yesterday, on Twitter:
Sheesh, tis’ a good thing nobody pays attention to what BD00 sez; especially the profit-seeking proponents of the “best practice” du jour.
From #NoProjects To #NoOrganization
Let’s jump on the twitter #NoProjects bandwagon and see where it takes our organization….
Many thanks to Gene Hughson for the #NoCustomers idea that fueled the writing of this post.
Challenging the Priesthood
It seems to have taken awhile, but people are finally speaking out strongly against the papal infallibility of the TDD high priesthood. Michał Bartyzel, Andrew Binstock, and Jim Coplien (who actually has been speaking out against it for years) are a few of these blasphemous heretics.
Any of the “driven” techniques can work, but to insinuate that they are the “only way(s)” to build superior products is arrogant, hubristic, and plain stupid. In mentally challenging, knowledge-intensive work, people have, and always will have, different ways of creating beautiful products.
When I speak with adherents of test-driven development (TDD) in particular, there is a seeming non-comprehension that truly excellent, reliable code was ever developed prior to the advent of this one practice. I sense their view that the long history of code that put man on the moon, ran phone switches, airline reservation systems, and electric grids was all the result of luck or unique talents, rather than a function of careful discipline and development rigor. – Andrew Binstock
“…these promises were not supported by unambiguous and verifiable data in early years of TDD. The enthusiastic reaction to TDD came first and then some (selective?) measurements were made to verify its promises. – Michał Bartyzel
“If you find your testers (or yourself) splitting up functions to support the testing process, you’re destroying your system architecture and code comprehension along with it. Test at a coarser level of granularity.” – Jim Coplien
Personally, I start sketching out quite a bit of a design upfront (OMG!!!!!) in “bent” UML (OMG, OMG!!!!!) prior to writing a single line of code. I then start writing the code and I subsequently write/run some selective unit tests on that code. In summary, I dynamically build/test the code base toward the coarse, “upfront” design as I go. Of course, according to the high priests of TDD, I’m unprofessional and I obviously produce inferior designs and bug-ridden, unmaintainable code. Gosh, it sux to be me.
For more details on how I develop software, check out this four year old post: PAYGO II. And no, I’m not promoting it as better than your personal process or, gasp, the unassailable holy grail of software development… TDD! No books, magazine articles, conference talks, or two-day certification courses are planned. It’s simply better for me, and perhaps only me.
A Skeptical “No”
Just about every agile video, book, and article I’ve ever consumed assumes some variant of the underlying team model shown below. The product these types of teams build is comprised of custom software running on off-the-shelf server hardware. Even though it’s not shown, they also assume a client-server structure, request-response protocol, database-centric system.
The team model for the types of systems I work on is given below. They are distributed real-time event systems comprised of embedded, heterogeneous, peer processors glued together via a pub-sub protocol. By necessity, specialized, multi-disciplinary teams are required to develop this category of systems. Also, by necessity, the content of the sprint backlog is more complex and intricately subtler than the typical agile IT product backlog of “features” and “user stories“.
When I watch/read/listen to smug agile process experts and coaches expound the virtues of their favorite methodology using narrow, anecdotal, personal stories from the database-centric IT world, I continuously ask myself “can this apply to the type of products I help build?“. Often, the answer is a skeptical “no“. Not always, but often.
Signals, Sensations, Perceptions, Commands, Actions!
In humans, the sensors are the eyes, ears, nose, skin, and taste buds. The processor/memory/controller combo is the brain. The actuators are the muscles. Although not shown on the diagram, “commands” are also issued to the sensors. All inter-part communications “In Here” are manifested via neural currents.
Of course, this crap is all made up. It’s simply a cacophonous dump of what was in my tortured mind at the moment.
Four Days And $2000
I get e-mails like this all the time:
In four fun-filled days, and for a measly $2000, you too can become a full fledged, CERTIFIED Scrum Master AND Scrum Product Owner. That’s all it takes to catapult you to the top of the software development world. W00t!
Why spend weeks or months struggling to learn a new language, API, framework, technology, or tool when you can nail this trifecta: leapfrog over your programmer peers, break into the highly coveted guild of management, and prefix a big fat “C” to your title? Quick, quick, jump on the bandwagon before it’s too late. Don’t get left behind!
The Vertical And Horizontal Dimensions
“A person is smart, people are stupid.” – Agent K (Men in Black)
I’m forever fascinated by how large groups of bright and well-meaning individuals often behave so dysfunctionally as a “whole“. How can that be? It’s because the individual “parts” of an organization don’t determine the behavior of the whole. It’s the part-to-part interactions enabled by, and (more importantly) disabled by, the structure of an organization that determines system behavior. By default, hierarchically structured orgs suppress collaborative communications in the horizontal dimension while catalyzing top down command and control communications in the vertical dimension.
In the vertical dimension, the fact that bosses get to unconditionally decide on how to divvy out tasks and rewards to their “subordinates” below ensures that the dweebs in the lower tiers will do whatever the boss wants them to do with little, if any, frictional blowback. In the horizontal dimension, crucial information can be withheld and collaborative communication suppressed because of peer-to-peer competition for the limited number of coveted slots available upstairs in the ever narrowing pyramid.
Thanks, But No Thanks
When it comes down to it, the primary function of management is to allocate finite org resources to efforts that will subsequently increase revenues and/or decrease costs. By resources, I mean people and money (for salaries, materials, tools, training, etc) and time.
Since projects vary wildly in complexity/importance/size, required skill-sets, and they (should) have end points, correctly allocating resources to, and amongst, projects is a huge challenge. Both over and under allocation of resources can threaten the financial viability of the org and, thus, everyone within it. Under-allocation can lead to a stagnant product/service portfolio and over-allocation can lead to an expensive product/service portfolio. Note that either under or over allocation can produce individual project failures.
To correctly allocate resources to projects, especially the “human resources“, some things must be semi-known about them. Besides desired outcomes and required execution skills, project parameters like size and/or complexity should be estimated to some level of granularity. That’s why, for the most part, I think the #noestimates and #noprojects people are full of bullocks. Like agile coaches, they mean well and their Utopian ideas sound enticing. Thanks, but no thanks.
Result-Focused, Or State-Focused?
As I continue to explore/evaluate the relevance of the SEMAT Kernel to the future of software engineering, I’m finding that I’m liking it less and less. (For a quick introduction to the SEMAT Kernel, please go read this post, “Revolution, Or Malarkey?“, and then return back here if you’re still interested in what BD00 has to say.)
One of the principal creators of the SEMAT movement, Ivar Jacobson, subjectively asserts that:
“…using the SEMAT kernel to drive team behavior makes the team result focused instead of document driven or activity centric.” – Ivar Jacobson
Using the patented BD00 method of distorted analysis, let’s explore this bold proclamation further.
In the current definition of the SEMAT kernel, each of the seven top-level alphas in the SEMAT Kernel has a state whose value at any given moment is determined by the sub-states of a set of criteria items in a checklist. In addition, each sub-alpha itself has a checklist-determined state.
“Each state has a checklist that specifies the criteria needed to reach the state. It is these states that make the kernel actionable and enable it to guide the behavior of software development teams.” – “The Essence Of Software Engineering“
So, let’s look at some numbers for a small, hypothetical, SEMAT-based project. Assume the following definition of our project:
- 7 Alphas
- Each alpha has 3 Sub-Alphas
- Each checklist has 5 Items
With these metrics characterizing our project, we need to continuously track/update:
- 7 alpha states
- 7 * 3 = 21 Sub-alpha states
- 7 * 3 * 5 = 105 checklist item states
Man, that’s a lotto states for our relatively small, 21 sub-alpha project, no? It seems like the SEMAT team could be spending a lot of time in a state of confusion updating the checklist document(s) that dynamically track the state values. Thus,
“…using the SEMAT kernel to drive team behavior makes the team state focused instead of result focused.” – BD00
Unless result == state, Ivar may be mistaken.
The Last Retrospective
In an ongoing agile endeavor, the practice for eliciting and applying freshly learned knowledge going forward is the periodic “retrospective” (aka periodic post-mortem to the “traditional” old fogeys). Theoretically, retrospectives are temporary way points where individuals: stop, step back, cerebrally inspect what they’ve accomplished and how they’ve accomplished it, share their learning experiences, suggest new process/product improvements, and evaluate previously implemented improvements.
As the figure below depicts, the fraction of newly acquired knowledge applied going forward is a function of group culture. In macho, command and control hierarchies like culture B, the application of lessons learned is suppressed relative to more flexible cultures like A due to the hierarchical importance of opinions.
Regardless of culture type, during schedule-challenged projects with a fixed, do-or-don’t-get-paid deadline (yes, those projects do indeed still exist), this may happen:
When the elites upstairs magically determine that a panic point has appeared (sometimes seemingly out of nowhere): retrospectives get jettisoned, the daily standup morphs into the daily inquisition, corner-cutting “practices” become best practices, and the application of newly acquired knowledge stops cold. Humans being humans, learning still naturally occurs and new knowledge is accrued. However, it is not likely the type of knowledge that will help on future projects.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 