Programming Without Fear

Speaker: Gil Broza

Gil Broza helps organizations, teams and individuals implement high-performance Agile principles and practices. His coaching and training clients – over 1,000 professionals in 20 companies – have delighted their customers, shipped working software on time, increased their productivity and decimated their software defects. Beyond teaching, Gil helps people overcome limiting habits, fears of change, blind spots and outdated beliefs, and reach higher levels of performance, confidence and accomplishment.

In the last six years, Gil has worked with organizations of every size and industry; he has conducted readiness assessments, skills trainings, project kick-offs, large-scale transitions, on-going process coaching, retrospectives, and process fix-ups and tune-ups. Prior to becoming a consultant, Gil was an R&D manager, team leader and developer for 12 years, successfully applying Agile methods since 2001. He remains proficient in Java, C# and C++ and has co-authored an interactive eLearning course on microtesting and test-driven development.

Gil has an M.Sc. in Computational Linguistics and a B.Sc. in Computer Science and Mathematics from the Hebrew University of Jerusalem, Israel. He is a certified NLP Master Practitioner and has studied organizational behaviour and development extensively. He has written several practical papers for the Cutter IT Journal, other trade magazines, and for conferences, winning the Best Practical Paper award at XP/Agile Universe 2004. Gil co-produced the Agile Coaching stage for the “Agile 2010” and “Agile 2009” conferences.

What People Say About Gil Broza

• “Gil’s agile coaching was critical to our transition to Agile development. In a very short time Gil helped us establish a true iteration-based process with accurate planning and solid execution.” – Yehoram Shenhar, team leader, Destinator Technologies
  
  
• “Gil is able to get people to try new things, even if they are a little uneasy about moving in the new direction… People know that they’ll have an out if they don’t like the results and that Gil will support them in trying the new approach. This was an important skill in our Agile transition. He also worked with me one on one to understand the current level of support there was for Agile, and together we developed a list of Agile stories for the transition. This assistance was instrumental in our Agile deployment, which eventually extended to over 400 people.”– Bob Fischer, Vice President, Fidelity Investments
  
  
• “He definitely helped us to become better developers and helped us leverage Agile effectively.” – Rick Silva, developer, Harvard Business School IT Group
  
  
• “Good listener, very passionate about the subject matter. Excellent facilitator.” – project manager, Fincad
  
  
• “Of all the presenters so far, you’ve been the most realistic.” – Bill O. commenting on “Secrets of High-Performance Agile Implementations” at SD Best Practices, Boston, 2008
  
  
• “I appreciate the fact that you can be trusted. You have helped our team as well as me individually grow and become well equipped for any challenge.” – Lidia Damian, tester
  
  
• “It was Gil who showed me what a standard software shop is really about and how it should function efficiently to produce high-quality software that best suits end users’ needs.” – Donghui Li, developer, Affinium Pharmaceuticals

Seminar Update

The seminar was a rousing success! Feedback from the attendees was that this contained great content, presented superbly. The evaluation form contained comments like:

• "Outstanding exercises. Gil was extremely clear."
• "Gil did a much better job of explaining the context/purpose of these practices than other presenters I've seen."
• "Well thought out and detailed seminar."
• "Gil is a great speaker and prepared very well."
• "I took a 1 day course in TDD (Test Driven Development) a little over a month ago. I got more out of this even without knowing Eclipse & rusty at JAVA."
• "Excellent instructor, giving practical examples, able to field questions successfully."
• "Good labs. Small enough but not too small."
• "Very informative, interactive, useful skills!"
• "Gil was great. Very informed and helpful."
• "Gil made complexity accessable! Extremely well though out."
• "Gil was fantastic. Great handouts, pre-work, presentation, on-his-feet answering questions..."

On the other side of the microphone, Gil was extremely impressed with the people attending the seminar. This was the largest single group he has taught, and everyone was fully engaged and participating for the entire two days. He said that he had never seen a group where everyone was sofully committed to learning. Must be something in the Boston water!

In addition to the technical content, Russell Doty of GBC/ACM presented some snippets on the soft side of The Journeyman Programmer. These were intended to stimulate discussion, and did just that! Some people found the concepts enlightening, and some strongly disagreed. A few people asked for the slides, which are attached here.

Finally, we promised to continue the conversations started in the seminar. We are doing this in our blog at TheJourneymanProgrammer.org. Please stop by, see if there is anything interesting, and join the discussion.

---

---

Lab Materials

Lab instructions and lab exercises are now available. Please download and install these before the seminar. (Note: these materials are only available to seminar attendees.)

Important: Update to Lab Materials

Well, we have our first bug fix - there is a bug in one of the lab exercises! The zip file containing the lab exercises has been updated. If you have previously installed the lab exercises, the corrected file is available by itself at Lab-LabelMaker-SolutionAfterLongParameterList-Java.

The Legacy Code Trap

Writing new code is one of the joys of programming. Modifying existing code is often one of the nightmares of programming. Unfortunately, you will spend more time modifying existing code than writing new code.

Modifying existing code often results in Whac-A-Mole Programming - you make a change in one part of the code, and a problem crops up in another place. You fix that problem and two more pop up. You quickly find yourself trapped in debug hell!

