A Gentle Rant About Software Development and Installers 338
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."
Agree (Score:4, Interesting)
I frequently remark to my colleagues how bizarre it seems to me that after 50 years or so of software engineering, we're still building awful crap. If we were architects, we'd be unveiling skyscrapers built using favela techniques of plugging any old crap together, in the mud, next to a river.
There are lots of reasons, but the two big ones I'd say are time pressures (which we as programmers will never be able to resolve) and a lack of code reuse (which we can resolve). For example, the constant churn of technologies to me is simply a failure to reuse code.
I would start by trying to engineer whole classes of faults out at the language level, as has been done with buffer overflows and garbage collection.
Make static analysis much more anal, forcing the programmer to express their intent up front - static types, constraints, etc. Make the compiler a totally pedantic Nazi. Sure, it's nice to be able to hack shit up in an afternoon in Python or whatever, but then it ships, and the bugs come in, and you end up adding a pile of asserts and whatnot that should have been caught way before the product shipped.
Make unit/integration testing a mandatory part of the build, i.e. the compiler/linker refuses to link with code that hasn't been marked as tested.
If we learned to put the hard thinking and effort into designing APIs, and then reusing those same APIs across whole new classes of problem (because the language makes defining APIs is such a hassle that we'd rather not dream up new ones left and right), I think things would improve massively. Forcing the APIs to be public, but allowing the internals to be as obscure and proprietary as you like, would allow for reuse, interoperability, and hopefully improvement (by replacing particular implementations of APIs with better ones). Add a sane API mechanism for backwards compatibility, so that when you realise the API is fundamentally bad, you can or are required to implement the old API in terms of the new, and you don't just abandon people to DLL version hell. A language could provide support all of these things.
None of this would stop you from writing shitty code. But at least, to do so, you'd have to knowingly subvert the compiler in a bogus way, ignoring screeds of the compiler telling you that you and your code suck goats' balls.
Is there a patent on administering electric shocks every time there's a build error?
Re:The problem is that we still use installers... (Score:5, Interesting)
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.
Well, Oracle and SAP are THE WORST POSSIBLE (Score:5, Interesting)
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.
Re:Okay. (Score:4, Interesting)
Because RPM/DEB makes assumptions. And some of those assumptions are simply invalid for some use cases.
Ever want to install more than one copy of Apache? Maybe you want your database installed somewhere other than default because that's where your GPFS shared disks are mounted? Ok, the latter is possible with RPM, though sometimes a bit more difficult. The former was also possible, but far more painful.
Complex post-requirements? Sure, RPM handles pre-reqs okay, though not circular ones. Post-reqs? When we were switching away from RPM in 2001/2002, no.
Cross platform? No. Want to get your apps installing on Linux, AIX (ok, AIX has RPM now, but it's severely outdated), Sun, HP, and anything else that comes up? Sure, they have their own installers. With their own unique quirks and issues.
In the end, we used tarballs with a Java/C++ front-end. Far simpler. And, for enterprise software, one of the better installers. Though maybe I'm a bit biased there :-)
Re:Agree (Score:5, Interesting)
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.