A Businessman's View

(Originally published at www.servicevirtualization.com .) In Part 1 , I proposed that application release decisions are not actually time-based but are instead risk-based.  To summarize, when the Lines of Business demand a specific time to release (from project inception) the Project Lead considers the risk to the business of releasing the application at that time.  This is illustrated to the right. Application Development Constraints Let's take a quick look at the "risks to the risk."  These are also known as constraints of the application development process.  I'll start by describing them as they are defined in the book Reality is Overrated (link goes to Amazon). Incomplete Development refers to the fact that software that a developer requires to validate their own code production is unavailable, requiring that developer to stub downstream systems.  The net result is that testing coverage early on is very sparse and puts the onus on the Quality As...

(Originally published at www.servicevirtualization.com .) After my recent webinar (entitled Agile is Dead , replay is here , registration required but is free) I was having a follow up discussion with someone about it when the discussion turned to the nuances between what Agile actually promised and what people perceived it was supposed to deliver.  From my perspective, the simplest explanation is that Agile promised to help ensure that business requirements were being met while people thought it meant that applications would be produced with far fewer defects.  In the webinar, I described how Agile, if anything, increased the total number of defects due to its attempt to be more adjustable to the needs of the business mid-implementation. The question was then asked:  are software defects inevitable?  If not then why do they exist?  We're not talking about an insignificant problem.  As I've often quoted, NIST produced a study in 2002 that illustrated a ...