There are so much “productivity hacks” out there. The blog lifehacker is full of little productivity hacks to boost your effectiveness. For developers we have more stuff to look at that every one else combined. This is not an article about some yet-another-incredible-new-tool, because there will be a better one next week. I’ll have plenty of time later to talk about my favorite tools that are great Time Savers. But IMHO, there is no tool yet that is as high a productivity booster as owning whole features in an application.
The current problem with any tool is that you can have a productivity increase of 1.5x – 2x. Maybe you can make that number 3x - 4x if the tasks you have to accomplish are repetitive, you are a master of your particular tool and you take the time to enhance it, creating your own snippet or macros. The thing about it is that, with most these kind of tools, you just become a faster typist. Since the number of lines of code is a terrible productivity metric, we can assess that being a faster typist doesn’t necessary make you a more productive developer.
The real productivity gains lies elsewhere. It has been given many names : Being “in the zone”, “in the moment”, “in trance”. Everybody has experienced this state of mind where time seems to stop, you lose awareness of everything around you and you wake up, several hours later, having done a week’s worth of work. This state of mind is one of the main points of the classic software project management book Peopleware. Getting into that state of mind can take from 15 minutes up to a full hour or even more depending on the individuals and many others parameters (ambient noise, stress level). And getting out of that state of mind is terribly easy.
But what’s all this have to do with developers owning some features? Simply that owning some code will make the “in-the-zone-boot-up-time” a lot shorter when working on that particular piece of software. Basically, what’s happening when you are in the process of getting in the zone? Your subconscious mind is loading (or, at least, tries to load) the entire problem space that you’re facing. When there are unknown elements, as there are always in shared code situation, the problem space is filled with variables elements, making the process really harder than if you know everything about the problem.
When you own features, you have seen (and probably written) every single line of code and you know every bit of functionality, every hack that shouldn’t be there and every little design flaw. So when you work on that feature, the feature problem space contain only known elements and is a lot easier to load in your subconscious mind. Moreover, it helps a lot for debugging and refactoring situations to know the entire feature characteristics. The developers that own their features will avoid a lot more pitfalls than those who share functionnalities, simply because they know the implications everywhere of the code they’re writing.
Owning features is not only beneficial on the developer’s performance side. Developers in general are elitist people and they don’t like others developers messing with their code. The fact that it is clearly stated that features X, Y and Z are properties of Joe Developer will surely make him not only happier on the job but he will be a lot more committed to those features than he could ever have been otherwise.
But that’s just me, what’s your opinion on this subject?