There is a better way - a sane approach to dealing with both new code and legacy code. A framework for bringing order to code chaos, for making changes to existing code that are actually improvements. And this seminar provides a powerful approach to developing and modifying code.

If you’ve been programming professionally even just a couple of years, you’ve likely noticed that:

• Fixing bugs can take anywhere from a few minutes to a few days - or even longer! - and is even less fun in code written by other people.
• The larger a feature gets, the longer it takes to enhance or maintain (and the scarier it gets to do so).
• However elegant, clear or clever your code appeared when you first wrote it, when you revisit it a year later you shudder (or scratch your head).
• Code-level documentation, even when it exists, somehow never gives you enough information.
• Even “tested” code breaks where you least expect it to.

Only a decade ago this was accepted wisdom about our profession. But it doesn't have to be this way!

In this Taming Legacy Code seminar, you will learn reliable, sustainable and enjoyable software development practices which you can immediately put to use. These techniques, first popularized in Extreme Programming (XP), have been proven, refined and extended for more than a decade. By using them you will produce working code faster, increase its quality, and reduce technical debt — the demon that snarls later development.

(And if you happen to be working with an Agile team, perhaps using Scrum, you’ve probably noticed that traditional software development tactics don’t work as well anymore. Big Design Up Front, detailed design documents, manual test plan execution, code freezes and other plan-driven approaches just don't achieve great results in a fast-paced, iterative environment. In fact, an Agile project management framework without suitable technical discipline is a great way to guarantee failure. The techniques you’ll learn in this seminar are just the ones you need.)

After this seminar you will be able to:

• Develop simple, clear, tested code faster than you ever did
• Practice modern techniques such as test-driven development and refactoring
• Evolve object-oriented software with tests’ guidance
• Unit-test the tough cases
• … And have the skills needed to stop dreading legacy code!

Seminar Topics

Code smells. Just as programmers can leverage design patterns and good Object Oriented (OO) practice to produce excellent code, they can know what sort of code to avoid. This knowledge has been catalogued and codified as a few dozen anti-patterns called “code smells”. Methods so long as to require scrolling, classes that have too many disparate responsibilities, and primitives that carry meanings are but three examples of code smells. We will study about a dozen common smells that occur within methods or classes. By studying these anti-patterns you’ll get a better sense of the code you do want to write, and develop your “nose” for finding low-level design defects so that you can more easily remove them from your code.

Refactoring. Even if the code you write today is 100% correct, you willl still have to touch it in a month or a year: Extract some reusable pieces, reorganize it for clarity, replace some logic with calls to shared functionality, simplify it, etc. Preserving behavior while improving implementation and design is called “refactoring”, and it is quite distinct from “rewriting”. In this seminar we will study two levels of refactoring:

• Low-level refactorings, such as Extract Method and Compose Method. These refactorings alter a few lines of code often in the context of one or two methods. They are quite mechanical in nature, to the extent that modern tools like Eclipse have automated them almost entirely.
  
  
• High-level strategies, such as Gradual Cutover, which combine several low-level refactorings to make refactoring safe and reliable. If you’ve ever had to make medium- to large design changes, perhaps some of your unit tests began to fail, or the code didn't even compile for a few hours; these strategies will help you avoid this scary zone.

Microtesting. Commonly called “unit testing”, this is the art and science of writing focused, quick, extremely low-level tests against your code to prove that it does what you think. By writing many of these microtests against your code, you will be able to develop it predictably, introduce far fewer defects, and spend a lot less time debugging now and later. However, the trap of microtesting is that you may develop brittle tests - tests that are difficult to change and subject to many of the same problems as the code you are working on. You will learn what makes great microtests and how to produce them.

Test-driven development (TDD). The TDD process is the best thing you can do when writing new code, be it small or large. TDD combines microtesting, small code increments or changes and merciless refactoring to have you write great code without fear. Remember when you would write a few dozen (or a hundred?) lines of code, start testing them, then fix the bugs you found? And remember that it was impossible to estimate (guess) how long finding and fixing the bugs would take? That is a thing of the past with TDD.

Having studied basic application of code smells, refactoring, microtesting and TDD, we will work on “big code problems”:

Dependencies. Most objects in most systems don’t work in isolation; they depend on other objects. Sometimes these dependencies (a.k.a. collaborations, interactions) make testing difficult, unreliable, slow, or ineffectual. Still, that’s no reason to avoid microtesting and just do slow end-to-end testing! You’ll learn how to ensure the speed and fidelity of your microtests when dependencies are present. You will study techniques like faking, stubbing, mocking, and dependency injection. You will practice keeping your tests sharp while testing the contents and process of the interactions themselves.

Test smells. Just as production code has known patterns of ill-design (code smells), so do microtests. As more tests and production code get written, tests become more brittle, erratic, slow, harder to follow or reuse, and rife with duplication. We will study known patterns in which this trouble unfolds, and discuss ways to nip it in the bud early and often (hint: this has to do with refactoring…)

For a Journeyman Programmer, you will move from hacking at the code - perhaps creating more problems than you solve - to code craftsmanship.