Monday, March 24, 2014

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

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

About Me

I’ve been in the technology industry for 14+ years mostly as a Software Developer. I've worked on projects ranging from a Ruby on Rails Portal, a high performance/low latency .NET search stack, R&D for building infrastructure in the cloud including automated server builds using Chef, to architecting and building iOS and Android Mobile platforms and frameworks.I've also spent some time building Android, iOS, Windows Phone, and Bada mobile applications that focused on the presentation of long form audio/video.The middle of my career was spent at MSNBC working on their content management publishing platform, their video syndication system, as well as being a co-creator of their iOS iPad framework from which the Rachel Maddow, Today Show, and Nightly News iPad apps were built.Finally, the beginning of my career was spent writing software on government contracts with a few years spent writing criminal investigation software.