Archive for april, 2013

When trying to understand a new concept the important thing to understand is not what the concept is, but why it exists. Thereby getting to the essence of the thing in itself.

This is probably why the 5 Whys is an important tool for root cause analysis and incident investigation albeit it doesn’t fit all purposes. But if it is a sequence of burrowing down to the core of an issue, then it is probably one of the better methods of examining unknown processes.

As in the story about the newlywed couple. One evening, the husband noticed than when his wife began to prepare a roast beef for dinner she cut off both ends of the meat before placing it in the roasting pan. He asked her why she did that. “I don’t know,” she said. “That’s the way my mother always did it.” The next time they went to the home of the wife’s parents, he told his mother-in-law about the roast beef and asked her why she cut off the ends of the meat. “Well, that’s the way my mother always did it” was her reply.

He decided that he had to get to the bottom of this mystery. So when he went with his wife to visit her grandparents, he talked to his grandmother-in-law. He said, “Your daughter and granddaughter both cut off the ends of the meat when they fix roast beef and they say, ‘That’s the way my mother always did it.’ How about you? Why do you cut the meat in this way?” Without hesitation the grandmother replied, “Oh, that’s because my roaster was too small and the only way I could get the meat to fit in it was to cut off the ends.” (I’ve heard it before, but the only text I could find was from The Everlasting Tradition on Google Books)

If you don’t know the root cause you may end up doing unnecessary work at best, but most likely limiting, and in worst case counterproductive and wasteful work.

Don’t ask people what they want or do, but why they want or do it. It’s just as Henry Ford said: “If I had asked people what they wanted, they would have said faster horses.” They would have asked for faster horses, because horses was something they knew about, and faster or stronger would make transportation better.

In the same vein, it is just as important to learn the reason behind, when embarking on a new project with unknown entities. In particular when starting on new software project, and especially for project managers on both sides of the table. You need to know what to deliver to be able to deliver it in the first place, you can’t tell a developer what you need, if you don’t know what it is, and you cannot accept or test the thing if you don’t know how it should behave.

If a feature has to be cut it is paramount that you can argue why that doesn’t impair the end product too much.

If a feature can be implemented in multiple ways, then the simpler should be opted for. If you don’t know the essence of the feature, you don’t know the feasible ways, and you may choose a too simple solution - these are the solutions which seems to almost work.

Going back to Ford’s quote, it is important that you know what to abstract and how to abstract it, e.g. “faster horses” to “faster means of transportation” and not “faster animals” - that would lead to trying to hitch a cheetah or a bear to a buggy.

As the character Forrest Gump is accustomed to say: “Stupid is as stupid does.” - if we don’t know better, then we do stupid things. If you know why you do things, you may have a chance not to act stupid.

When knowing why as opposed to just what, then you are closer to the Ha step of Shu Ha Ri, because you already know the mechanics, and you are armed with the path. You may not know which quantum leaps you have to make to diverge to another stable level, but at least you know whether a path is perpendicular to the current flow or perhaps an ever so slightly diverging path.

On a much more pragmatic level, it is better to know why a certain color or method is chosen, especially when the time to change it comes around. Which is why the “why” is a much better comment for source code than the “what” - which should be evident by the code itself. And if you have complete memory of the history of changes, you can check if we’re going in circles.

Some people don’t “get” agile - then again perhaps it’s just me who doesn’t get it. At least here’s my take/rant on the issue:

Software development is an evolution of the software, thus you’re not really ever done - the product may be fine for now, but will later have to evolve to keep up with customer requests, e.g. new rules, new layout, new features. A product is not a boxed-in set of features for a given amount of time and money. It’s a concept with an evolving portfolio of features, and an evolving wish list.

Sometimes you have to provide a solution to a customer in order for them to better understand what they really want.

A project cannot be a boxed development of features for a set amount of time and money, as time goes by and new and possibly more interesting features evolve for the customer at hand. Well - perhaps a project could be to “change fonts” or “change colors” - but there’s no project which requires more than one task, well perhaps “change fonts and colors”. A Project becomes a single iteration or sprint.

