Archive for april, 2013

Why Why is more important than What

torsdag, april 25th, 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.

Fragile agile

fredag, april 12th, 2013

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 Chinese Whisper strategy of getting answers: Developer asking Lead asking Project Manager asking Customers Project Manager asking feature requesting employee – and sending the answer back in the reverse direction fails on at least 3 accounts:

  1. It takes a long time to get an answer.
  2. 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?”
  3. 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.

Crossing a River

fredag, april 5th, 2013

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.”

Developers: “River? Wet? Boat? What are those things?”

Here the customers animosity towards the apparently completely stupid developers germinate.

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.

Initial design for crossing a river

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

Getting back to the first side again

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.

  1. 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.
  2. 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.
  3. 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.

Dragging the raft back to the beginning

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.

Crossing the river using a bridge

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.

Communication is difficult