Cause and Effect – Is It Really That Simple?

So this post has been on my mind for a while, but something happened at work today….

It would seem to me that it’s human nature to explain occurrences in the simplest manner possible, often in the form of linear “cause and effect” relationships.  You know, after you kick a ball, you realize the that the kick (cause) led the ball to move (effect) and so we are always looking for that “kick” that led something to happen.  For example, why did we find fewer defects this sprint?  Well, it’s because we went from a 3 week sprint to a 2 week sprint.

Is it really that simple?  I don’t think so.  I’m reminded of the phrase “correlation does not imply causation“.  In the domain of systems thinking (and every one responsible for the system should have a basic understanding of systems thinking), we realize that there are often many variables at play in the system.

Take the “fewer defects” example I mentioned earlier.  While it is true that the sprint duration was shortened, is it possible that other conditions changed as well?  Was the team now a bit more familiar with the work?  Was their less pressure because they committed to less in that particular sprint? Was this work less complex than the work before? Was technical expertise that had been missing before made available?  What about the conditions we are not aware of? I mean, we can’t be aware of everything can we?

The additional challenge we have is that we rarely have the luxury of repeating our experiments.  Every time we try something new, the conditions are different.  How many times do we get the opportunity to develop the same feature repeatedly just to capture how effective a change is?  I assume rarely, if ever.  Our laboratories don’t allow us to reset and run the exact same experiments over and over.

So where does this leave us? (Especially those of us who consider ourselves to be expert problem solvers!).  Does this imply that we cannot attribute cause to the things that happen around us?  I think we need to be a bit more respectful of the complexity of the problems we often face.  We need to understand that the underlying structures and conditions continually impact one another.  To use systems thinking parlance, structures reinforce and balance one another. There are often many factors at play and we should be careful latching onto a single one as THE (only) cause.  This complicates things for us in some regards, but put us in a position where we can actually dissolve problems.

It is rarely as simple as we often make it out to be.

PS.  Some links to my posts on systems thinking.

Have You Seen The System Lately

Appearances Can Be Deceiving

Advertisements

Build What Product Management Tells You To Build. Really?

A current (ok now its old) conversation on LinkedIn was the source for the first post of 2015.  (Yes I’ve been slacking a bit).

While on vacation, I spent some thinking about the fact that many organizations have “Product” groups that are separate (read completely different organizational structure) from the “Technology” group.  In fact, the only organizations where I have not seen this are the technology startups that I have been involved with.

I happened to bring up this point in the LinkedIn conversation only to be told the following:

Software Engineering – Build what product management tells you to build. Worry about predictability, quality, productivity and extensibility

Product Management – What should be build? What is the business case for it?

Really?  Is that really what Software Engineering is about?  Building what product management tells you to build? Could it be true?  We shouldn’t care about what we’re actually delivering?  I believe that such an opinion leaves a lot on the table and yet I’ve found it to be a common opinion in more than one organization.  Ever heard this: “don’t ask why, just do it”!  Unfortunately, statements like this reveal a complete lack in understanding of software engineering.

I won’t get into a discourse on software engineering as there are many institutions of repute (and Google) that can you help you out with that but I do want to point out an important aspect of software engineering that trained software engineers are very familiar with – requirements engineering.  Requirements engineering is all about determining what problem needs to be (dis)solved and what outcome is desired.  I realize that “requirements” is often a red word in Agile circles because of its literal application in many command and control type organizations.  I mean, who hasn’t heard the “go read the requirements” reply before?   But when you really think about it, you’ll see that Agile methods promote performing requirements engineering throughout the entire product development process.

So its my belief that software engineers need to understand “what should be built” and “the business case for it”. In fact, I’d suggest that it’s irresponsible not understanding why.  Sure, there may be another group (for example product) focused on idea generation and problem identification but instead of walls between product and development, let’s have a mesh with ideas and information flowing both ways.  It is product development afterall, isn’t it?  Software engineers ultimately need to understand the problem to be able to deliver the best solution (they are capable of delivering).

As I pointed out here:

To get the “best” solution, it seems to work best IME when those delivering the solution understand “why” and the outcome desired. I have been told many times in the past to do X because it was needed but if I had understood “why” and the outcome, would have done X+ or maybe Y. A key component of software engineering is requirements engineering. Requirements engineering asks us to understand the problem.

So friends, don’t let friends tell you that software engineering is just about building what we are told to build.  It’s more than that!