This article covers my thoughts on when developing code in a team, should you develop to the lowest skill level in that team? I'm beginning to think you should. Read on for my thinking behind this...
Introduction
Recently, I started to think about when a developer is writing code in a team, should they develop to the lowest skill level in the team? I'm started to come to the conclusion that they should and this article explains my reasons for this thinking.
Background
So what brought me to this way of thinking? Well recently I posted a small tip for an simple extension method I have created to convert a typed list into a CSV string.
My solution was 100-odd lines of "traditional" code with "for i" loops, braced "if" statements and broken into lots of short and succinct methods. However, almost immediately responses started to appear with suggestions that maybe the code should be refactored into a complex one-liner made up of LinQ, Lambda and coalesce expressions.
Now, I don't have any beef with one-liners and the responder has clearly showed off his technical knowledge of both LinQ and lambda expressions. The problem for me is that I did not find it easy to read as personally I am not good with lambdas or complex LinQ queries; and bear in mind that I already knew what the problem the coder was trying to solve was!
So I started to imagine what it would be like if I run into this code while supporting one of the apps from another member of the team I work within at my place of work. I'd have two choices. If the guy who wrote the code was available, then I'd have to get him to go through it step by step until I understood it. If however the guy who wrote it was absent or unavailable, then I think my next choice would be to let Resharper "Unfactor" the code back to for-loops and if statements.
So this really got me thinking which brings me on to the reason I am typing this article...
Why Should We Write to the Lowest Skill Level?
Now this subject is going to be contentious for sure, as one of the key driving forces for any developer is to learn new ways to code, new technologies and new frameworks and maybe even new languages to program in. But what I'd like to propose is a different way of thinking when working in a commercial development environment where multiple members of a team will end up supporting a developer's code. Take the following scenario for instance.
Scenario
A team of five developers are working as an internal development team for commercial company called Company Z. Senior Developer A and Senior Developer B are very technically adept senior developers and are always pushing forward in their knowledge and the technologies they experiment with and implement in their projects. Developer C and Developer D are competent developers and although are not the architects of new coding practices in the team, they can follow and support most of the code the first two developers write, but maybe sometimes after a fair bit of reading and re-reading. Developer E is a relative new comer to the team but has been with the business for years writing VBA macros and functions for Company Z's many MS Excel Spreadsheets and MS Excel databases. He/she has an abundance of business knowledge about the company but is still lacking in some of higher level the skills and confidence levels of the other four developers in the preferred team development language.
Senior Developer A and Developer C are working on a new project together and want to implement a coding architecture which they have recently read about. They know Senior Developer B is also interested in using this new architecture at some point and would welcome it to be in the coding portfolio for the team. However neither Developer D and Developer E are not up to speed on this architecture and generally write their code in a more traditional style. Should Dev A and Dev C just crack-on and implement this new code architecture in the new project? From their perspective of course they want to. They want to increase their knowledge and probably also their employ-ability by adding this new technology to their CV / Resume for the future. Not to mention the fact that new code architecture, framework or programming style IS always exciting.
But what does the team as a whole gain from this? The team gain an ever evolving code base where standard ways of working can never take root due to the pace of change. The lower skilled members of the team may start to feel alienated as the goal posts keep moving before they get a chance to reach them each time. The skill gap may grow and they may dread having to support yet another app from Developer B, because they know it will mean trawling through lines upon lines abstract code full of the latest coding fad just to understand it.
And what does the Company Z gain from this? Not much. If developers are allowed to write the code that their ego demands with no regard for the ability of other team members to be able to read, extend or support the code, then the company gains nothing but a prospective single point of failure for the application and maybe half of the envelopment team feeling disheartened and un-enthused. It may also cost the company more in support time, which is going to come off the bottom line and in turn hit the developer's prospective bonus.
So What Am I Saying Here?
So am I saying all developers should abandon learning new ways of developing? No I am not. What I am saying is if you do want to learn and try new things, make sure you bring the rest of your team with you on the journey. Involve the rest of the team in decisions about trying new frameworks or architectures. Make sure you do regular show-and-tells, or lab sessions to make sure everyone in the team understands why and how the new architecture was implemented. Make sure your code is readable and understandable by all of the team who are supposed to support it. If you have written a magic-one-liner, please ensure your junior developer can understand what the hell it is doing. If he can't and you can't train him to understand quickly, then break it out into bite size chunks which he can understand. For the sake of the business you work for, don't let you and your coding ego be a single point of failure for an application your team (should) support.
Confession
Don't get me wrong I am as guilty as the next man for trying out that amazing new framework in a project and just hoping the team will be able to support it in my absence! I have also been at the other end of the stick too, for instance when I had to learn about Ninject and Dependency Injection a few years back to be able to co-develop on a project where that framework and methodology was already put in place by the lead developer. I felt I'd never get it (maybe this was the same way as I had felt many years before when moving from procedural code to an OO approach) and felt overwhelmed and unable to comprehend how it all plugged together.
But I am trying to change my mindset, and with this article I am trying to help you change your mindset too so the coding world we live in is a better place, especially for the junior devs or those whose job roles have mainly kept them supporting and extending legacy code applications!
Summary
So to sum up... we all like to strive to improve our development skills and knowledge and in no way am I saying we should not. But when working in a team with code the team will end up supporting, maybe we should step back and think a little different. Will Jimmy the Junior be able to support this or will I need to explain it to him? Have I just written in a single point of support failure that no one will understand except me?
Maybe in the same way, you might ask a more experienced developer to review and critique your code for technical excellence and readability, you should also ask the junior dev to read your code and explain to you what he thinks the code is doing. If he can't explain easily, then maybe don't include the code, or if it really must be included for technical or performance reasons, take responsibility and arrange a knowledge transfer session to bring all team members up to the same level for that element of code. Remember until performance becomes an issue the best code is clearly understandable code.
Feedback
I'd really love to hear from the community what their thoughts and feelings are on my thoughts about writing for the lowest skill level. I'd like to hear from both sides of the coin; from the technically advanced architecture astronauts reading the latest blogs and implementing the latest code fad into their production code the next day, right down to the junior devs trying desperately to support that code that they can barely read, which appears to model some abstract idea which they can barely understand.
History
