Awhile back, I read two very good blog posts both talking about technical debt and passionately treating it as a sunken cost. The 1-2 punch of these articles made me much more aware of the long term effects that “rotten” software can cause.

The majority of the time it is management that has a tough time throwing away previous investments. Hypothesizing, I believe this is for two reasons:

1. Lack of visibility

Because managers are not doing the work they do not have the visibility of how evolutionary the current project may or may not be. Some projects move and shake a lot, others are more linear in nature. Although requirements may evolve (or even contradict), progress will often give management the illusion of being linear.

2. Fear of promoting refactorbation

In the majority of cases, it is not the developer who is afraid to throw software away. I have seen developers literally beg that previous work be tossed out (and in most cases the work is even their own). It is my belief that developers actually represent the unhealthy reciprocal of this situation by refactorbating.

Managers do not want to fuel a need to code towards unattainable perfection, thus sacrificing velocity towards the end goal; after all nobody but the developer cares what the code looks like.

The manager can always reject a request to refactor, likewise, the developer can pull the trump card and never ask for permission. So what can both sides do to defend against each other? Previously, I have struggled with a number of ideas, but have boiled it down to these tips, one for each side.

Developers – Pick your battles

Learning not to cry wolf every 5 minutes is important. If asking permission for a large refactor is an exception rather than the expectation, the validity of your request will be weighted heavier.

Which battles do you choose to fight? Pick the battles that will cause you long term maintenance headaches. Wanting to refactor 50k lines of code to use generic collections rather than typed collections? Probably won’t matter in 5 years, generics will be out of date too. Want to refactor Crystal Reports out to use SQL Reporting Services…now that is probably a good refactor…

Managers – Maturity + Trust = Permission

Again the responsibility/authority principle comes into play – you can’t give one without the other.

If you have a mature developer coming to you, and you trust them to act in the best interest of the project, their should be no reason you never deny them the authority to execute – get the hell out of the way.

If you trust the developer, but they do not have the maturity – find a lead developer to make the call.

If you have a mature developer that you don’t trust – fire them. There is no room in business to be working with people you don’t trust. Period.

Throwing away work is not a crime, but carrying technical debt is. Learn the difference, and sometimes time lost is actually time saved.

During this last holiday season, I read numerous new articles about ‘Secret Santas’ covertly donating thousands of dollars into bell ringers’ kettles. Always associating things with software, I instantly related it to my previous post about the selflessness of OSS developers. Just like ‘Secret Santas’, the more I am aware of their activity, the more I am humbled by these people.

Selflessly giving their time and knowledge to OSS projects, blogs, and forums; developers seem to give so much back into the community. Musicians, artists, scientists, doctors, whomever, all seem to have one thing in common – in the end they all want to be accredited for their work. Never have I seen a musician announce they have created a musical riff to allow anyone to sample, and I highly doubt the creator of the artificial heart didn’t ask for a dime.

As a result, I recently started to rethink an old thought if other careers care about their craft (or disciplines) as much as developers do.

Sure there are a lot of truly passionate occupations. Musicians and artists create works of beauty out of love for the craft, and scientists continually are hard at work solving the next big problem. Not to sound pretentious, but is it our craft’s unique stage of both engineering and craftsmanship that allows us to be more passionate?

So what makes developers uniquely give their knowledge and time away? Do we under estimate what our knowledge and time is worth? Is it our attempt to be part of the fundamental growth of our infant craft? Is this the way geeky introverts act in good will? What is it?