There should be no need to argue whether a request should be in a project or not, except for technical reasons. If the request is there, then at some point in time the request will be fulfilled. If it’s of high value to the customer, then it’ll most likely be done earlier.

Estimates are wrong - by at least a factor of 2: I’m not saying we should work slower, I’m saying that we should work towards improving our legacy systems as well. A sprint is not called a sprint because you blindly go along full speed without concern for what you’re doing - that would be a demolition derby.

A sprint is a just a short distance with the goal easily visibly, and hopefully easily attainable. You go along a sprint as fast as you can while still maintaining the highest level of quality, not building any technical debt, thus highest sustainable pace. You know, that when the sprint is over, there’ll be another one. Thus there will be no time for rest, no time for clearing technical debt.

If a better way during a sprint is to refactor code to get a better structure, then this should be taken into account when the estimates are done - and the refactoring should be done. If not, then the code becomes more rigid - quite the opposite of agile and software.

Sometimes requests are disrupting the flow of the current code, then it is the developers responsibility to spot this and remedy the problem, otherwise the code ends up as an exquisite corpse. Sometimes Project managers think they need to shield developers from information thereby making the developers create exquisite corpses - don’t do that. Be on the same journey, work towards the same goal.

Agile done the wrong way: The team should work as a team. That is on the same features in the sprints backlog - if they’re not working on the same features, then collocation is pointless and so is team size limits. The customer should be passionate about the product, and be involved in the development. This is why the customer should not be represented by a random project manager. The developers should be passionate about the product, which is why decisions shouldn’t be made by random project managers.

The question and answer may get corrupted along the way. Especially if
any of the communication bridges are verbal. “You tell me they said
‘red’ but the task says ‘green’ - which is it? Or better yet: Can I get
a hex-color for that?”

Information may be lost or withheld along the way - deemed “not
important” or “not relevant” by any party.

This would be alleviated by developer asking (onsite) customer directly - if the developer could show the customer representative then a lot of other questions are answered so much faster and so much better saving a lot of redoing a feature.

You may think I don’t like Project Managers - well, if there’s no project, then there’s no point in having a manager for it. My take is that the Project Managers, Project Secretaries - or SCRUM Masters - should remove obstacles in the software development process and make sure that the project/sprint gets finished on time. They should not create problems nor prolong the sprint by adding features. There’s probably still need for time/feature accounting thus Iâ€™m not entirely against them - they should just not be in the way of progress, and should keep their micromanagement tendencies and software estimates far away from the development and developers. This, of course, requires developers to prove that they are responsible professionals delivering estimates and solutions consistently and on time.

Introduction

For those who are not in the software development business, I have triedÂ to create a parallel to an engineering task simple enough that most canÂ see what some of the issues are.

In this story we have a customer who wants to cross a river. He has seenÂ other people using boats to cross the river, but he doesn’t know anythingÂ about boats, he simply wants to be able to carry some merchandise from oneÂ shore to the other without getting it wet.

The software developers he hires have no business insights into the riverÂ crossing domain, but they do know that they can solve almost everyÂ problem.

Customer: “I want to cross the river without getting wet. I’ve seenÂ boats, but I can’t be bothered with the hassle of sailing one.”

Customer: “Don’t you know anything? The river is this flowing barrier.Â Boats float somehow and can be rowed across using muscle strength. But asÂ I said - I can’t be bothered with the hassle of sailing one.”

The developers taking note of the animosity don’t want to ask moreÂ questions trying to keep up appearances they conclude that they haveÂ sufficient information to start work and their own preliminaryÂ investigations on the subject.

Version 1.0

The developers set up an investigation on the objects mentioned. They getÂ that wood will float, and that apparently the river flows carrying theÂ wood downstream, which means that there is a possibility of some kind ofÂ raft can be carried across using this flow.

Another team tests the best launch site of the raft within the river toÂ the highest probability that it can land on the other side. They concludeÂ that starting close to the middle of the stream has a high probability ofÂ keeping the raft in the middle of the stream.

The developers come up with the following solutions covering all of the customers needs.

Proudly they show this to the customer, who in turn is thrilled to see itÂ in action. Though after getting to the other side he’s a bit stomped, andÂ asks the developers: “How do I get back then?”

