Thursday, June 10, 2010

Bad Code, Craftsmanship, Engineering, and Certification

Clean Code: A Handbook of Agile Software Craftsmanship
At QCON 2010, Robert Martin gave a talk about Bad Code, Craftsmanship, Engineering, and Certification. Uncle Bob started the talk by showing an example of bad code which consisted of two massive classes with hundred of methods. He asked why do we write bad code that we know will impede us? And wondered if it is due to deadlines, laziness, boredom, or job security. Bob stresses that the way we go fast as professionals is to do the best job we possible can. He encourages us to wear a green band on our wrist that symbolizes a commitment to write the best code we can at all times.

Uncle Bob then makes the following recommendations:

1.      Apply the boy scout rule: Always leave the camp ground cleaner than the way you found it. That is, whenever you work on a class or function, spend some extra time to refactor it and clean it a little.

2.      Apply Extract till you drop: Function size should be small. Keeping extracting until you can no longer extract the function. This takes all the concepts in the function puts them in well named places.

3.      No argument is the best argument. Functions should have the smallest number of arguments possible. Try not to exceed 2 arguments. Do not pass Booleans as arguments; instead create two well named functions.

4.      Use long names to be as descriptive as possible.

5.      Avoid duplication. Do not copy and paste.


Next Uncle Bob goes over the Software Craftsmanship Manifesto which states:

1.      We value not only working software but also well crafted software

2.      Not only responding to change, but also steadily adding value.

3.      Not only individuals and interactions, but also a community of professionals.

4.      Not only customer collaboration but also productive partnerships.


He then covers the disciplines that the manifesto is based on. These include:

1.      TDD – verifies that our code works and also makes it possible for us to refactor and constantly improve the code over time.

2.      CI: Use tools like Hudson, CruiseControl, Bamboo, and TeamCity. If the build fails, immediately fix the build.

3.      Pairing: If you don’t want to code pair, at least make sure the team is communicating, sharing and working closely together.

4.      QA should find nothing

5.      Have pride in workmanship

To convince others, the best thing you can do is do the best job you can and be a role model. Soon others will observe that you are outperforming the rest and will realize why.

Uncle Bob next covers the engineering practices of small cycles feedback, source code as the design, and design patterns. He wraps up by discussing certification and how they over promise and under deliver. Instead he recommends actually talking to potential new hires and have several team members talk to them as well. Let them show you code samples. Ask for references and check those references.

This presentation is available on InfoQ at http://www.infoq.com/presentations/Robert-C.-Martin-Bad-Code