Software Craftsmanship: Going Dark (Or why you need a flashlight)

Over the last few places I've been employed at I've given a similar presentation on the topic of Going Dark.  I think it's time to unleash this topic to all three of you out on the interwebs. The term Going Dark may or may not be new to you. Hopefully by the end of this post you'll understand why it's bad, how best to identify it, and how best to avoid it.

Taking a look back at the last few posts I've done on Software Craftsmanship you've probably noticed a pattern emerge in what it means to treat software as a craft. I'll lump them into a category called Software Development Ideals.  So what are those ideals?

• Develop software for maintainability first
• Reduce the waste in our development cycle
• Reduce the complexity of the software
• Introduce less bugs as more features are introduced
• Write better code faster

Before we talk about how Going Dark is the antithesis of the ideals I think it's important to understand the symptoms associated with Going Dark. Those symptoms are:

• Working in isolation on a specific feature or problem for long periods of time
• Waiting to check in code till the feature is “complete"
• Failing to communicate or collaborate on software features as feature development “starts going bad”
• Constantly having to explain your work before and after you commit it to your repository
• Leads, management, or other teams members feeling like what was built wasn't quite what they expected

“Developers who work for long periods -- and by long I mean more than a day -- without checking anything into source control are setting themselves up for some serious integration headaches down the line” Jeff Atwood – Coding Horror

“Developers often put off checking in. They put it off because they don't want to affect other people too early and they don't want to get blamed for breaking the build. But this leads to other problems such as losing work or not being able to go back to previous versions.”
Damon Poole– Author of “Do It Yourself Agile”

Okay so now that we're able to identify the symptoms of someone who has gone dark. Let's talk about why not treating the problem is actually costing you lots of time, energy, and wasted cycles.  There are several problems associated with someone who has gone dark.

• There's more code to integrate on each check-in
• Code that is written in isolation is full of assumptions about the other software with which it will be integrated
• Each assumption is a potential issue that will only be discovered when the software is integrated
• The more code you have to integrate the higher the likelihood of introducing bugs
• The longer you wait to check in your code the higher the likelihood of breaking a piece of NEW code you've written before you check it in
• When you're on the wrong path you end up spending more time going down that path rather then being able to have your path corrected sooner
• There's no way to "gut check" your progress
• Closes your code off from scrutiny (which may seem uncomfortable but ALWAYS makes your code better)

That list alone should scare you. My guess is that you can probably relate to it. You've probably participated in "merge parties" or spent half a day or a full day trying to re-merge your changes after someone else beat you to committing and has changed the topology of the code. Maybe you've come in one day to find that there's a new bug in the system because a merge went bad and something got missed or accidentally added.

The great thing is that there are some pretty simple changes that can be made. The first is to start working out how to make lots of little small changes in the system which can be verified along the way. One good method for doing this is using some form of Test Driven Development. Once you've started to follow down the path of thinking about your code in bite sized pieces, all of which have an associated test, you can start to think about checking in those bite sized pieces frequently. I like to think about this as Checking In Early and Often. There are a lot of benefits of checking in early and often, and you'll notice that they are solutions to the problems that are presented by Going Dark.

• Change set is much smaller which means it's much more manageable and has a lower impact on the code base as a whole
• When you start integration of your changes the chances of having changed the same method or function as someone else is much smaller
• Less of a chance of having to reapply your changes on top of someone else's just because they beat you to the check-in
• When others refactor, you obtain the benefits quicker with less integration work
• Reduces the likelihood of anyone's changes being lost or overwritten by a bad integration
• Easier to find bugs because there's less code to search through
• Easier to fix bugs because there's less code that could be possibly causing the bugs
• Helps to reduce unnecessary code (YAGNI) as you're just writing the code you need to do the task you're on

Go forth into the light and help others come out of their darkness!