Saturday, August 3, 2013

Why Government software projects go wrong - Part 2

Last time I mentioned the problems that are caused by governments in government projects.  What about the other side - the ISVs.  It turns out that they aren't entirely blameless.

Bean-counter Effect

As I said previously, government work is very risky for small ISVs so much of the space is dominated by large ISVs.  Large ISVs exist in a space where they are controlled by the bean counters.  I really want to emphasize that certain changes in corporate culture are necessary as the company grows but this one is very detrimental.

The bean-counter effect is treating employees like interchangeable cogs in terms of service delivery.  Two software engineers with 5 years of experience are completely equal as far as they care, even though that is provably false.  To them, a team of 2 top-notch performers earning $100K/year is worse than a team of 3 middling performers earning $60K/year.  Switching to the latter means saving $20K/year in payroll and an increased their ability to bill out clients.  After all, the clients still pay the same rate for the best and the worst.  In the end, the ISV has a perverse incentive to employ low-skill, but highly profitable, developers which end up dragging out the project.  Needless to say this is very bad for the client.

Sales over Quality

Many ISVs will offer to "customize" their current solution to meet the client's needs.  Here's the dirty little secret of programming.  All software platforms represent a trade-off, by optimizing to do things well, like geo-spatial analysis, they will do other things much worse, like community interaction.  The only way to counter-act this is to be equally good at doing everything, however, this ends up with a platform which is equally bad at everything.

In the best case, the existing solution is close to what the client needs.  In this case, the client is well served by re-using an existing solution.  However, in many cases Sales will try to make a purse out of a pig's ear (after all, it's their job).  In cases such as turning a geospatial platform into a social networking system, it ends up being worse than starting over from scratch.  However, the perverse incentive is that many clients won't, or can't, pay for a proper custom solutions.  So, "customizing" an existing system, no matter how much code has to be written or discarded to make it fit, is better than starting fresh with a targeted solution.

Fear of Change

"We can't develop a new version because it would offend our current clients."

Many agencies are so paralyzed with fear of change that they refuse to analyze new technology.  Part of being an ISV is reviewing all the new technologies that come out and determine if they meet the needs of their clients.  After all, clients generally won't have the needed expertise in-house, it's why they hire ISVs.

What this means is that most of these organizations will adopt very stale technologies and use them as the basis for new projects.  This can be caused either by the ISV deciding its investment in the technology is too large to change or by the fear that clients won't be interested in a new system.  What this means, is that clients end up with systems which are expensive to support and nearing a very sharp end of life.

In addition to the old technologies, these large ISVs will maintain old software development techniques and practices.  Waterfall, big-design upfront and The Methodology is often used to attempt to produce a quality result.  By staying behind the curve on modern software development practices these ISVs think they're being consistent but all they're doing is harming the client.


In the end, I don't think anyone at the ISV is deliberately trying to do a bad job.  They are doing their best, but I believe their incentives don't line up to produce amazing software.  Rather, they're incentivized to produce software which has the right superficial features, of which sadly, "Great" is not on the list.