Friday, February 20, 2009

case study...

This is a real life incident which happened this morning.

Context: Last night Developer 1 (D1) sent across a mail saying task XYZ cannot be done because current code (which is reused from an existing code base with minor tweaks) doesn’t have those pieces of instructions which can handle the inputs we are receiving and so we are ignoring the inputs as of now and we will need a discussion on the same.

Manager 1 comes in.

M1: Hi D1! What is it I am hearing? Why can’t we do that?

D1: Hi M1. Current code is taken from the existing code base which doesn’t handle what we expect. Also, we had conveyed the same earlier that this would not be possible to customize the accounts with current code and that all accounts will inherit their parent’s characteristics.

M1: But why aren’t we handling that? That means the design was flawed? B1 (M1’s boss) had clearly told that the code has to be reusable. Then the code should be able to do that. Why is it not doing that then?

D1: Well, because it is built that way. If we want that code to do extra tasks then it will require extra development work.

M1: slightly pissed off look… B1 will push it blah blah blah… (D1 doesn’t understand the lingo…) Costs are blah blah blah… Timelines are blah blah blah…

D1: startled look… silent...

M1: startled look… silent for a while... Ok! Can you just do some analysis and let us know why it was not done and what would it take to do it?

D1: hiding frustration behind a poor smile… Sure M1. I will let you know.

M1 goes and D1 puts his ear phones back and starts listening to Linkin Park.

Manager 2 comes in.

M2: Hi D1, how are you! I hope you are aware of the new requirement with respect to the accounts. Before we discuss anything, let me just say I am totally with you in and I totally agree that current code cannot do what it is expected to do.

D1: Hi M2.

M2: Can you just tell me, what’s the problem we are facing?

D1: Yes M2. The new inputs expect the new accounts to be customizable at child level. Till now, the code has been built in such a way that all the accounts inherit the characteristics of the parent account. In order to do that, we will have to do some extra development.

M2: Can you tell me, what are the extra attributes that are required to be customized at child level?

D1: Attributes, like billing frequency, billing currency, billing addresses and contact persons.

M2: Do you have any idea how many such clients are there?

D1: Nope. I will confirm with D2 and let you know.

M2: I think, just suggest what you feel… will it be a good idea to load all the accounts as current code does. And then write a small add-on script which will then take those additional attributes and write into the database.

D1: M2! D2 has confirmed that there are 14 such accounts.

M2: Will it be possible to set them up manually, instead of writing a script especially for them? D1! Can you please analyse both the options – setting them up manually, or writing an add on script to load only account specific data after main script runs, and let us know which option will be quicker, cheaper and better?

D1: Sure M2. I will get back to you in next 2 hours.

M2: Thanks D1.

D1: No probs M2.

M2 goes and D1 closes his windows media player and starts analysing the problem.

1 comment:

P.R.Santhosh said...

I would love to know who D1,D2,M1 and M2 are....mail karo sirjee...