Posts Tagged ‘uTest’
How to Break the Vicious Cycle of Technical Debt
The dire consequences of the pressure to quickly deliver more functions and features to the market have been described in detail in various posts in this blog (see, for example, Toxic Code). Relentless pressure forces the development team to take technical debt. The very same pressure stands in the way of paying back the debt in a timely manner. The accrued technical debt reduces the velocity of the development team. Reduced development velocity leads to increased pressure to deliver, which leads to taking additional technical debt, which… It is a vicious cycle that is extremely difficult to break.
Figure 1: The Vicious Cycle of Technical Debt
The post Using Credit Limits to Constrain “Development on Margin” proposed a way of coping with the vicious cycle of technical debt – placing a limit on the amount of technical debt a development team is allowed to accrue. Such a limit addresses the demand side of the software development process. Once a team reaches the pre-determined technical debt limit (such as $3 per line of code) it cannot continue piling on new functions and features. It must attend to reducing the technical debt.
A complementary measure can be applied to the supply side of the software development process. For example, one can dynamically augment the team by drawing upon on-demand testing. uTest‘s recent announcement about securing Series C financing explains the rationale for the on-demand paradigm:
“The whole ‘appification’ of software platforms, whether it’s for social platforms like Facebook or mobile platforms like the iPhone or Android or Palm, or even just Web apps, creates a dramatically more complex user-testing matrix for software publishers, which could mean media companies, retailers, enterprise software companies,” says Wienbar. “Anybody who has to interact with consumers needs a service to help with that testing. You can’t cover that whole matrix with your in-house test team.”
Likewise, on-demand development can augment the development team whenever the capacity of the in-house team is insufficient to satisfy demand. IMHO it is only a matter of little time till marketplaces for on-demand development will evolve. All the necessary ‘ingredients’ for so doing – Agile, Cloud, Mobile and Social – are readily available. It is merely a matter of putting them together to offer on-demand development as a commercial service.
Whether you do on-demand testing, on-demand development or both, you will soon be able to address the supply side of software development in a flexible and cost-effective manner. Between curtailing demand through technical debt limits and expanding supply through on-demand testing/development, you will be better able to cope with the relentless pressure to deliver more and quicker than the capacity of your team allows.
‘Super-Fresh’ Code
Source: http://www.flickr.com/photos/21560098@N06/3636921327/
Misty Belardo published a great post/video clip on Social Media in which she describe the effect of the ‘Super-Fresh’ web on brands:
… millions of people are creating content for the social web… the next 3 billion consumers will access the Internet from a mobile device. Imagine what that means for bad customer experiences! The ‘super-fresh’ web will force brands to engage with its customers…
I would contend we are also going to experience ‘Super-Fresh’ code in not too long a time. Such code is likely to emerge as the convergence of two overarching trends:
- Continuous Integration –> Continuous Deployment –> ‘Super Fresh’ Code. Sophisticated companies are already translating velocity in dev to competitive advantage through Continuous Deployment. ‘Super-fresh’ code is a natural next step.
- Open-sourcing –> Crowd-sourcing –> Expert-sourcing. Marketplaces for knowledge work expertise are becoming both effective and efficient. For example, uTest indicates “… 25,000+ testers in more than 160 countries.” A marketplace for mobile application developers could probably be organized along fairly similar lines.
No doubt, complex software systems of various kinds will continue to be produced through more conventional processes for many years to come. However, ‘Super-Fresh’ code will establish itself as a new category. Code in this category will owe its robustness (and creativity!) to millions of people creating software and fixing it in extremely short time, not to process rigor.
In case you are still wondering about the premise, I would like to point out two corroborative facts:
- It is a small step from content to code.
- Various mobile applications are already developed and tested today in a different manner from the way web applications have been done.
A fascinating link exists between ‘Super-Fresh’ web and ‘Super-Fresh’ code. The dynamics (“Imagine what that means for bad customer experiences!”) Misty discusses in her blog post are a major driver for the evolution of knowledge work marketplaces and for the production of ‘Super-Fresh’ code.
Extending the Scope of The Agile Executive
For the past 18 months Michael Cote and I focused The Agile Executive on software methods, processes and governance. Occasional posts on cloud computing and devops have been supplementary in nature. Structural changes in the industry have generally been left to be covered by other blogs (e.g. Cote’s Redmonk blog).
We have recently reached the conclusion that The Agile Executive needs to cover structural changes in order to give a forward-looking view to its readers. Two reasons drove us to this conclusion:
- The rise of software testing as a service. The importance of this trend was summarized in Israel’s recent Cutter blog post “Changing Playing Fields“:
Consider companies like BrowserMob (acquired earlier this month by NeuStar), Feedback Army, Mob4Hire, uTest (partnered with SOASTA a few months ago), XBOSoft and others. These companies combine web and cloud economics with the effectiveness and efficiency of crowdsourcing. By so doing, they change the playing fields of software delivery…
- The rise of devops. The line between dev and ops, or at least between dev and web ops, is becoming fuzzier and fuzzier.
As monolithic software development and delivery processes get deconstructed, the structural changes affect methods, processes and governance alike. Hence, discussion of Agile topics in this blog will not be complete without devoting a certain amount of “real estate” to these two changes (software testing as a service and devops) and others that are no doubt forthcoming. For example, it is a small step from testing as a service to development as a service in the true sense of the word – through crowdsourcing, not through outsourcing.
I asked a few friends to help me cover forthcoming structural changes that are relevant to Agile. Their thoughts will be captured through either guest posts or interviews. In these posts/interviews we will explore topics for their own sake. We will connect the dots back to Agile by referencing these posts/interviews in the various posts devoted to Agile. Needless to say, Agile posts will continue to constitute the vast majority of posts in this blog.
We will start the next week with a guest post by Peter McGarahan and an interview with Annie Shum. Stay tuned…
Round Two: Can Technical Debt Constitute a Breach of Implied Warranties?
In a previous post I discussed whether technical debt could under some conditions constitute a breach of implied warranties. Examining the subject with respect to intent, I made the following observation:
It is a little tricky (though not impossible – see Using Credit limits to Constrain Development on Margin) to define the precise point where technical debt becomes “unmanaged.” One needs to walk a fine line between technical/methodical incompetence and resource availability to determine technical fraud. For example, if your code has 35% coverage, is it or is not unmanaged? Does the answer to this question change if your cyclomatic complexity per class exceeds 30? I would think the courts might be divided for a very long time on the question when does hidden technical debt represent a fraudulent misrepresentation.
One component of technical debt deserves special attention in the context of this post. I am referring to the conscious decision not to do unit testing at all… Such a conscious decision IMHO indicates no intention to pay back this category of technical debt – unit test coverage. It is therefore quite incompatible with the nature of an implied warranty:
Responses to my post were mixed. Various readers who are much more knowledgeable in the law than I am pointed out various legal defenses a software vendor could use. Click here for a deeper understanding of these subtle legal points.
Imagine my delight reading yesterday’s uTest interview with Cem Kaner. Cem makes the following statement in his interview:
ALI [American Law Institute] … started writing the Principles of the Law of Software Contracts. One of its most important rules is one that I advocated: a seller of software who knows about a defect of the software but does not disclose the defect to the customer will be held liable for damages caused to that customer by that defect. Note that this does not apply to free software (not sold). And if the seller discloses the defect, it becomes part of the product’s specification (it’s a feature). And if the seller doesn’t know about the defect there is no liability (once customers tell you about a defect, you have knowledge, so you cannot avoid knowledge for long by not testing). ALI adopted it unanimously last year. This is not law, but until the legislatures pass statutes, the Principles will be an important guide for judges. Even though I am a minor contributor to this work, I think the defect-disclosure requirement might be my career’s most important contribution to software quality. [Highlights by IG].
While not (yet?) a law, the Principles could indeed lead us where IMHO we as an industry should be. Technical debt manifests itself as bugs. By making the specific bugs part of the spec the software evolves from a quality standpoint. Moreover, the defect-disclosure requirement practically force software vendors to address their bugs within a “reasonable” amount of time. Customer bugs become an antidote to the relentless pressure to add functions and features without paying due attention to software quality.
I guess I missed the opportunity to include technical debt in the 2010 revision of the Principles. As we always do in software, I will target the next rev…
The Agile Executive 