I recently took another look at Mike Gunderloy’s book “Coder to Developer” and one thought keeps crossing my mind – “what can make one group of developers so different from another?”
I’ve been on small and large software teams where the group dynamic is great – where I look forward to work every day knowing I’m working on delivering something great. I’ve also been on large and small teams where the group dynamic is murky at best. The biggest difference I’ve seen between these projects is the group’s ability to share ideas.
Products can be shipped with good or bad communication, but the job is far easier and more exciting with a group of programmers that talk code. Whether it’s over cube walls, at the water cooler or to-and-from Starbucks – it plays into code that’s far better than one great programmer could create by himself/herself. The best communicating teams I’ve been part of have consistently put out better designs – which have lead to patents, standards or articles. While I fundamentally disagree with software patents, it takes a solid design to stand up to the test of qualifying for a patent.
You cannot consistently ship a solid product with high turnover or coders who believe their section of code is their key to job security. You can push the team through things like murky specs, but without a constant influx of new ideas and approaches and code changing hands, the codebase will quickly degrade over time as the cost of maintenance goes through the roof.
The idea of code sharing is something I call "Code-Talking"’. As a developer, code-talking allows me to leverage the ideas and experiences of other developers while getting exposure to other areas by asking for ideas. Nothing is more flattering than when someone says “I’ve got this problem… What do you think?”
What is Code-Talking and how does it work? The areas are far reaching and this is the first in a series about the topic. To get a better feel for a code-talking environment, I’ll first look at it’s stark opposite – code ownership.
The Dark Side – Code Ownership
Code ownership manifests itself as the belief that a section of code is tied indelibly to one developer throughout the life of a project. Jim McCarthy made this one of his development rules titled “Beware the Man in the Room” where he warns of an individual developer being tasked with a key application feature that the success of the project hinges upon. While McCarthy’s example is an extreme situation, it happens in smaller ways on projects where developers identify with code as “theirs.” The best way to tell if you have fallen into this trap is when you are asked about your code. Are you defensive? Do you get a gnawing feeling in your stomach that your code is being called on the carpet? If so, you are feeling the pull of Code-Ownership.
When a developer ties himself/herself to one piece of code – or section of an application – over time, the ideas that went into making the solution great start to age. The code eventually starts feeling like a ball-and-chain, preventing the developer from moving on to bigger and better things. Through this situation, if the developer isn’t questioning the design and aggressively looking for new ideas, then the code becomes more brittle as it gets patched quickly so the developer can get back to better things. The absolute worst situation is the code-review prep – where the developer locks him/herself in a room, adding code comments prior to a code-review.
Code degrades over time regardless of the programmer’s skills – software entropy. In an open system, the input of energy reverses entropy (increases order) – and in software this energy comes from new, shared ideas and the ability to refactor throughout the life of the product. Software development is first and foremost a creative process and code-talking is a key way we can expose ourselves to new ideas and new ways of thinking. New ideas and concepts give us the ability to creatively solve problems and continue to question our assumptions.
Enter Code-Talking
Code-Talking happens between developers and cannot be mandated by management. However, code-talking almost never happens in formal meeting environments. Code-Talking happens when no one is worried that sharing their code and ideas will be used against them in any way. Most importantly, code-talking only happens when developers value each others' opinions and experiences in an open environment.
Code-talking is usually a passion held by two or more developers on the team. The talking becomes contagious between team members and the desire to contribute a new approach or pattern to the group’s idea toolset becomes a running desire among the developers. People email links or blog about the latest article they’ve read or the new book they’ve picked up. Developers spontaneously send quotes or code-snippets as a “check out this cool feature” message. The healthier the code-talking environment, the more developers are eager to learn from others and teach others as well.
Beyond the communication benefits, code-talking is one thing that can trigger passion in developers. I’ve found that many computer science Phds are natural code-talkers and contribute immensely to team communications – they tend to be highly motivated and view software development as the greatest job in the world. If you can’t afford or find a team of Phds, we need a way to encourage the practice and I believe that is where pair-programming comes in.
Institutionalizing Code-Talking: Pair Programming
Pair programming enthusiasts discuss many benefits of the pairing practice but seem to brush over the notion that developers become more confident in their code as though it was simply a pleasant side-effect. The ability to change a team’s working dynamic in this way is far too important be considered a side-effect – this benefit should be front and center. Developers not only become more confident in the code, but they become more confident and begin to rely on each other beyond filling a resource space on a project plan. This is the same confidence and camaraderie that leads to a code-talking workplace. It also breaks the code-ownership cycle and encourages developers to move around and gain new experience.
Summary
I believe code-talking is one of the critical factors to a successful software project. From what I’ve seen, it’s the difference between a team that survives the software delivery process to continue the fight and one that ends in programmer burnout and high turnover. I believe that code-talking may be one of the biggest arguments for pair programming – it’s perhaps the only tool capable of encouraging open discussion. The topic is immense and affects everything from effective application of design patterns to truly effective build cycles.