7/06/2012
One word:
I believe that a developer work should be one filled with the joy of creation. When I started out to become a programmer I thought that it would be great. my work will be filled with:
- Joy of creation when working on building a solution to other people problems
- moments of joy when completing new things and releasing them to the market
- moments of satisfaction from work well done
- moments of eureka when I find great solution to difficult problems
- moments of collaboration when I work with my team members to achieve a shared goal
a few years later I found out that:
- its not fun when you finally get your product to the market realizing you just solved the wrong problem
- Its annoying that whatever you are doing always seems to take longer then expected
- its frustrating when you never have enough time to actually complete your work as it should be done
- its not easy to work along other people which are stressed out just like you.
- its disappointing that you never get a chance to learn something new because now is not the right time and we first need to finish.
- its depressing to continuously get a stream of defects on the code you write
- its terrible to work 3 days straight to understand why the system keeps on crashing at your client, when it behaves perfectly ok in your own environment
- its frightening to work on unknown parts of the system not knowing if what you will do will only cause more bugs
So why should you learn TDD?
Because TDD is one major step towards bringing the joy back to work:
If you do TDD right, many of the stupid defects will go away.
if you do TDD right, your system design will improve making it easier and faster to change
if you do TDD right, you will have a safety net guarding you from mistakes.
and if you do TDD right, you may be able to bring some of the joy back to your work.
Posted in: 
Posts
4 comments:
imo your argument is somewhat flawed.
you say "you should do XYZ" because if you do XYZ *right* then it will be great.
XYZ does not necessarily have to be TDD.
e.g.: If you designed and implemented your system *right*, then the good outcomes you stated will have happened.
Not saying (at least not in this context) that TDD is wrong, just that the argument is.
Ken,
didn't claim that's the only thing that you can do.
Just that doing TDD right is one of those thing.
I'm sure there are other ways.
But I'm also sure we can agree that this is one of those.
Right?
"...its not fun when you finally get your product to the market realizing you just solved the wrong problem"
How do you find Tdd helpful in solving that? my experience tells me that - if anything - Tdd actually makes this worse. Team is so focused on unit level, that the "system correctness" is overlooked and neglected.
After all, that why BDD frameworks were born.
Moti,
I totally agree with you that TDD will not solve that. TDD won't solve all bad things happening to us. I also don't think that "System Correctness" has anything to do with that. Alignment with the business, understanding your domain and good people on the product side is necessary to avoid that.
Post a Comment