Agile non-negotibles

Agile non-negotiables are those software engineering practices that you'd be crazy to go without.

Unit Testing: Knowing your code works
Refactoring: Paying down your Technical Debt
Test-Driven Development: Knowing what your Goal is before Coding
Pair Programming: Tightly binding review and development together
Continuous Integration: Making it Production Ready

I'm a little crazy. I don't always use all of the above practices. I try to but my desire to be a hero and get things done quickly overcomes my sensible side. I think most people do this too. There are always outside influences that can seduce a developer into over promising.

The argument for ignoring those outside influences and always practicing the above agile non-negotibles is that you will have:
- better quality code,
- more consistent deliveries, and
- less bugs.

Stop worrying about taking three days to develop something that might have took two days had you left out unit testing or refactoring. That is only a short term savings. Consider how long it will take to fix a missed bug or add a new feature next year.

Using the above practices is an investment in the future of your software.

Pair Programming

I'm a big fan of pair programming. I have used it many times and almost everytime the result was better code that was developed faster. Pair programming is like having continuous code review.

Sadly, there is a lot of controversy with this particular agile/XP practice. Seeing two valuable resources sitting down at one computer makes most managers nervous. They think their team's productivity has just been halved. The worst thing about this mentality is that it makes it clear that the manager thinks programming is just typing.

Mere typing, programming is not. A good idea or a bug caught early on in the process can save a team a lot of work and rework later. By pairing you share valuable knowledge and practices throughout the team, catching more bugs early, and increasing code quality.

Merciless Refactoring

Many people are afraid to make code changes out of fear that they will break the code. To ensure you can safely make code changes you should change it often. I'm not talking about pointless changes but solid improvements. Run FindBugs against your code and fix the issues. If you disagree with FindBugs then use PMD or any static analysis tool. However, if static analysis suggests that your code looks like a bug then consider changing it to look less dangerous.

Anyway, the point of merciless refactoring is to always be improving your code. To make changes and ensure that it was easy to make those changes. If it isn't fast and easy then you need to make changes to make it fast and easy. Write unit tests, delete unused code, optimize loops, automate tests; everything you can do to make it possible to complete your next project in record time.

Merciless refactoring can also be described as following the boy scouts rule of always leaving a place cleaner than when you found it. If you add a method to a class then add some JavaDocs to the other methods while you're there. If you change a single line of code in a method, take a look at the entire class and fix it up if you can.

HIV/AIDS Cure Proof of Concept

New York magazine had this great article, "The Man Who Had HIV and Now Does Not", last month. It is as the title says about a man who was cured of HIV. It is an amazing read. It is not a cure for everyone; there are some specific genetics required but it is sparking new AIDS research.