Recently I found very interesting post of Jeff Atwood regarding developers and bad practice of
going dark. It was so thought-provoking that I decided to write a few my opinions how it looks like within
Cognifide. By going dark we should understand situation where developer is "locked in his room" for a long period of time implementing some piece of functionality until job is done. Definition of 'long period of time' will vary across different organisations. In our case, in
ASP.NET team we try to manage granularity of tasks in way that new modules can be implemented in days. If implementation of some module is going to take 1 week then it's considered as a big task. So going dark for us would mean that some developer is "locked" for longer then 1 week working on some gigantic feature. What's wrong with that?
Actually dropping such code-bomb can potentially create many problems:
- if there was any bad design decision made then whole new feature can be rejected as it may not fit to main project design. Please note that while developer is in the dark working on his feature, main project keeps changing,
- it's hard for other team members to understand and maintain new code
- it's almost impossible to do code review
Fortunately for us, we use SCRUM to manage ongoing work. Daily meetings significantly reduce risk of going dark, so good for us! But is that enough to be happy about the process? Jeff pointed out two things:
"The brilliant developer must be capable of performing on a team,
making his work visible in modest increments and subjecting it to
scrutiny as it matures."
and
"Hiding your code until it's "done" may feel safer, but it isn't.
Sharing your ongoing code with your coworkers is scary, much less the
world -- but it also results in feedback and communication that will
improve your code and draw you closer to the project you're working on."
I would like to highlight this part: "
feedback and communication will improve your code and draw you closer to the project".
Why is that important for me? From my perspective it doesn't matter so much if you are working on one huge project for a long time or on a few smaller, at some point you have your habits, your ways of dealing with tasks. After some time you have already solved most of the problems which means that implementing yet another class/module/feature will not give me much in terms of new skills, my code won't get better, in fact I'm quite sure that it will stay exactly the same.
Few ideas how to change it, how to encourage people to talk about code quality and good patterns and this way learn new things:
- pair programing when implementing bigger features. Main point is to avoid situation when there is only one person working on the feature and in the end this is the only person which is capable of maintaining it. I'm not saying that people should all the time sit together and do proper XP, work in parallel as much as you can. Important is that working with someone enforces communication and design discussions which in the end prevent from going dark.
- code reviews, that seems to be the most obvious way of improving my code, I need feedback from other people! Of course it would be great to see senior developers taking active part in code reviews, that would be the best way to share knowledge. But also it's worth to know what less experience people think, fresh approach is also important! :) As I see it, code reviews makes the most sense in the early stages of each project. But also it would be nice to have a 'code review' session once a month to point out some fresh ideas (people don't necessary need to show bad habits ... good practices should be also presented!). Important is to take notes, find consensus and write it down!
- internal demo after each iteration, it's vital to keep everyone up-to-date, it's also important to reuse similar approach designing all modules. That is another chance to communicate with peers, to get others people opinion. And additionally, it makes much more sense for end user when delivered project works and acts as a coherently designed system.
In the end, one last point ... I believe that none of us would like to end up doing one-man projects all the time. It usually means very small progress or no progress at all. We have lots of smart and clever guys around, we have opportunities which people in one-man project don't have so let's make a use of it. Don't be anti-social, communicate and improve your code!
