There is a team which commits to 10 features but ends up delivering 11 features. In the next release cycle (Scrum practitioners: read sprint), the same team commits to 11 features and ends up delivering 12.

Now consider this…

Another (a very similar) team commits to 15 features and delivers 12. And in the next time release, commits to 18 and delivers 14.

Leaving all other factors aside – which of these two teams is performing  better ?

When you see these teams in isolation, it’s very easy to appreciate Team #1 but  Team#2 will appear as a continuously under-delivering team. But the perception changes, when you juxtapose the two teams and compare them – Team #2 stands out as the winner.

You get what you measure.If you measure commitment- that’s what you will get. If you measure productivity- you will get that instead. So my question to you is-

Do you value commitment more than productivity ?

I don’t…
Continue reading »

 

If I were to summarize my experience in Software development, that I have gathered over the last 10 years or so, it would be more of a collection of “Don’t do that” rather than “Do that”.

In other words, I have learned more from doing things incorrectly rather than doing correctly. Why? I guess simply because the affects of mistakes stick for a longer time than the benefits you get from doing things the right way.

I may not know the best way to get to New york from Boston. But i can tell you what highways to avoid and what the rush hours are…

So today, I want to “confess” three mistakes that I did and the valuable lessons that I learned from them.

1) Don’t stop listening when you tell.

This was very early in my career, I was young and restless. At that time I was working on the authorization module of a Swing based CORBA client. Roughly put, it worked as follows: Users had permission to either read or create or modify information. Our trick was to have a semantics based naming convention for the button variables. Then using reflection, the buttons would get disabled, thus denying access to parts of the application
Continue reading »

 

‘What do you do after you find a bug ?- I asked a team-mate one day while we were having lunch.

‘Fix it’ came the quick reply, with out a pause.

‘No. No. I mean after you fix it’

‘Go home’ and then he quickly added – ‘ after fixing other bugs’ , now begining to look perplexed.

‘I mean , how do you…follow-up ? Do you revisit your unit test cases (if you have any in the first place), or do you talk to QA team to see ow they found it ? ‘ I clarified, having clearly understood that lunch is not a good time for such conversations.

‘Ah ! Well, I do that yeah- Sure helps’ He replied, nodding his head wisely.

By this time I knew that this was not getting anywhere- so I turned the topic to iPhone.

This is what my problem is.

I obsess over bugs. I am not satisfied just that they have been fixed. I need to know more.

How did it miss unit testing ?

Do the test cases cover them ? Do we need more test cases ?

Is it an indication of more defects that are yet to be discovered ?

Why didn’t the QA team discover them in the last iteration or before ?

Did we miss something in deployment ?

And on and on…
I guess this is a reflection of my underlying belief in my sub-conscience  that all defects are mistakes, And mistakes by definition can be avoided. Only if certain actions had been done, the outcome could have been different. Only if…

But are they ? Are they really mistakes? Or are they just a natural part of  development process ?

I guess I could argue either way…

My first instinct is to probe to find how we missed the defect and then identify what part of the process broke. And then go and plaster it with another counter process. Conceptually this will ensure that the defect doesn’t happen again and we will slowly tread towards a zero-defect software. Hmmm it can’t be that simple – can it be?

The problem is that we have just now put another layer of a process and mind you- these processes don’t come at zero-cost either. Processes need effort to be defined and maintained and then fixed when they break(just like defects !). I don’t think we should automatically head towards putting a new process every time we see a problem. Sometimes just talking about the problem makes it go away. But if it doesn’t and you have a repeat pattern- then go ahead and do something about it.

And then we also need to keep in mind that software development is a very human activity. There are somethings which you can control (Set up a daily integration build) and some that you can’t (Non work related personal problems). Also splitting hair for each and every problem can cause un-needed stress on all the parties involved. But then sometimes, it is needed- definitely.

To take a dig @ TDD- if you practise TDD religiously, you can have no bugs in the Production code. All your defects will be in the test cases- which can ‘t be that bad- eh?

© 2011 Technology Cafe Suffusion theme by Sayontan Sinha