 |  |  |
| Main | |
Discarded Software #1: Disturbing Trend
Mountains of Discarded Software is an essay I wrote in 1999 but never made public due I guess to feeling I needed to tow the line as a subcontractor on a Government contract or perhaps just because I had no ready forum to publish it (blogging wasn't big yet). It is posted here in four parts. After a few years of working closely with customers in the Department of Defense, I began to see a problem with the bigger picture. Immense inefficiencies had become engrained in the system despite so many good intentions and hard working people. To this day, though I am currently working on commercial software, one of the goals I am most passionate about is introducing a platform to improve budget system efficiencies across the U.S. program budget system. Even though I wrote this 6 years ago, it remains just as relevant today.
I'm sorry to spill the beans but, from what I hear, every year the software contracting industry generates tons and tons of software for the government that is scrapped! They try to use it. They have training sessions and lots of big manuals telling them to click on OK. Some of the customers smell trouble and resist from the beginning, many of them really make a big effort. But in the end, the sheer effort it takes to cram their business practices into the constrictions of the software is too much.
The software is shelved.
The story I am describing is all too familiar to our customers at the Pentagon, but it surprises me that in the world of government contractors everyone seems helpless to change this situation.
Even if the rate of shelved software is just a byproduct of progress, there is a disturbing trend of anti-customer attitude among developers. Believe it or not, many developers in the software contracting business place the blame for scrapped software on the customers. Its kind of a detached mentality where if all goes well its because of the developer, if it goes badly its because the customer wouldn't listen! Yet it's the customer that is responsible for keeping up with his or her work responsibilities in addition to the challenges of using the new software. I completely disagree with placing any blame on the customer.
Another angle on this is the resignation many developers feel to a contracting system that they characterize as not allowing them to produce the best software possible. It can be over-regulation, the backwardness, the lack of funding. So either way the blame lies elsewhere, either with the customers or the system... This can be an excuse for a lack of ability to reach beyond standard software design ideas. It's a way of saying that the customer does not fit the software solution and its someone else's fault.
I haven't got a grand solution or anything, but I do want to make some small suggestions. The developers consist of designers, programmers, and analysts. Each part of the development team is critical. It seems like we have a disconnect between the development team and the customers. The customers are busy trying to do their work the way they currently do it. The developers are trying to create software solutions the way they are used to doing it. The weak link is in bridging that gap between what the customers are doing and what technology would make it easier within the developer's know-how.
The next part of this series is called "How Standard Practice Fails."
| Main | |
