The Craftsmen Aren't Crazy

My fellow apprentice Stephen had a great blogpost that I really just want to ditto. Stephen hit the nail on the head and I want to add some ideas his main points:

1) "I write tests because I want to code well and fast": I think it's important to note the huge amounts of time we lost because of poor code coverage. Weeks of work went down the drain on slippery bugs nested in tightly coupled code. The code base was begging to be refactored, but we simply couldn't without first testing the nasty code that wasn't our own. Furthermore, it was enough work to meet our stories on time in the system so refactoring outside the scope of our stories was rare and I wish it did not have to be that way. Test coverage is amazing. It drives simple development and loose coupling.

2) "Team communication is key": No matter what the circumstances, be communicative. I learned that it's more important to ask trivial questions than worry about looking dumb. We are not impressing the other developers on the project, we are impressing the client.

3) "Communicate religiously with the client": Acceptance criteria is almost always not specific enough. Do not let the client get away with specifying vague stories. This will always come around to bite the developer when the developer's vision does not match the client's vision. Also, use acceptance criteria to force the client to understand what it is they want implemented, exactly. Colin and Justin gave some insight into their troubles with the client not understanding the story they were asking for and it really changes the flow of the iteration as time moves forward.

4) "Pair programming is awesome": It is awesome! Our project implemented code reviews and the process was more tedious and less productive than pair programming in all instances.

5) "Clean code matters": As the project grows in size dirty code gets dirtier and dirtier. It receives 'bit rot' and even though it's been working as is the entire time it can sneak in and break the project. It collects dust. A feature you thought lived totally on its own is now breaking all of the tests. It's terrible too, since it's completely avoidable. Coming off of this project I understand the importance of clean code in the scope of a big project (especially one that is only getting bigger).