The developers are fluttered. There is no mention of getting back fromÂ the other side, just a simple crossing.

The customer argues: “But that goes without saying. If I take myÂ merchandise from one side to the other I have to get back to resupply.”

Version 2.0

One developer suggests reversing the flow of the river. Naturally youÂ can’t do that thus he shows the lack of domain knowledge of rivers. But ifÂ it was possible to reverse the flow, then this would be a viable idea.

Whether the customer is informed of this idea or the developers try itÂ out for themselves, the result is greater animosity or wasted effort.

While the reverse solution seemed stupid, another developer reflect uponÂ the concept and the original idea, then gets his Eureka moment: We’ll justÂ add another dock on the first side further downstream - it’ll be the sameÂ as going from the first to the second side, just reversed.

The developers proudly present version 2.0

The now wary customer is thrilled that he can get back home, but nowÂ there’s an issue with reuse. “I want to be able to bring another shipment,Â but now the raft will just continue down the river.”

Version 3.0, 3.1, …

After mentioning that this was another thing not in the specification,Â the developers come up with several suggestions for solutions.

Repeat the success. Build more docks alternating sides. While thisÂ works for a few round-trips the customer finds that the way back homeÂ becomes excruciatingly long. Or they end up wherever the river flows to.

Skip the surplus docks, just keep the three from the second solution.Â Build new rafts at the start of every round-trip. While this works, andÂ the way back home is constant, the price for a raft: Materials and timeÂ spent. Soon becomes unfeasible.

Drag the raft from the last dock to the first. This can be done eitherÂ by the customer or some other power source, e.g. a horse.

While the customer now has a reusable way of crossing the river, thereÂ are better alternatives.

Some of the downsides to this solution:

Cost - the developers worked on several solutions. If they got toÂ version 3 above before multiple docks or rafts, they would at least haveÂ saved a lot of time and resources.

Time - while time is a cost, then time spent crossing the river inÂ this fashion seems wasteful

Parallelism - everyone crossing must depart at the same time or wait aÂ full revolution of the raft. Naturally more rafts can be issued, butÂ then there’s another problem of cluttering up the river.

The “correct” solution would have been to build a bridge crossing theÂ river.

While this should seem like a no-brainer to us, then there was a firstÂ bridge at some point.

The “funny” part is that this could be achieved at 2/3 the cost of theÂ final solution as the docks are going halfway into the river.

Another “funny” part is that most likely then the developers analyzingÂ the flow and suggesting the launch site to be he middle of the river,Â would probably have build a tiny bridge crossing the entire river fromÂ which they could launch probes. Quite possibly they would have buildÂ another bridge to measure where the probes went.

The bridge does have a drawback, which the dock solution doesn’t have:Â Tall things can pass through the river without tearing apart the solution.

To keep with this parallel. A new developer company - a set of bridgeÂ builders - shows up telling the customer that there is a better way to doÂ things, namely a bridge. But the customer is quite happy with hisÂ solution. It might not be the best, but it works, and the cost/benefit ofÂ the current solution is still in the red.

Summary

So - what to take away from this story? First off, this is an extremeÂ simplification of the issues in software development. It would probablyÂ have been more correct if the customer had been blind, as most softwareÂ customers don’t understand the code making up the solution. But then someÂ of the developers would have had to be blind, deaf, mute, and forgetful.

The customer is most likely the best candidate for an expert in theÂ domain for which the developers are building a solution. On the otherÂ hand, then developers should be experts in the solution cracking andÂ development domains.

Animosity and trying to keep up appearances are detrimental to theÂ solution at hand. It is quite easy for the customer to think that theÂ developers are stupid when they don’t know what he is trying toÂ communicate. On the other hand, then the developers quite easily findÂ themselves on a death-march project where it seems the customer keepsÂ wanting more features for free.

The unsaid, not written down expected parts of solutions are always thereÂ - they may be given for those knowledgeable in the domain, but probablyÂ aren’t for others.

Anchoring terms in the conscience of anyone is dangerous if you wantÂ something completely different.