The only true wisdom is in knowing you know nothing.
Socrates
What types of software products have you worked on: desktop applications, traditional web, single-page applications, embedded, mobile, mainframe?
How about organizations: private for-profit, government, non-profit?
How about domains: finance, retail, defense, health care, entertainment, banking, law enforcement, intelligence, real estate, etc. etc. etc.?
Given that the realm of “software development” is currently huge (and probably expanding as you read this), how logical is it that someone (or even a group) could regulate what is acceptable process and practice? I won’t say that it would be impossible to come up with one unified set of regulations that would fit all circumstances, but I’m very comfortable estimating the likelihood as a minute fraction of a percent. If the entire realm were broken down into smaller groupings, the chance might increase, but the resulting glut of regulations would become an administrative nightmare and still wouldn’t address those circumstances that aren’t in the list above but are on the horizon.
Nonetheless, people continue to float the idea of regulation.
Last fall, Bob Martin floated the idea of government regulation as a reaction to the healthcare.gov fiasco. That would be the same government whose contracting regulations contributed to the fiasco in the first place, correct? That would be the same government that has legally mandated Agile for Department of Defense contracts? Legally mandated agility just seems to sound a bit suspicious. As Jeff Sutherland noted “Many in Washington are still trying to figure out what exactly that means but it is a start”. A start, for sure, but the start of what?
Ken Schwaber’s blog post “Can Software Developers Meet the Need?” takes a different approach. Schwaber proposes that:
A software profession governing body is needed. We need to formalize and regulate the skills, techniques, and practices needed to build different types of software capabilities. On one side, there is the danger of squeezing the creativity out of software development by unknowledgeable bureaucrats. On the other side is the danger of the increasingly vital software our society relies on failing critically.
We can either create such a governance capability, or the governments will legislate it after a particularly disastrous failure.
Call me a cynic, but I’m betting that the amount of bureaucratic squeezing that would result from this would far outweigh any gain in quality.
Most of the organization types listed above are already on the hook for harm caused by their IT operations; just ask Target and Knight Capital (don’t ask the Centers for Medicare & Medicaid Services). Is it more likely that a committee, whether private or public, can better manage the quality of software across all the various categories listed above? Could they be more likely to keep up with change in the industry? Color me doubtful.
Form Follows Function 
The GAO Root Cause Analysis (I work at times for IDA a DOD Root Cause assessment FFRDC) will show that ACA violated several FAR procurement guidelines, not the least of which is the “past performance” qualifier section of the RFP. The vendor had been disbarred in Canada.
As well OMB requires explicit program management process through OMB Part 7, many of which were ignored.
But RCA on many of ACT1 programs we are famailar with have these 4 Root Causes (symptoms actually)
LikeLike
Indeed, however the problems were not isolated to that single vendor and CMS’s poor coordination.
All in all, the regulations tend to encourage ticking boxes (and documenting that the boxes were ticked) over actual function.
LikeLike
The FAR, Part 7 do not “encourage” ticking of boxes. The accountability of the PMs ignore their responsibility. Nothing in the procurement regs – HHS is subject to the FAR, says “tick the boxes.” This all comes to PM accountability.
LikeLike
I can’t really comment on what that particular section entails as I don’t spend time down in the weeds of Federal Regs. However, on a general basis, would you agree that the high-dollar hammers are a result of the vendor going through the certification and documentation process rather than the basic cost of the item? The vendors seem to be very good at providing what was asked for and the government seems to be pretty mediocre at figuring out what they need.
I’ve noticed that while at least one vendor has been dropped, have any been subject to a claw-back?
LikeLike
Those hammers were built to spec. The spec is the source of cost escalation. The Coffee pot on the C-5 was spec’d to fly in high G, high bank turns. How about you not get coffee when doing that.
The “figuring out” what we want is the root cause. But ACA has a myriad of other procurement issues, not the least of which was the PM(s) and there were at least 3 had zero experience in procuring things like this. The FAC-P/PM certification called out in DOD provided by DAU and other vendors (Management Concepts is one I work for), was not required.
But HHS is not the poster child for good PM. BARDA is alway in trouble with GAO for poor PM execution.
LikeLike
The question one might ask is whether the rigor around the hammers was as valuable as the rigor around the coffee pots (which obviously have non-commodity requirements to them).
LikeLike
I am no expert on US government IT procurement but appear regulations to be trying to mandate quality by defining the how rather than the what. It’s like saying a car needs to be safe by being built of certain materials rather than crashing it into a wall and observing the passengers are safe.
Thinking of software development in general, the biggest impediment to software quality is the warranty disclaimer included in any contract or EULA. Better or clearer attribution would force the industry to create its own quality standards rather than having it forced upon them.
FOSS further complicates matters, however, as they often lack centralized control, let alone the people and financial resources to compensate those impacted by issues in their software.
LikeLike
My impression is that the primary motivation (for all US government procurement) is anti-corruption – mandating that the product exactly matches the requirements provided and that there’s no graft involved in the awarding of the contract. It’s no accident that these regulations originated after the US Civil War which saw corruption in procurement of war material and other supplies on a monumental scale – many of those who had been supplied with defective clothing and inedible rations were entering politics at that time.
Long story short, the process is so optimized for those aspects that there’s not much room to allow it meet other requirements (like responding to changes/new information).
LikeLike
I think this is a tough question. I am not sure we can mandate what we can’t define but perhaps what we can do is provide standards to have the conversation. Just providing definition for words like agile or professional would be a helpful to having a more measured and rational conversation.
LikeLike
Starting at the beginning and building slowly would definitely be preferable. The biggest impediment is that it takes a lot of discipline to only mandate that which you understand and have a firm rationale for mandating. There’s a lot of pressure to “do something” even when no one is really sure what that “something” should be.
LikeLike