Author Archives: David Kessler

Navigating our Pair to Success

I’ve been pairing for over a decade. I’ve witnessed and tried all kinds of things shoulder-to-shoulder with all kinds of pairing partners. Through the years I’ve witnessed a single consistent misfire while pairing. We don’t understand our roles. As professional problem solvers we gravitate towards actively solving the problem at hand. 

Latest posts by David Kessler (see all)

Continue reading

Pain Driven Learning

I find that in software development, and also in life, people learn best within the context of painful experiences.  I’m not suggesting that software development mentors go out of their way to create painful experiences for their teams.  On the contrary, just start listening.  It doesn’t take very long to identify pain points within a team.  Equipping teams to solve their own problems is drastically more effective than teaching people the right way to think.   When I teach large groups I often describe my points as hooks or link where they can go back and expand their understanding.  This large-scale map is essential so teams have a shared road map.  But this is rarely enough.

Latest posts by David Kessler (see all)

Understanding is built incrementally.  Each hook requires layers of experience and reflection hung upon it to develop a robust context of understanding.  While there are a vast number of reasons that people are motivated to learn, as a mentor I find pain to be a constant source of effective mentoring.  Pain is easy to identify within a group if you take the time to listen.  As a mentor I search for the root causes that set this frustration in motion.  Once I’ve collected and researched a variety of pain points I look for common themes and related root causes.
I remember one team that had a significant trust issue between the business team and the development team.  The most obvious place that this pain point appeared was in the daily stand-up meeting.  The business members were quiet and withdrawn while the development team dominated the conversation.  As I started asking questions I quickly realized that there was a language barrier within the team.  While most everyone on the team grew up in the same country, the developers consistently used technical terms that confused and alienated the non-technical team members.  On top of this divide the technical team regularly used their exclusive knowledge to push decisions through.  After discussing this with the whole team we adopted a “no tech talk” policy at stand-up.  In fact we gave non-technical members cards that they could throw down in the center of the group if the speaker started using terminology that only part of the team understood.
This small but powerful modification significantly changed this team.  The business team stopped reading their emails and texts during stand-up and started engaging in meaningful conversations.  The technical team started translating their technical thoughts into business terms.  Changing how the team communicated not only aligned their conversation with the business, it began to leak into their code.  Constantly thinking about their work in the context of the business helped them create code that reflected the business.  Clearer code reduce unnecessary overhead related to translating business terminology into application terminology.  This increase clarity also cut down wasteful communication overhead and reduced the new team member learning curve.  Aligning this team was not just a feel good moment; it resulted in a critical alignment of their software with the business.
While this example focuses on “soft skills”, pain driven learning is applicable to every part of software development, technical or not.  I focus on pain points because they’re easy to find if you just listen.  The emotion surrounding these problems provides an implicit invitation for a solution.  The act of helping a team solve a problem that they face increases trust and moral.  Once a team believes that they can solve the problems they face, they become emboldened to look at their challenges and take steps to correct them.  These shared experiences draw the team together and provide a powerful environment for developing valuable software.  Mentors earn respect from their teams by helping them identify and overcome issues.  Respect opens avenues for powerful teaching opportunities that extend beyond pain points.
Effective mentoring is not delivered by force.  On the contrary, effective teachers must become students willing to listen and learn.  In the same way that effective software provides value to the customer, effective teaching equips students to keep moving forward.  The correct posture of an effective mentor is humility.
I find that in software development, and also in life, people learn best within the context of painful experiences.  I’m not suggesting that software development mentors go out of their way to create painful experiences for their teams.  On the contrary, just start listening.  It doesn’t take very long to identify pain points within a team.  Equipping teams to solve their own problems is drastically more effective than teaching people the right way to think.   When I teach large groups I often describe my points as hooks or link where they can go back and expand their understanding.  This large-scale map is essential so teams have a shared road map.  But this is rarely enough.

Pragmatic Application of Principles

I was reminded of a profound truth as I was re-reading Robert C. Martin’s book “Agile Software Development, Principles, Patterns, and Practices”, in C# this time.

Latest posts by David Kessler (see all)

It is not wise to apply (a) principle … if there is no symptom.

Continue reading

Automated Testing Strategy for Legacy Systems

Once you catch the automated testing itch you want to write test for everything. But should we use the same strategy for every piece of software? The conclusion that I’ve come to is no. While I’m completely committed to the practice of TDD and aggressive test coverage, I’ve found that legacy software needs to be approached strategically.
Continue reading

Hibernate Logging

Through the years I’ve encountered a recurring requirement. Clients need to log changes to the database for auditing and legal purposes. To satisfy this requirement you could add logging to every save/update/delete call in your code. Or better yet, you could create an aspect that wraps these calls. While these would certainly work Hibernate provides a convenient interceptor.

In this article I will show you how to add a simple logger to Hibernate.
Continue reading

Back to Basics: hashCode() & equals()

So we all know that if we implement equals() we must override hashCode() too. But why? The best explanation of this commandment can be found in Effective Java (2nd Edition) starting on page 45.


… Failure to do so will result in a violation of the general contract for Object.hashCode, which will
prevent your class from functioning properly in conjunction with all hash-based
collections, including HashMap, HashSet, and Hashtable. (Bloch, Effective Java, 2nd Ed.)

Continue reading

Next Step in Agility

I often find that teams that have adopted Agile practices quickly plateau. They often start by scheduling a daily stand up, planning in iterations, take time for a retrospective, and modify their estimation process. These are common first steps in the agile adoption process. Teams have varied success and commitments to these practices but nevertheless these are the low hanging fruits in the Agile adoption journey.
Continue reading