6th Sense gives deep insight into developer productivity

Worker productivity is no more a hot button issue than within the corps of the world's 9.5 million software developers. Demystifying development as a process and allowing developers to simultaneously demonstrate their true individual and collective worth -- rather than be lumped together as mis-understood cost centers -- has tremendous advantages across the software lifecycle ecology.

In September a new North Carolina firm, 6th Sense Analytics, will unveil a hosted service that automates the tracking of developer productivity. The implications are not just gaining accurate and transparent visibility into the actual work patterns of developers, but importantly amassing the meta data of development productivity analytics.

When such data are assessed and compared -- company to company, tool to tool, outsourcer to outsourcer -- project managers can finally get quantitative and qualitative rankings of what works and does not in the real world pursuit of quality code and productive development processes.

Not every developer is going to cotton to the idea of tracking what they do within their development tools and utilities. And this will not be easily brought into all development activities, based on the exisiting politics and control cultures. But I'd wager a lot of developers might like the idea of not having to fill out (make up?) project management tracking reports, and time tracking forms and papers ad naseum.

They may also like the idea of being able to demonstrate that it does indeed take time, care, patience, passion, and artistry to get good code right. After all, transparency is a hallmark of open source and collaborative development in a community. Why shouldn't work use transparency be a natural mode for individual and team development, too?

As a researcher, I love the idea of new and accurate metrics on what goes on amid development in the real world. Enterprise or ISV architects should love to really know what tools their developers actually use, how, and to what degree they benefit the bottom line. With such knowledge, enterprises, contractor developers, and ISVs may be able to stop paying for shelfware, and double-down on the investments in the tools, platforms, and frameworks that are actually getting the job done.

Furthermore, CFOs and CIOs certainly would like to know more on how their outsourcing dollars are better spent: In building out in-house development ranks, or via outsourced or mixed-source scenarios. With such insight, they might want to insist that any outsourced contractors in a bidding process provide a 6th Sense Analytics-type profile of what went into the creation and delivery of the last development project they delivered. There's no way to accurately measure these things now.

The 6th Sense blog offers a lot more on the virtue of developer use and productivity insights.

What also has me jazzed on this developer activities tracking approach is that it's not just germane to software development, but could be applied to many professional services and creative arts pursuits.

Because so many services and creative endeavors are built using computers and applications, the same sensors employed by 6th Sense Analytics could be used with many sets of productivity questions. The sensors are open source, so new ones could easily emerge for ever more applications. Graphics arts, editorial, accounting, back office functions -- heck, research and analysis (blog writting?) ... These all could be defined and tracked far better than they are.

I actually like the idea of my clients knowing what goes into what makes me productive, not to bill by the hour so much as to demonstrate true productivity: Good work done quickly. The results speak for themselves, yes, yet showing how well the processes leading to the results performed has merit too, especially for repeat work based on total quality and repeatability.

I hope an organic, bottoms-up enthusiasm wells up for these analytical tracking and automation activities. Indeed, we should have nothing to hide but the proprietry code itself, and even that is becoming less of an imperative as open source doctrines grow pervasive. In the case of code being open, the only thing remaining hidden is how developer productivity actually works.