Thoughts on Systems

Emil Sit

Nov 16, 2010 - 2 minute read - Technology agile gbcacm gil broza programming selfimprovement tdd

Programming without fear

This past weekend, I attended Gil Broza’s seminar on Programming Without Fear, organized by the Greater Boston Chapter of the ACM’s Journeyman Programmer initiative. The seminar was as advertised, and covered:

For anyone with more than a passing interest in agile, the material Gil presented (covered in the links above) will not be new.

The benefits of the seminar came from two things. First, Gil presented the information in a somewhat “formal” framework: a taxonomy of code smells, a set of refactoring patterns, a pair of mnemonics (PRICELESS unit tests and TRUST your refactoring process) to help remember basic techniques. This gives someone new to the material an organized set of knowledge to internalize. Second, Gil has prepared a series of exercises, interspersed with the lecture-y sections, that seminar participants work through in pairs, designed to reinforce the theoretical frameworks with practical experience. Even as someone moderately experienced with these concepts, the exercises are useful in that they focus on the fundamentals and force you to actively strengthen those fundamentals. (The weakest section, I thought, was the one on mocking which received insufficient exposition and dropped the class directly into jMock, which was a bit opaque.)

Gil is not the most exciting or funny teacher but he kept the attendees engaged by teaching with a Socratic flavor—he presented examples and solicited audience evaluations, allowing the audience to interact to reach conclusions. The practical exercises were followed by group de-briefs. This encouraged the audience to stay engaged and better absorb the material.

My main worry about the techniques is the overall reliance on Eclipse (or other IDE) as a developer’s assistant: while certainly the tooling is convenient, they make me worry about Java and whether the use of tools and wizards weaken developers who may never learn how to do things themselves.

What I really enjoyed was the experience of actually developing and refactoring with the protection of a unit test suite and learning techniques to perform refactoring without more than a moment or two of compiler errors. This was in sharp contrast to my normal refactoring experience of making a top-level change and then following all the compiler warnings until the work is done. Now if only every codebase I worked on came with such a set of tests…