Blogs

I have a professional crush. 

Gary Hewett of Technical Magic manages the infrastructure of a well-known records and information management group.  I’ve had the privilege of working with him for the past year and a half. Simply put, he is an incredible teacher. Together we plunged deep into the concept of agile software development.  You know how we Records folk like to discuss navigating the sensitive waters of the information technology mindset?  Thanks to him, my view on information technology, records best practices and project management has matured quickly.  

Also thanks to our conversations this past year, I picked up a deceptively small but extremely technical book by Chris Sterling called, “Managing Software Debt: Building for Inevitable Change”. I HIGHLY recommend it to you as a companion before you design and deploy your organization’s electronic records management system. The book focuses on how teams can take more responsibility for software and enterprise technology—“from vision to delivery and beyond. The book is for everyone who is involved in delivering and maintaining software for users.” That’s us, Records folks—and our business partners, Information Technology.

Mr. Sterling tells us that agile teams are asked to think more broadly than in terms of a single component or application when planning, implementing, and testing software features—this includes any integration with external applications.  He encourages his workshop attendees to focus on enhancing quality attributes to software, such as suitability for all end users; interoperability with other software; compliance with applicable regulatory guidelines; confidentiality, integrity, availability, accountability, and assurance; stability; operating in the event of failure; recoverability; little training required; learnability; immediate response; scalability; easy determination of how a software functions; changeability to meet business needs; testability; adaptability; installability; conformance to industry standards; and, replaceability.  Of course, the business owner is the driver. The agile software development team exists to respond, to build, to test, and to deliver.  I like that VERY much.  But, agility forgives—“we [the software development team] have to get it right the first time” doesn’t seem to exist in the agile world. I like that very much also.  In fact, collaboration across functional disciplines is one of Agile’s mantras. What other business are  we in?

Mr. Sterling identifies five types of software debt:

• Technical Debt: a team or team members choose not to do well now and will impede future development if left undone
• Quality Debt: a diminishing ability to verify the functional and technical quality of software
• Configuration Management Debt: integration and release management become more risky, complex, and error-prone
• Design Debt: the cost of adding features is increasing toward the point where it is more than the cost of writing from scratch
• Platform Experience Debt: the availability of people to work on software changes  is becoming  limited  or cost-prohibitive

The scenario and accompanying formula is straightforward. Software debt is created when the project sponsor demands a timeline must be met instead of thinking through the ramifications of their choices. Long-term vision is sacrificed for short-term payoff.  Soon, problems surface as customers use the product. This is ignored by the business team; they demand new functionality.  Software debt accrues further.  Development slows down.  Of course the business owners will ask for more resources—possibly from another service provider.  Here’s the hitch: by doing so, the business owners see a negative return on investment.  Costs are increased without any increase in delivered value because adding more resources only reduces the rate of debt accrued. It doesn’t reduce the rate of overall software debt. Meanwhile, continued development means more code…more possibility of errors…more costs to remove software debt.  The infrastructure runs a likely risk of imploding—or the software development team does. Neither party wins.

This isn’t one of Aesop’s fables. It happens to good records and information management teams all the time. But it needn’t.  Next time I’m going to break down the types of software debt against a MOSS 2007 to SharePoint 2010 migration.  Meanwhile, don’t take my word for it. Treat yourself.  Pick up a copy of Mr. Sterling's book.