24 Jun08

Topics:Arb Thoughts Funnies Jobs 

On numerous occasions I’ve seen companies go through the dilemma of having the wrong people making the wrong decisions at the wrong time. The same is true in personal relationships.

 

In one of my more recent encounters, I’ve had the opportunity of having a software developer telling the business analyst what the client’s requirements are without having investigated this. At this point we stop. “What?!” Yes you heard me. Requirements are being thumb sucked and forced on the BA as “needed”. This is BS. If I was not as strong of character I’d have said “erm… ok...” and let the bastard get away with this. I however, am made of stronger stuff.

 

The unfortunate part for the Business Analyst is that he is facing the client. So presenting this “much needed requirement” to the client, you’ll oft time face the reaction of “WTF is this? I don’t need it! Get rid of it…” while the analyst will sit there with a mouth full of teeth trying to figure out the good reason why it was “required”. The analyst now has to run around to all parties and sort the mess out. All because they weren’t able to say no.

 

I'm not sure where the following excerpt came from originally, or if the stories are true. But the fundamentals of this kind of thinking is vital. This is what makes a good Business Analyst, or anyone who is trying to solve problems.

 

Difference between Focusing on Problems and Focusing on Solutions

 

Case 1

 

When NASA began the launch of astronauts into space, they found out that the pens wouldn't work at zero gravity (ink won't flow down to the writing surface). To solve this problem, it took them one decade and $12 million. They developed a pen that worked at zero gravity, upside down, underwater, in practically any surface including crystal and in a temperature range from below freezing to over 300 degrees C.

 

And what did the Russians do...?? They used a pencil.

 

Case 2

 

One of the most memorable case studies on Japanese management was the case of the empty soapbox, which happened in one of Japan 's biggest cosmetics companies. The company received a complaint that a consumer had bought a soapbox that was empty. Immediately the authorities isolated the problem to the assembly line, which transported all the packaged boxes of soap to the delivery department. For some reason, one soapbox went through the assembly line empty. Management asked its engineers to solve the problem. Post-haste, the engineers worked hard to devise an X-ray machine with high-resolution monitors manned by two people to watch all the soapboxes that passed through the line to make sure they were not empty. No doubt, they worked hard and they worked fast but they spent whoopee amount to do so.

 

But when a rank-and-file employee in a small company was posed with the same problem, he did not get into complications of X-rays, etc., but instead came out with another solution. He bought a strong industrial electric fan and pointed it at the assembly line.. He switched the fan on, and as each soapbox passed the fan, it simply blew the empty boxes out of the line.

 

Moral:

 

1.. Always look for simple solutions...
2.. Devise the simplest possible solution that solves the problems...
3.. Always focus on solutions & not on problems...

 

 

Keep your own solutions simple. Imparting the same thought principle to the developers coding your solution is vital too. Taking some of the fundamental aspects of test driven development and pushing them into your development environment may be a good idea.

 

From a high-level, these are the principals:

• First pass – does it do what it is suppose to (meet the functional requirement)?
• Second pass – does it not break under alternative scenarios (does it throw the right error messages if the printer is out of paper vs a paper jam)?
• Third pass – is it optimised /intelligent /elegant?
• Fourth pass – does it integrate with the rest of the solution?

With this lot in mind, as long as the requirements are defined and well thought through there is no need for developers to create a cannonball to kill a mosquito. The developer should be given sufficient time to go through the specification, understand the requirements. Specifications can almost always be improved; however, these should be posed as suggestions. With this time frame developers should be able to create their own test cases which would provide some valuable insight for the BAs.

 

To developers: Develop within constraints supplied by the architect and business analysts. If you don’t like the framework, question it in the proper forums, raise a change request and justify it properly. Convince them the change is necessary and will save time. Don’t become a rogue developer and just “do things”. You may risk causing your project to be shelved… or worse implemented and failed. The framework and boundaries are there for a reason. Time, money, existing environments, lack of skills after hand over…. Etc. There is a bigger picture than your module. Remember young pad wan developers - with great power comes great responsibility.

Make a Comment
Current Comments // 00

No cookies... next time, you won't have to type in your details.

Comment