Additive Vs Multiplicative

April 25, 2015 Leave a comment

You may not believe this, but overall, I like “agile” management and coding practices- where they fit. The most glaring shortcoming that I, and perhaps only I, perceive in the “agile” body of knowledge concerns the dearth of guidance for handling both the social and technical dependencies present in every software development endeavor. The larger the project (or whatever you #noprojects community members want to call it), the more tangled the inter-dependencies. There are, simultaneously: social couplings, technical couplings, and the nastiest type of coupling of all: socio-technical couplings.

The best analogy I can think of to express my thoughts on the agile dependencies black hole is the linear vs multiplicative complexity conundrum as expressed so elegantly by Bertrand Meyer in his book, “Agile!“. But instead of the family friendly linguini and lasagna images Mr. Meyer employs in his book, I, of course, choose to use imagery more in line with the blasphemous theme of this blog:

Additive Multiplicative

The complexity of the system is at least equal to the product of the problem and solution complexities. At worst, there are exponents associated with one or both multiplicands.

The Missing Role

April 22, 2015 Leave a comment

Quick, quick! What role is missing from the classic Scrum 1.0 team configuration of developers, product owner, and scrum master?

Missing AC

Ooh, ooh, I know what’s missing….

AC Present

Me thinks version 2.0 of the Scrum guide should include, and formally recognize, the glorious role of Agile Coach, no?

Since the Scrum Master has waaaaaaay to much to do already (running the daily 15 minute meeting and removing all those bazillions of impediments that the whiny developers willingly disclose every day), she can’t possibly fulfill the crucial role of agile coach. In addition to formal recognition, the Scrum Alliance should create a program where aspiring coaches can dole out some $$$$ to get certified.

Categories: management Tags: , ,

The Apples To Apples Fallacy

April 19, 2015 1 comment

To promote their infallible expertise, fathead consultants love to present apples-to-oranges comparisons as though they were apples-to-apples comparisons. One such prominent consultant (hint: a famous Forbes columnist) recently gushed over the success of music provider; contrasting its success to the team that built the buggy, slow, initial, version of the web site.

As is almost always the case, these clever dudes leave out the oft-hidden, process-independent, contextual, forces that relentlessly work against success:

Apples Oranges

To imply that the team would have been successful if they simply employed agile practices (like is to either be naive, disingenuous, or both.

Have you noticed that the press isn’t clamoring over the inadequacy of the site anymore? Obviously, the development team must have righted the ship by morphing into a high performing juggernaut under the tutelage of a cadre of agile process consultant(s) – regardless of whether they did or they didn’t.

One Word

April 16, 2015 Leave a comment

I’ve been waiting patiently (freakin’ impatiently?) for 10+ years for some word, any word, to dethrone “agile” as the most frequently seen word on book, video, and article titles in the software industry. Thanks to the highly esteemed Gartner consulting firm, perhaps we have a viable candidate:

Bimodal IT refers to having two modes of IT, each designed to develop and deliver information- and technology-intensive services in its own way. Mode 1 is traditional, emphasizing scalability, efficiency, safety and accuracy. Mode 2 is non-sequential, emphasizing agility and speed.” – Gartner IT Glossary

One Word



Personally, I like the word “Tradagile” better than “Bimodal“. It’s lighter, less stuffy.

I’m goin’ Bimodal! W00t!



Categories: technical Tags: ,

More Effective Than, But Not As Scalable As

April 13, 2015 Leave a comment

If you feel you have something to offer the world, the best way to expose and share your ideas/experiences/opinions/knowledge/wisdom is to release it from lock down in your mind and do the work necessary to get it into physical form. Write it down, or draw it up, or record it. Then propagate it out into the wild blue yonder through the greatest global communication system yet known to mankind: the internet.

You are not personally scalable, but because of the power of the internet, the artifacts you create are. Fuggedabout whether anybody will pay attention to what you create, manifest, and share. Birth it and give it the possibility to grow and prosper. Perhaps no one’s eyeballs or ears other than yours will ever come face to face with your creations, but your children will be patiently waiting for any and all adopters that happen to come along.

The agilista community is fond of trashing the “traditional” artifact-exchange method of communication and extolling the virtues of the effectiveness of close proximity, face-to-face, verbal exchange. Alistair Cockburn even has some study-backed curves that bolster the claim. BD00 fully agrees with the “effectiveness” argument, but just like the source code is not the whole truth, face-to-face communication is not the whole story. As noted in the previous paragraph, a personal conversation is not scalable.

Face to face, verbal communication may be more effective than artifact exchange, but it’s ephemeral, not archive-able, and not nearly as scalable. And no half-assed scribblings on napkins, envelopes, toilet paper, nor index cards solve those shortcomings on anything but trivial technical problems.

Comm Combos

Categories: technical Tags: ,

Join The Club

April 10, 2015 Leave a comment

My good Twitter buddy (and perhaps future book co-author), Mr. Jon Quigley, pointed me toward this great picture:

Debunker Club

Well… that’s not exactly the original picture. I took the liberty to paste Bulldozer00’s puss over the machine operator’s face. It simply felt like the right thing to do.

Good one Jon

That picture is much more apropos than you think. When I golf, I seem to always hit my balls into debunker!

Both Inane And Insane

April 7, 2015 6 comments

Let’s start this post off by setting some context. What I’m about to spout concerns the development of large, complex, software systems – not mobile apps or personal web sites. So, let’s rock!

The UML class diagram below depicts a taxonomy of methods for representing and communicating system requirements.

Reqs Taxonomy

On the left side of the diagram, we have the traditional methods: expressing requirements as system capabilities/functions/”shalls”. On the right side of the diagram, we have the relatively newer artifacts: use cases and user stories.

When recording requirements for a system you’re going to attempt to build, you can choose a combination of methods as you (or your process police) see fit. In the agile world, the preferred method (as evidenced by 100% of the literature) is to exclusively employ fine-grained user stories – classifying all the other, more abstract, overarching, methods as YAGNI or BRUF.

As the following enhanced diagram shows, whichever method you choose to predominantly start recording and communicating requirements to yourself and others, at least some of the artifacts will be inter-coupled. For example, if you choose to start specifying your system as a set of logically cohesive capabilities, then those capabilities will be coupled to some extent – regardless of whether you consciously try to discover and expose those dependencies or not. After all, an operational system is a collection of interacting parts – not a bag of independent parts.

Reqs Associations

Let’s further enhance our class diagram to progressively connect the levels of granularity as follows:

Reqs Granularity

If you start specifying your system as a set of coarse-grained, interacting capabilities, it may be difficult to translate those capabilities directly into code components, packages, and/or classes. Thus, you may want to close the requirements-to-code intellectual gap by thoughtfully decomposing each capability into a set of logically cohesive, but loosely coupled, functions. If that doesn’t bridge the gap to your liking, then you may choose to decompose each function further into a finer set of logically cohesive, but loosely coupled, “shall” statements. The tradeoff is time upfront for time out back:

  • Capabilities -> Source Code
  • Use Cases – > Source Code
  • Capabilities -> Functions -> Source Code
  • Use Case -> User Story -> Source Code
  • Capabilities -> Functions -> “Shalls” -> Source Code

Note that, taken literally, the last bullet implies that you don’t start writing ANY code until you’ve completed the full, two step, capabilities-to-“shalls” decomposition. Well, that’s a croc o’ crap. You can, and should, start writing code as soon as you understand a capability and/or function well enough so that you can confidently cut at least some skeletal code. Any process that prohibits writing a single line of code until all the i’s are dotted and all the t’s are crossed and five “approval” signatures are secured is, as everyone (not just the agile community) knows, both inane and insane.

No Source Code

Of course, simple projects don’t need no stinkin’ multi-step progression toward source code. They can bypass the Capability, Function, and Use Case levels of abstraction entirely and employ only fine grained “shalls” or User Stories as the method of specification.

One Step To Source Code

On the simplest of projects, you can even go directly from thoughts in your head to code:

Thoughts To Source Code

The purpose of this post is to assert that there is no one and only “right” path in moving from requirements to code. The “heaviness” of the path you decide to take should match the size, criticality, and complexity of the system you’ll be building. The more the mismatch, the more the waste of time and effort.


Get every new post delivered to your Inbox.

Join 481 other followers

%d bloggers like this: