Slashdot Mirror
A Gentle Rant About Software Development and Installers
Nerval's Lobster writes "This is the story of the comparison that just wasn't meant to be. It's a story of everything that can go wrong in the customer end of the software world, and some thoughts on what needs to be done, especially in an area known as Installers. I'm a software engineer with 25 years of experience, and for years I've wanted to point out some of the shortcomings of my own industry to help make it better for everyone involved—not only for the end-users, but also for the IT people who have to support the products; the salespeople who have to sell and later, possibly, apologize for the software; for the executives whose hands are tied because they don't have the technical knowledge to roll up their sleeves and help fix problems in the code; and for the programmers themselves who might get stuck with what some consider the absolute worst position for a programmer: maintenance of crappy code written by programmers who have long since left the organization."
This is enterprise software; it's a much bigger problem than that. You're not installing "a single app", you're typically installing an entire software stack. LAMP is just the beginning.
From TFA:
The past 20 years have seen us escaped Windows and DLL hell by moving to Linux. Then, we escaped its own little twisted maze of dependency hell by using apt-get. Then, we used all those open source tools to build ... the infrastructure that was then used by the closed-source community. In the case of the SAP product, it comes with Tomcat as a web server. In the case of the Oracle .OVA installation, an entirely preconfigured Linux install that probably comes with its own separate stack. If you keep them all on separate VMs, you've got a shot at getting them to talk to each other, but is that really the best use of the underlying hardware? One bit of Java talking to some other abstracted piece of Java, using dozens of VMs as intermediate layers of abstraction?
And now we're right back where we started. SAP will support this revision of Tomcat which works with this version of Java, because, well, that's the Java way. And Oracle appears to have solved that problem by throwing down a .OVA for every subcomponent.
Web services are a great way to save developer time - but in return for that, they're yet another layer of abstraction that has to be dealt with. Virtualization's a great way to save administrator time. Rather than having to separately install "the right version" of the entire stack from the OS to Java to the configuration properties of the web server, just grab the .ova and work from there. It also gives you some scalability that you might not have had - fire up the .ova on your PC for a demo, or on bigger iron for production.
But in exchange for the ability to get crap out the door ("it works on my machine / Great! Virtualize it and your machine's now the installer!") faster, we've merely exchanged one dependency tree for another: instead of kilobyte-sized .DLLs or megabyte-sized repositories of source from which we can rebuild our binaries, we're now dealing with gigabyte-sized VMs.
It's hard for me to think of any software companies that are worse at creating software that actually WORKS.
SAP and Oracle are notorious for pushing out incredibly expensive, complex products that are impossible to install and generally don't work like ANYTHING else.
SAP, especially, seems to be incapable of releasing a product without a half-dozen show-stopping bugs that require obscure workarounds that you'll only find out about by calling support. I won't even talk about the unholy mess that is SAP's support site.
There's a rule about software that people often forget, and it's this:
"Software quality is inversely proportional to cost". In other words, the more expensive a given piece of software is, the crappier it is. Oracle and SAP are the NUMBER ONE offenders in this regard.
All of this assumes that the vendor *wants* it to improve. TFA shows that where there's an incentive for good installers, they get written. MySQL installs in a snap. Mainstream open source software installs on Linux in an apt-get/yum/whatever one-liner.
Now look at Oracle DB -- one of TFA's examples of "bad". The people who specify Oracle are seldom the people who will be installing it; or if they are, they're people who've done Oracle training and are charging by the hour for Oracle consultancy.
Lots of people *benefit* from Oracle being a dog to install. Consultants, as above. Staffers who get to put down a week's timesheets for "Oracle installation and configuration". Oracle themselves, because for certain decision making managers, "serious" software is difficult to install -- if you can install it in 20 minutes it must be a toy; and because they can sell books / training / certification.
There's a lot of people who would lose out on profitable (but wasteful) activity if enterprise software was easier to install.