Month: May 2010

You are not a developer if you..

  1. don’t know the overall product you’re building.
  2. don’t know the context of the piece you’re building in the overall product.
  3. can’t empathize with the users of your product.
  4. can’t explain the business needs.
  5. don’t believe in continuous learning and improvement.

Sadly, just writing some code snippet doesn’t qualify you to be a developer, leave alone a good one.

Recently, I’ve heard many arguments in this context which I feel are absolutely absurd :

  1. Developer: My job is to write code. There are other people who take care of business needs.
  2. Developer: Why should I care about business needs? Doesn’t help me anyway.
  3. Developer: We should write this piece in Java. I know Java pretty well.
  4. Manager: Developers don’t need to know business side of things. They should concentrate on writing code.

These are signs of mediocracy. Good software isn’t built this way.

[tweetmeme source=”snarayan” only_single=false]

The best part of TDD..

[tweetmeme source=”snarayan” only_single=false]

Test Driven Development (TDD) in its lamest form is understood as “Write your tests first”. This is how most developers understand it. Some follow it too.. But is that all?

TDD as its popularly known, is not only about writing tests first. It is about Design, releases and a software philosophy.  Some of the prime features of TDD are

1. Simple & Evolutionary Design

Design to your current set of requirements. Do not bloat your design with unneccessary patterns and frameworks, unless you see a real advantage of using them.

2. Acceptance Criteria

Have boundaries of development, clearly defined by acceptance criteria. This helps you define what you’re trying to achieve.  So that translates to your tests. Tests are your acceptance criteria for each line of code that you write.  This helps you understand the requirement much better, hence result in getting closer to the solution and an overall efficient development process.

These are the major aspects of TDD that we practice.  Testing is one aspect of it, not the whole.