Agile India Conference - Day 2

The highlight of Day 2 was undeniably Stop or I will bury you in a box by J. B. (Joe) Rainsberger.

This is what he had to say.

1. Stop writing comments where the code suffices.
What he meant was ensure class/method and variable names are descriptive enough. Modern programming languages do not restrict the size of these.

2. Stop working in codebase with compile errors
Developers have multiple projects opened in their workspace, some of which they don't use, with the IDE showing up several errors/warnings.

3. Stop insisting that writing the tests after is just as good as writing the tests before.
It is observed that developers end up changing the written code, while writing tests, when they find their code is hard to test
Developers end up changing code, when their tests break the functionality.
In short, they spend a longer time, writing code, then tests, during which refactoring written code, while they would have spent less time, if they wrote test first and then code.

4. Stop claiming that evolutionary design leads to poor architecture
Architecture is at a very high level and typically gets frozen at the start of development. Choice of app server, choice of frameworks constitute architecture. Pretty much everything else is design - whether it is high level or low.
You become good only by practice - there is no substitute for it.
You rarely have complex design

5. Stop writing tests for "coverage". The law of diminishing returns.
Specifically, writing tests without assertions is criminal

6. Stop arguing about whether a story is done.
Ideally, Done, is if some one can buy it.
Decide on the criteria. Stick with it. Don't spend time arguing about it.

7. Stop trying to increase your velocity
Velocity is not a goal - it is a measurement
Usually learning is the bottleneck
Spped at which we go, is the speed at which we learn
When customer talks about increased velocity, what he means is getting things sooner, not faster

8. Stop breaking up working teams

9. Stop acting as though agile is "what the project teams do".
All departments of an organization have to be agile, for the organization to be agile. Or we are just moving the issues elsewhere.

10. Stop telling people to "go agile" on their own
Support systems should be in place. Management should be tolerant of mistakes and the learning curve.

Michael Bolton's "Stop it" - Stop being "test zombies". Distinguish between checking vs testing. Checking can be automated - it is mundane, repetitive. Testing calls for brains.

What should be the goal (if not velocity)? It should be increased flow of value

Book references:

  • Chess - by Polgar
  • Psychology of a computer programmer
  • The Power of Full Engagement
  • Four hour work week
  • 3 signs of a miserable job

Reference to 3M, which publishes its financial data in their hallways, pantries and educate every one about the numbers

Usually, in an organization, every one does not align on purpose

Start "validating" your software - by giving it to actual end users.

Is code size, a measure of productivity? Not at all. Ask, does your company pay you per lines of code? If not, then why is this number relevant?

In fact, you know you are doing well, if you are deleting code, thereby adding feature!

Incorporating learning. 1 week a quarter to do something outside the product

If you are 10 times as good as your colleagues, and not paid as much, use part of your time to learn and hone your skills.
Participate in open source projects
Code retresats

90 minutes a week, code on the wall. Refactor as a team. At the end of 90 minute, either throw it or use it.

Questions on estimations - FP & cocomo vs ad hoc (as in agile). It is similar to economy which works with multiple currencies, even though exchange rate varies regularly


Popular posts from this blog

Opening a safe deposit locker in SBI

Opening a Kannada Word document

Automating a cordova ios build