Agile FAQs
  About   Slides   Home  

 
Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
     
`
 
RSS Feed
Recent Thoughts
Tags
Recent Comments

Won’t TDD kill my Productivity?

Let me ask you, what do you mean by productivity?

Number of Lines of Code (LoC) committed per unit time….ahhh….I know measuring LoC is a professional malpractice.

May be, number of features committed per unit time….ahhh….ok…it does not end when I commit the code, it also has to be approved by the QA. So lets say number of features approved by the QA per unit time.

Well all my features are not of same size and they don’t add same value. So really measuring number of features does not give a true picture of productivity. Also just because the QA approved the feature, it does not mean anything. There could be bugs or change requests coming from production.

How about using function points or story points or something like that?

Really? You are not kidding right?

Let me ask you something, what is the goal of software development?

Building software is not an end in itself. Its a means to:

  • Enabling your users to be more productive. Making their life easier.
  • Helping them to solve real business problems, faster and better
  • Providing them a competitive edge
  • Providing new services that could not be possible before
  • Enabling users to share and find information more rapidly, conveniently
  • Automating and simplifying their existing (business) process/workflow
  • Innovating and creating kewl stuff to play with
  • And of course making money in the process
  • And so on…

Keeping this in mind, its lame to measure or think about productivity as amount of software created. I’ve never meet an user who wants more software. What users want is, to solve their problems or to enable them with the least amount of software. (no software is even better).

To be able to really help your users, you need to build the least amount of software that will not only solve the problem but will also delight them. Get them addicted to your software. IMHO, that’s the real goal of software development. One needs to use this goal to measure productivity (or anything useful for that matter).

So

  • Checking-in code
  • Having the QA approve it
  • Having it deployed in production

None of these is worth measuring. For a minute, get out of your tunnel visioned coding world and think about the bigger context in which you operate. Life is much bigger. Local optimization does not really help.

I recommend you read my post about: Why should I bother to learn and practice TDD?

  • A very true post I would tweet 100 times (After that I may get tired) :).  I don’t like when people use QA signoff (I don’t like signoff. It sounds like report card). Thats why I also don’t like story point or metrics driven development.
    That is why I like the lean’s concept of starting with user’s need. That being the begining, should loop back to the begining and see if we solved the need. Not sure most of us are looking at it.
    But what would be a good way to measure this? Talking with the customer, Seeing how much they want to work with us again and how much they recommend us. Using user satisfaction survey after we deploy the software 🙂

  • A very true post I would tweet 100 times (After that I may get tired) :).  I don’t like when people use QA signoff (I don’t like signoff. It sounds like report card). Thats why I also don’t like story point or metrics driven development.
    That is why I like the lean’s concept of starting with user’s need. That being the begining, should loop back to the begining and see if we solved the need. Not sure most of us are looking at it.
    But what would be a good way to measure this? Talking with the customer, Seeing how much they want to work with us again and how much they recommend us. Using user satisfaction survey after we deploy the software 🙂

  • Nice perspective Naresh. I think we often don’t take the time to step back and think about the big picture.

  • Nice perspective Naresh. I think we often don’t take the time to step back and think about the big picture.

  • Good posts on TDD.  Well said and good perspective.  One of the biggest push backs I get is “if you write all those tests, if the code changes, you’ll need to maintain the tests too.”  Some people just don’t get it! LOL

  • Good posts on TDD.  Well said and good perspective.  One of the biggest push backs I get is “if you write all those tests, if the code changes, you’ll need to maintain the tests too.”  Some people just don’t get it! LOL

  • @John, I think the concern is valid in some regards. Esp. when you see people writing tests too tightly coupled with their implementation. Or when they try to bullet proof their apps using tests. 

    When I’m TDDing, I’m not trying to bullet proof my app. All I’m trying to do is drive my development in baby steps, one test at a time. I’m thinking about the intent and letting the test guide me. I’m also being pragmatic and thinking about ROI. I just don’t want to write tests when they are not really help me drive my development. 

    Many times, I find I’m hitting a dead-end and don’t know what to do next. Then I go off and do some prototyping (read as, throw away prototypes in code). This might give me new ideas to move forward. 

    Again the goal is to make progress, get constant feedback by taking baby steps and really feeling in control of things.

  • @John, I think the concern is valid in some regards. Esp. when you see people writing tests too tightly coupled with their implementation. Or when they try to bullet proof their apps using tests. 

    When I’m TDDing, I’m not trying to bullet proof my app. All I’m trying to do is drive my development in baby steps, one test at a time. I’m thinking about the intent and letting the test guide me. I’m also being pragmatic and thinking about ROI. I just don’t want to write tests when they are not really help me drive my development. 

    Many times, I find I’m hitting a dead-end and don’t know what to do next. Then I go off and do some prototyping (read as, throw away prototypes in code). This might give me new ideas to move forward. 

    Again the goal is to make progress, get constant feedback by taking baby steps and really feeling in control of things.

  • Hemant

    Sorry Guys,

    Am bit of a sceptic here…
    I would like to understand how you guys can give some commitments on when things would get delivered, especially when metrics and data is the key for future projects..

    other industries have matured due to gathered data..while i understand sw dev is not a factory, we still need to have data which can give us some predictability.

    my business wants to know when I can deliver a particular product, and if i havent calculated previously, its very difficult to predict accurately.

  • Hemant

    Sorry Guys,

    Am bit of a sceptic here…
    I would like to understand how you guys can give some commitments on when things would get delivered, especially when metrics and data is the key for future projects..

    other industries have matured due to gathered data..while i understand sw dev is not a factory, we still need to have data which can give us some predictability.

    my business wants to know when I can deliver a particular product, and if i havent calculated previously, its very difficult to predict accurately.

  • @Hemant, you don’t have to be sorry. Being a sceptic is not a bad thing. 

    I would strongly recommend you read my blog on Estimations Considered Harmful and Projecting Velocity is Useless. That would completely confused you and hopefully will show you why the whole “Number Drive Development” approach is fundamentally flawed. 

  • @Hemant, you don’t have to be sorry. Being a sceptic is not a bad thing. 

    I would strongly recommend you read my blog on Estimations Considered Harmful and Projecting Velocity is Useless. That would completely confused you and hopefully will show you why the whole “Number Drive Development” approach is fundamentally flawed. 


    Licensed under
Creative Commons License