Of course, if the software is crap that statement would make sense, but if that is the case, you should throw the tool out rather than try to plug the holes.
Modifications form a lucrative and essential part of enterprise software, judging by what my co-workers and friends at other companies were billed out at an hourly basis (the consultant was always paid a mere fraction of the $100-$200/hr). Sometimes I wonder if paying for expensive consultants wasn't just a CYA-move by the client ("look, I hired the company to consult directly")
If you can customize the software, you can try to fit it around your company's strong points. If you can write the software from scratch, you can tailor it for your company. That's the dream, anyway.
I think the author is dead-on right: this is about a lack scrutiny and feedback.
Zawinski's Law
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can. Coined by Jamie Zawinski (who called it the Law of Software Envelopment) to express his belief that all truly useful programs experience pressure to evolve into toolkits and application platforms (the mailer thing, he says, is just a side effect of that). It is commonly cited, though with widely varying degrees of accuracy.
"Enterprise software" is a social, not technical, phenomenon
http://lists.canonical.org/pipermail/kragen-tol/2005-April/0...
You know how Fred Brooks said to "build one to throw away"? You just can't do that with Enterprise software because the businesses that use it need it to keep living.
You know all those little things you learn as you go along, and you begin to really understand the problem, and how to solve it properly? You can't do that with Enterprise software either, because everything else relies on what you choose already; and even worse, changes in the environment are coming in all the time that you must adapt to first. That's hard enough, even with a stable (if flawed) foundation to work from.
You can iteratively adapt it, but you can't iteratively improve it.
It's a problem of legacy, of network effects, of debugged/tested/working code and of something relied on so strongly that you can't afford to mess with it.
Joel says you can't improve these things. You can - but it's a research problem. "Things You Should Never Do, Part I" (rewrite code from scratch) http://www.joelonsoftware.com/articles/fog0000000069.html
It seems to me that intellectually stimulating discussion would be served better by a longer timeout.
(fortunately, the back-button and cut-and-paste circumvents this problem, but it gave me a start the first time).
At a hospital near where I live that shall remain unnamed, I found a job that seemed perfect for me on their site.
Except when I went to apply for it -- not joking -- the application was so incomprehensible and novel-long that I just gave up.
I can't imagine they got the best people with such an application process, though perhaps they got the most persistent ones, and the ones with no better prospects.
Users have no voice, but that's only part of the problem - the time it would take to evaluate New Competitor C just to cover all the unspoken requirements is prohibitive. You can be pretty confident that because they claim nice sounding features and a simple interface, that's proof that they haven't been around to gain enough of the unspoken requirements - if they had, they wouldn't have nice sounding features and a simple interface anymore. Bit of a catch 22, really.
Unspoken requirements in the Windows world are things like "... and has a web interface", "... works on a terminal server", "reports integrate into central management program X", "has an Outlook plugin", "tolerable support for user permissions", "incomprehensible massive logfile", and so on. Either things that a program which incorporates all of them will be cumbersomly big by necessity, and/or an established competitor for several years with a few versions under its belt.
