×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

A Gentle Rant About Software Development and Installers

samzenpus posted about a year ago | from the listen-up dept.

Open Source 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."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

338 comments

Put everything in the cloud! (5, Funny)

Anonymous Coward | about a year ago | (#42094131)

Problem solved. I will come by later to pick up my consulting fee.

Okay. (0)

Anonymous Coward | about a year ago | (#42094141)

Why not package enterprise-grade software into InstallShield or RPM/DEB packages like every other piece of end-user software?

Re:Okay. (4, Informative)

Giant Electronic Bra (1229876) | about a year ago | (#42094265)

Because most Enterprise software (and I manage a product line which is definitely in this category) isn't something so simple that you can install it with RPM or Installshield (or whatever the heck MS calls it now). There are multiple interacting services, very specific dependencies for things that are often not packaged at all for the target platform and usually cannot be distributed, etc. Complex databases, usually on other machines, have to be set up, XML files edited, etc to even create a basic working environment for our software. Now, MOST things might not be quite this complicated, but I suspect most software that you have to install largely by hand has many of these kinds of issues. Most of this stuff has to integrate fairly deeply with the client's IT infrastructure and setting up the basic applications is only a small part of it.

In our case we have some installers for some specific tools, but the main product? No, it wouldn't materially assist in setup and would just be yet another task to maintain when some tarballs/zips, thorough instructions, and heavy tech support works fine. You're already typically paying from 10's to 100's of K up front and 1000's a month to even run real Enterprise class software anyway. Surprisingly installer tech that was designed around simple desktop apps is just not that helpful. Our installer is a guy that shows up at you office, lol.

Re:Okay. (5, Insightful)

sribe (304414) | about a year ago | (#42094309)

Bullshit. There's not one thing in your list that cannot be handled with an installer. You just don't care to automate the process, and are making up excuses to justify that after the fact.

Re:Okay. (5, Insightful)

GoatCheez (1226876) | about a year ago | (#42094373)

I agree. By thinking about installation when creating complex enterprise software, you end up making better quality software. When you're forced to handle the inter-dependencies of complex systems in an installation process, you end up having a better handle on how everything interacts. This has been my experience at least.

Re:Okay. (2, Insightful)

Anonymous Coward | about a year ago | (#42094581)

Mine too, but it never works that way.

The last thing that gets thought about is dependencies - this is also one of the reasons Android software acquires permissions but rarely relinquishes them. We only know how to grow software, once it starts working the "Job is done, go home".

Re:Okay. (4, Insightful)

sribe (304414) | about a year ago | (#42094811)

I agree. By thinking about installation when creating complex enterprise software, you end up making better quality software. When you're forced to handle the inter-dependencies of complex systems in an installation process, you end up having a better handle on how everything interacts. This has been my experience at least.

Absolutely true. I didn't even bother going there in my response, because I figured it was pointless when someone was actually claiming "enterprizey software is simply too complex for installers". Sigh. As usual, the creators of the problems are blind to the problems...

Re:Okay. (0)

Anonymous Coward | about a year ago | (#42094729)

You can make an installer that can predict & solve DLL version conflicts without breaking the other applications that depend on them?

Re:Okay. (1)

jythie (914043) | about a year ago | (#42094813)

What installer can set up databases on other machines?

Re:Okay. (1)

sribe (304414) | about a year ago | (#42094881)

What installer can set up databases on other machines?

They can all run scripts. Just because there's not a checkbox labeled "set up our database on the other machine" doesn't mean it can't be done--at least if you're not a lazy bastard.

Or, the easier approach, an installer for each part on each machine. There's really not an excuse for not considering that.

Re:Okay. (1)

vlm (69642) | about a year ago | (#42094337)

Our installer is a guy that shows up at you office, lol.

That combined with your username is the real LOL.

Re:Okay. (0)

war4peace (1628283) | about a year ago | (#42094753)

Then make your own god-damn installer.
You can handle "interacting services" gracefully; you can check for dependencies and resolve them directly from within the installer, and as for "XML files edited", please, even I, as a total installer noob, can write code to parse a damn XML and put whatever values need to be in there.
I tell you why you don't bother building or configuring an installer: so that you can charge your customers money for the product installation too. And big money, that is, under the umbrella that "it's a complex thing".

Re:Okay. (2)

jythie (914043) | about a year ago | (#42094841)

I suspect the complexity is not in being able to parse and alter XML files, but what level of human knowledge is necessary for determining what values to put in them.

Re:Okay. (0)

Anonymous Coward | about a year ago | (#42094789)

That's right. The company is indeed paying hundreds of thousands or even millions of dollars to run your software. The least you can do is make a decent installer. If that installer is a guy that shows up at the office, fine, but then your "free trial" version is not going to be very effective unless the guy shows up for those users too.

I tolerate difficult installation processes for free software because it's usually free-as-in-beer, which means the developers probably have no budget for anything beyond developing (if that). That is not the case for Oracle and SAP.

Re:Okay. (3, Interesting)

Tanktalus (794810) | about a year ago | (#42094435)

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:Okay. (1)

hawkinspeter (831501) | about a year ago | (#42094527)

Why would you want to install more than one copy of Apache? I could understand wanting to run multiple instances if you can't configure the virtual servers correctly, but I don't understand multiple copies.

If you wanted to test different versions, you'd be better off using multiple virtual machines - that way you don't have trouble with one version of Apache requiring different libraries than another one.

Re:Okay. (2)

Electricity Likes Me (1098643) | about a year ago | (#42094597)

Virtual machines have a performance hit, require permissions, and don't reflect native hardware. Fine for Apache, but what about something like a file manager, or anything which requires OpenGL currently?

Admittedly there's progress on this front - LXC in the Linux kernel goes some of the way to fixing this problem, though what we really need is a distribution that's LXC aware so it's easy to use.

Re:Okay. (1)

sgbett (739519) | about a year ago | (#42094735)

I assume he meant virtual *hosts*, which is fair enough, though vhosts arent necessarily the answer to everything.

If you had two physical interfaces to a machine then its not a stretch to suggest you might want to glom an instance of httpd onto each.

Re:Okay. (1)

hawkinspeter (831501) | about a year ago | (#42094807)

I actually meant virtual machines. Virtual hosts won't allow you to use different versions of Apache (as far as I know), but will get round the need for multiple instances of Apache. You don't even need multiple instances of Apache for dealing with multiple network cards, let alone multiple installs of Apache.

Re:Okay. (1)

hawkinspeter (831501) | about a year ago | (#42094779)

I still don't see why you'd need multiple copies of the same software installed, even if they do use OpenGL. If you need them for testing variances between versions, then you're better off taking the performance hit of virtualising the machines.

Re:Okay. (0)

Anonymous Coward | about a year ago | (#42094791)

If you wanted to test different versions, you'd be better off using multiple virtual machines - that way you don't have trouble with one version of Apache requiring different libraries than another one.

Why do with a virtual machine what can be done with separate users/directories? Some of us remember unix before package management and can actually manage multiple versions of the same software safely on the same server. Lazy and/or incompetent sysadmins I tell you...Virtual machines just add more usually unneeded complexity to a system.

Installers? (1)

Anonymous Coward | about a year ago | (#42094157)

apt-get and checkinstall.
Do we need anything else?

Re:Installers? (1)

vlm (69642) | about a year ago | (#42094349)

puppet to automate it.

package { "wtf" : ensure => latest }

Re:Installers? (0)

Anonymous Coward | about a year ago | (#42094803)

You made a typo. I think you meant Chef? It's okay, a lot of people make a similar typo. :D

It's the submitter's fault. (1)

mcgrew (92797) | about a year ago | (#42094181)

Not as a user, the guy has been writing software for 20 years and complains about poor design and bugs? Nerval's Lobster should clean up his own house.

I finally found a system log from the installation. There were a whole bunch of exception errors, but no explanation of the exception, what caused it, whether the installer took care of the problem, and if there was anything I should do to fix it. Yet the installer claimed everything had installed correctly.

I wonder how the UNIX SAP software fared; Windows is not a robust OS. Flaky hardware will make Windows and its software crash every time, while apps running Linux on the same flaky machine work fine, as I've seen on two different occasions.

Part of the problem is the tools. A poor workman always blames his tools, but a good workman doesn't use faulty tools. The tools I'm talking about are compilers, 3rd party installers, and OSes.

There really is no excuse for today's shoddy software. Why should an automobile last longer than an OS?

Re:It's the submitter's fault. (0)

Anonymous Coward | about a year ago | (#42094243)

Why should an automobile last longer than an OS?

Because it is a profitable business model.

Re:It's the submitter's fault. (3, Insightful)

war4peace (1628283) | about a year ago | (#42094809)

Why should an automobile last longer than an OS?

That has no longer been valid since post-'95. An OS lasts just as long as an automobile, if you consider all the variables. If the infrastructure doesn't change, an OS would last forever. But infrastructure (read hardware support, network support, etc) does change, and rapidly. Your own automobile would be good for nothing if, for example, current roads would be replaced by magnetic field monorails.

Re:It's the submitter's fault. (1)

Kielistic (1273232) | about a year ago | (#42094843)

Why should an automobile last longer than an OS?

If you don't pay for regular maintenance (which costs more per year than a single OS license) I think you will find that your automobile will not last longer than an OS.

Re:It's the submitter's fault. (1)

Megane (129182) | about a year ago | (#42094873)

Not as a user, the guy has been writing software for 20 years and complains about poor design and bugs? Nerval's Lobster should clean up his own house.

Pay more attention to what you are complaining about. NL is just the guy who crossposts stuff over from SlashBI. (He used to submit a lot of not-news-for-nerds crap that never got posted, but seems to have gotten a lot better in the past few weeks.) The guy you are complaining about is in the linked article.

no installers wanted (0)

oever (233119) | about a year ago | (#42094187)

There should not be any installers. A software package should be one file that is download and run. The file should not be unpacked, it should simple be one executable with all necessary parts inside.

Any software that is not simple a single file is complex and brittle.

Re:no installers wanted (0)

Anonymous Coward | about a year ago | (#42094263)

We had that, then they invented fixed disks and shared libraries.

Re:no installers wanted (1)

cfulton (543949) | about a year ago | (#42094323)

Well yes, theoretically I would agree. But, then that damn reality pokes its ugly head in and things are more complicated than we want them to be. Enterprise software, especially web based applications often cannot be packaged as a single file. Companies often want the database to run on their existing Oracle (or whatever) install, which means scripts to build out the tables in their database. There are often existing APIs that need to be called that are custom to the client. That means that after the install you will need to add code to make API calls that the standard install does not necessarily make. Many companies have existing web server farms that they want to run the application on so it will have to be deployed to each of the existing servers or they want to separate the static content from the dynamic. There are a million and one reasons that your simplistic view of the world cannot be achieved in the real world.

Bespoke development of a plug-in for each client (1)

tepples (727027) | about a year ago | (#42094707)

Companies often want the database to run on their existing Oracle (or whatever) install, which means scripts to build out the tables in their database.

Is there a reason the installer can't have a button to execute these CREATE TABLE IF NOT EXISTS scripts in a given database? The installers for phpBB, MediaWiki, WordPress, and the like have this.

There are often existing APIs that need to be called that are custom to the client. That means that after the install you will need to add code to make API calls that the standard install does not necessarily make.

Now you're getting somewhere by mentioning the requirement of bespoke development of a plug-in for each client.

Re:no installers wanted (1)

TheDarkMaster (1292526) | about a year ago | (#42094421)

Well, you can make a good installer and not every software is simple and/or small enough to use a "all-in-one" executable. The problem is finding qualified people for the job.

Re:no installers wanted (1)

somersault (912633) | about a year ago | (#42094445)

Define "necessary parts".

We have a lot of storage space these days, but I don't think every piece of software basically having their own /usr/lib or /windows directory is feasible yet.

Re:no installers wanted (1)

hawkinspeter (831501) | about a year ago | (#42094545)

That sounds like a backwards move to me. Usually, you want config files to be in a separate place than your binaries. What about shared libraries? Do you recommend statically linking everything?

Re:no installers wanted (1)

Anonymous Coward | about a year ago | (#42094695)

A software package should be one file that is download and run. The file should not be unpacked, it should simple be one executable with all necessary parts inside.

Total and utter crap.

Just a few of many reasons why:
Many more complex packages (which is what we are talking about) need background services (often smallish executables with different elevated privileges required). They also have a huge gui front end which can run at normal user privilege level. From the security and efficiency point of view, only a total moron would combine these into one executable.
Many packages have to modify system configuration items (systemwide config files, registry, whatever, depending on OS). The modifications *cannot* be packaged as part of a single executable (does not even make sense).
Nearly all packages have their own private configuration items (default config files or whatever). Having data files like these incorporated into an executable is totally barking from the security point of view - executables should (almost) never be self-modifying; they should sit in protected non-modifiable storage.
Many complex packages have multiple components of which a typical install only requires a subset. Installing the unnecessary components because they are all packed in a single executable is idiotic, it introduces extra potential security holes.
I could go on like this all day but it should be clear by now that packaging *complex* products as a single executable is one of the stupidest ideas ever suggested on slashdot.

Security updates to a "necessary part" (1)

tepples (727027) | about a year ago | (#42094745)

The file should not be unpacked, it should simple be one executable with all necessary parts inside.

So what happens when a security vulnerability is discovered in one of these "necessary parts" statically linked into the executable? If the part lives in its own package on which your package depends, a fix for this vulnerability is applied for all applications using the part once the part's maintainer releases the fix. Otherwise, you have to wait for the maintainer to update the application with the fix, and $DEITY help you if the maintainer has pronounced the application's end of life.

Re:no installers wanted (1)

war4peace (1628283) | about a year ago | (#42094831)

I would watch with interest when that single-file Database you're using messes up for good, completely, because that single-file was deleted by mistake. Tee hee. Or when it got corrupted by power loss, etc.

Re:no installers wanted (1)

Half-pint HAL (718102) | about a year ago | (#42094863)

There should not be any installers. A software package should be one file that is download and run. The file should not be unpacked, it should simple be one executable with all necessary parts inside.

Any software that is not simple a single file is complex and brittle.

Do we have to include the whole operating environment in the file, even eliminating BIOS? Because all modern software builds on external functions and libraries, even on a game console. Heck, even the cartridges for the original Nintendo relied on firmware inside the console to some extent....

Why even use installers... (0)

Anonymous Coward | about a year ago | (#42094193)

...when there are package managers?

Re:Why even use installers... (1)

J_Darnley (918721) | about a year ago | (#42094607)

Because they're better. With package manager it is usually "use this old version" or "compile from source". On occasion you get the rare third option of "add this repository of compiled binaries to your package manager" which is no different to downloading a random installer.

Reusing existing apt-get (1)

tepples (727027) | about a year ago | (#42094761)

On occasion you get the rare third option of "add this repository of compiled binaries to your package manager" which is no different to downloading a random installer.

With one big difference: adding a repository allows the existing package manager to check for and apply updates instead of adding Yet Another Daemon to do this.

big bucks (1)

roman_mir (125474) | about a year ago | (#42094195)

There has to be a correlation between the price tag on these BI tools and the difficulty of installation, you are just not meant to install it, you are a simple mortal, not a SAP or Oracle certified 'specialist'. By getting those certifications you immediately acquire special knowledge of how it really works. You don't need to click on those seven icons or whatever and you don't actually need to download those GB packages. That stuff is made to look Enterprisy, it's for chumps. Actually SAP is just a few lines of code in your BIOS and Oracle is built into every computer that you buy by default. All you need to do is to have a special key that you hold to the machine at a specific coordinate point near the processor and everything starts working as if it is magic. The 2GB files and the 7 Icons really serve as a decoy, gate keepers, for those with true knowledge can pass the test and the rest will have to pay the ones with the true knowledge whatever the going rates are.

My software OTOH is very simple, I even provide a shell script for installation, and if something doesn't work you can see right in the script which library didn't download or something similarly elementary. The applications themselves are just WAR and JAR files drop them into the configured server and BAM.

Re:big bucks (0)

Anonymous Coward | about a year ago | (#42094253)

The applications themselves are just WAR and JAR files drop them into the configured server and BAM

What?! The server explodes? I'm surprised you continue your nefarious business practices, don't you have any shame?

The problem is that we still use installers... (3, Insightful)

gestalt_n_pepper (991155) | about a year ago | (#42094219)

Instead of creating single exe. Memory and disk space are cheap. Portable application creators are easily and cheaply available (e.g. Cameyo.com - both free and excellent at what it does). It's easier to copy a single file than to go through the hell that is installation for most apps.

Re:The problem is that we still use installers... (4, Interesting)

Tackhead (54550) | about a year ago | (#42094319)

Instead of creating single exe.

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:

Except it didn't really install correctly. One of the servers just wouldn't start up, and gave me no indication whatsoever the problem was. Another serverâ"the Tomcat web server that hosts the user interfaceâ"started up fine, so I was able to get to a login screen through the Web browser.

... Oracle provides a pre-built Linux image with all of the necessary business-intelligence tools already installed, running inside Oracle VirtualBox. "What could be easier?" were my famous last words.

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.

Re:The problem is that we still use installers... (1)

Anonymous Coward | about a year ago | (#42094385)

It sounds like you're saying that Java is 100% of the problem here.

Re:The problem is that we still use installers... (1)

marcello_dl (667940) | about a year ago | (#42094423)

But then you depend on the software vendor to fix bugs or worse vulnerabilities in libraries used by the program that you otherwise would update separately.

It would be feasible to provide static packages in FOSS, though. Gobolinux and its rootless mode are one approach alternative to the monolythic package.

How much more disk is static linking anyway? (1)

swb (14022) | about a year ago | (#42094495)

I remember being kind of annoying in the early 90s when I started using Windows and had to deal with Installers; as a Mac user, I was always used to just copying applications from system to system (although IIRC, some set resource values during install or copied INITs to the System folder).

A couple of software developers told me DLLs were better technically due to resource usage, but to me it just seemed like a clunky form of copy protection.

I kind of felt the same way on Linux/BSD platforms -- why couldn't everything be compiled statically? How much more disk space would it REALLY take to have an entire system statically linked?

I still think this would be a good idea on Windows, even though DLL conflicts seem to not occur that often.

Re:The problem is that we still use installers... (1)

Zadaz (950521) | about a year ago | (#42094739)

DRM. I love to keep installs as simple as possible. Every program should be able to be run on removable media. But back when I had a little less control over the software I develop, clients were horrified by such an idea. They wanted applications locked to a specific machine, permanently, if possible. If they would have known the lingo they would have asked for rootkits and BIOS viruses to keep their app from running anywhere it wasn't supposed to. (They would have gone with hardware dongles, but they were far too cheep for that.)

And to do that (Without hardware dongles) you have to get stupid. Insinuate files into places they're not supposed to be and generally just dick with a person's computer in a way that would make them unhappy if it wasn't hidden by a shiny graphic on the installer's splash screen.

You can understand why I don't do that work anymore, but I guarantee that someone does.

Maintenance Isn't a Bad Job (5, Insightful)

Greyfox (87712) | about a year ago | (#42094225)

As long as you can incrementally improve the design and code, maintenance isn't a bad position to be in. I've seen far too many programmers who whine and whine about how much the code base sucks, but they never do anything to make it better. They insist that the only way to go forward is to rewrite the whole thing, a project that is almost inevitably doomed to failure. If you actually design new code, implement policies if the company doesn't have any in place, and clean up the old code while you're hunting bugs, it can be every bit as rewarding as new development. ANY programming project can be a joy to work on, or a nightmare to work on, and it's entirely the discipline and ability of the team and its management that makes all the difference.

Re:Maintenance Isn't a Bad Job (2, Insightful)

Anonymous Coward | about a year ago | (#42094299)

That's because those programmers are not professionals but basically code churning prima donnas. They like to write new code and move on rather than do boring things like bug fixing and other maintenance tasks. The GNOME project epitomizes this attitude in spades.

Re:Maintenance Isn't a Bad Job (1)

Anonymous Coward | about a year ago | (#42094327)

As long as you can incrementally improve the design and code, maintenance isn't a bad position to be in. I've seen far too many programmers who whine and whine about how much the code base sucks, but they never do anything to make it better. They insist that the only way to go forward is to rewrite the whole thing, a project that is almost inevitably doomed to failure. If you actually design new code, implement policies if the company doesn't have any in place, and clean up the old code while you're hunting bugs, it can be every bit as rewarding as new development. ANY programming project can be a joy to work on, or a nightmare to work on, and it's entirely the discipline and ability of the team and its management that makes all the difference.

The real problem is that for the most part the system they rewrote would probably have all the same disadvantages as the current one; they keyword in your statement is "improve the design". A lot of programmers are kinda lousy. And a lot of orgs still reward seniority as well or better than they reward skill/performance. This is a recipe for disaster, since as soon as your talent pool starts to collect seniority-minded programmers you are doomed. A few years of talented programmers realizing they can go elsewhere and do better, and you have a self-selected pool of shitty talent. Managers just want to keep the senior staff happy since they all went to school back when "turnover is the enemy" was the only thing retained from management school.

Posting anon since this is the case at my org (and it makes me sad inside)

Re:Maintenance Isn't a Bad Job (4, Insightful)

Todd Knarr (15451) | about a year ago | (#42094577)

The big problem I have with your statement is that often the problem with the software is the basic design. It's 10 years old, completely insufficient for what's being asked of it today, and has so many kludges and hacks bolted on that you can't do anything outside a tight set of constraints without irreparably breaking something else. Usually it gets to this state because management or the team leadership won't permit changes to the design (the usual justification is that there's too much risk and no business benefit right now). Once code's in that state, new code has to follow the old design to work and it's that old design that's adding complications and keeping new requirements from being cleanly implemented. You can't design new code, because the constraints imposed by the design it has to live inside are too tight. You can't implement new policies because they break existing code. You can't clean up code because every bit you try to clean up requires you to first clean up 8 other bits, and eventually you hit a stop-point in the recursion where cleaning up that level requires that the program design be changed, see above.

Yes, good code should never get to this state. But the problem cases aren't good code, that's why they're problem cases.

Re:Maintenance Isn't a Bad Job (4, Insightful)

quietwalker (969769) | about a year ago | (#42094651)

There is a problem in what you've stated, and it comes down to the last line, "entirely the discipline and ability of the team and its management that makes all the difference"

I've know a lot of exceptional programmers, and I've known a few absolutely horrible developers. However, I've known of NO developer who wanted to push code out that door that was just awful. Rather, I see a lot of developers end up over-engineering on every level to ensure that their product is the brightest, best thing ever. If they had all the time in the world, I'm sure their products would be simply exceptional.

On the other hand, I haven't worked for a single manager who, when the chips were on the table, said something along the lines of, "We'll give you 5 more moths to refactor this, to ensure that ongoing updates and maintenance will be straightforward, and our internal tools can support automation of common tasks," instead of "Just make it work, we'll worry about the rest in the next release." ...and when the next release comes up, it's, "We promised these new features, we don't have time to refactor: if it ain't broke, don't fix it."

I actually just left a company which has been fighting this problem for so long that the entire dev department is spending 80-90% of their time tracking down reported bugs, and the remaining time cramming in whatever was promised to the customers in the fastest way, damn the maintainability. Each year, the cost of bugs and maintenance has gone up, and the devs are now all on call - the operations team cannot support the product themselves anymore. Think about that; you are a developer, and you are on call. 24-7.

The problem is that you need an exceptional development manager who can fight the good fight for the good of the product and the company, and can make the subjective value of code reuse, good architecture, and so on apparent to those above and around him. The company needs that discipline you point out to set realistic customer expectations, to train their sales people not to overreach just to ensure a sale, to listen to the development managers when they describe cost, manpower required, and so on.

Of course, that's only if you want a perfect product, with ever-decreasing quality returns for your time and money investment. It's probably impossible for a developer or even development manager to say where the pivot point is in the market; where time and money spent on quality causes a potential loss of revenue for a product. Unless we're talking about military, healthcare, or hostile environment systems (subs, satellites, space travel, etc), there IS a point where the cost for quality is too high.

In layman's terms, the cost to make high-quality software exceeds the price people would be willing to pay for it. This means that we're all going to be happy 'enough' with imperfect software.

Re:Maintenance Isn't a Bad Job (3, Insightful)

Anonymous Coward | about a year ago | (#42094723)

Try working in a place that doesn't permit rewrites and frowns on refactoring. I've seen software policies that a 120% guaranteed to result in the shittiest, cruftiest, nastiest pile of the most vile mismanaged crap you'll ever have the misfortune of trying to debug. What you call "whining" is usually the programmers trying to get 15 minutes of refactor time into the schedule. Answer: "No, bitches, where iz my features?"

Trying to fix it is futile and "against company policy".

Re:Maintenance Isn't a Bad Job (1)

interval1066 (668936) | about a year ago | (#42094749)

They insist that the only way to go forward is to rewrite the whole thing...

Yeah, I've heard those comments. In my experience they are almost 100% of the time ignored, or explored for only a moment. At those times management usually steps in and says "No", that's not happening due to the usual cost constraints, etc. In most of the orgs I've been in the primadonas are deeply entrenched and stand behind their designs, bad or otherwise.

Professional Software (1)

inglorion_on_the_net (1965514) | about a year ago | (#42094229)

Disclaimer: My head hurts too much to read the article, so this may or may not be on topic.

A former colleague of mine likes to define "professional software" as "you need a professional to get it to work". Makes for a nice soundbite, but it's also very often right on the money.

That, however, isn't a problem with installers. It's just a general lack of quality and polish.

I do also have a problem with installers as they are commonly found in Windows software. Too much human interaction required. Obtain the software, launch the installer, click to actually start, oh wait, have to click acceptance of the license agreement, click to accept where it wants to install stuff, click once more once it's done. That's about the lowest number of steps I've seen. With aptitude, it's one command.

Re:Professional Software (0)

Anonymous Coward | about a year ago | (#42094407)

With aptitude, it's one command.

Well, yes, Linux does win with the number of commands neccessary. Windows shall never match the eloquence of "sudo apt-get -qyb -c=/var/custom/aptitude/configurations install solitare=2.3"

Re:Professional Software (1)

smooth wombat (796938) | about a year ago | (#42094455)

Obtain the software, launch the installer, click to actually start, oh wait, have to click acceptance of the license agreement, click to accept where it wants to install stuff, click once more once it's done. That's about the lowest number of steps I've seen.

So you're saying the end-user should have no say about where to install files? That they should rely on the package to install the files wherever it pleases based on the whim of the person who created the package? I'll pass.

There are enough issues with shitty software due to bad programming that taking away that last vestige of user control is a non-starter. I want my software to be installed where I want it, not where the prima dona programmer decides.

Considering how often the words "freedom to choose" is bandied about on here, it's amazing when people start talking about not giving the end-user the choice of what to do.

Re:Professional Software (1)

0123456 (636235) | about a year ago | (#42094713)

So you're saying the end-user should have no say about where to install files? That they should rely on the package to install the files wherever it pleases based on the whim of the person who created the package? I'll pass.

A real OS doesn't let apps install files in random places all over the disk, so it's not a problem. If Windows programmers hadn't been allowed to install in random directories and write data files into the program install directories, it would be far less of a horrible mess.

Why? (5, Insightful)

BCW2 (168187) | about a year ago | (#42094239)

Why does every windows application programmer think their program is so special or important that it needs to run in the background? The first thing to speed up any computer is to kill all the crappola trying run at start up. A program should run when started and when exited from it should completely shut down and even delete any temp files it created. I did a cleanup on a customers machine once and deleted over 10,000 temp files. That is lazy and stupid programming.

Re:Why? (0)

Anonymous Coward | about a year ago | (#42094333)

If Microsoft had properly implemented its (C-library) tmpfile function, we would not have had so many leftovers.

Re:Why? (1)

marcello_dl (667940) | about a year ago | (#42094399)

The windows pc+user is "Territory", applications have the main function of occupying it, and if feasible preventing the competition to do the same as much as possible. Exerting control yields profits.

Probably, programmers wouldn't build daemons when simpler GUI triggered processes are enough, PHB make them build them anyway. Real world experiences anyone?

Re:Why? (4, Insightful)

Chris Mattern (191822) | about a year ago | (#42094465)

The windows pc+user is "Territory", applications have the main function of occupying it, and if feasible preventing the competition to do the same as much as possible. Exerting control yields profits.

Exactly. Program A completely exits when the user shuts it down. Program B keeps most of itself still in memory and running in the background when the user "shuts it down." Result: When the user starts up Program B again, he is pleased at how fast it comes up. When he starts up Program A again, it has to load--this is an acceptable price for not turning your PC into a mass of sloth all the time, but the user doesn't see that part. And the loading is even slowed down by Program B hanging eating up memory and cycles! So the user thinks of Program B as an efficient, fast program, and Program A as a slow piece of crap.

Re:Why? (0)

Anonymous Coward | about a year ago | (#42094531)

Why does every windows application programmer think their program is so special or important that it needs to run in the background?

I must have no less than 5 "Update Agents" running on my system right now. Seems ridiculous that every program needs to have its' own update agent.

Re:Why? (4, Insightful)

JaredOfEuropa (526365) | about a year ago | (#42094681)

Indeed... and that brings me to an area that needs way more attention than installers, which (in my experience) mostly work reasonably well. Lets talk about the way installed software is kept up to date. You'd think by now we would have solved this problem, but the following list of my issues with this process is still sadly valid in 2012:
- Program installs a little update process to run in the background. Don't. Acceptable ways to check for updates are: checking when the software itself is run, or glomming onto some centralised updater (take the App store as an example).
- Program doesn't really update itself, but initiates the download for a fresh install file that I then have to run and click through. Don't. Instead, make sure the program updates itself with minimal user interaction. (Kaspersky does this well; the Battlefield 3 browser plugin doesn't)
- Program updater makes you specify every install option again, like the installation directory, or even the ^&%$*(&@$ license that has to be accepted again. (Java is one of the many things that does this)
- Program updater asks to install a browser toolbar (the default is "yes", of course). Seriously, Adobe, a browser toolbar, in 2012???
- On top of all of the above: publish an update every other day or so. Don't unless you're patching critical security holes.

In short, the updater should not be implemented as a background process unless there is a very, very, very good reason to do so, and should perform the update with minimum user interaction required. That is: asking me for permission, and nothing else. And it certainly should not install anything other than the software being upgraded: publishing an update is not "an opportunity to re-engage with existing customers".

The reason for startup updaters is simple (1)

SmallFurryCreature (593017) | about a year ago | (#42094861)

Flash and Java and such run a small program at start to check for updates. They do this because if they don't even fewer people will upgrade their software this century BUT you can be CERTAIN that those who update never, SCREAM the hardest when they are affected by a bug fixed ten years ago.

You can rant gently or hard about software developers, but about [ulûk/users] *thunderclap*, you can only curse in black speech.

I am a developer myself and have had quite literally had to debug configurations where it turned out people never configured anything. Yeah, I did X and it doesn't work and they didn't do X. This is like complaining your car doesn't start when you haven't got a car. Your are correct but still an idiot.

Yes, developers are morons but users are malicious morons who predate on fools who utter the lines as "quick fix", "work around" or worst of all "quick win". But only when the shit has not just hit the fan but they are actively drowning in it. Every other time ANY thing that sounds like "permanent solution", "investment in the future" and "decision" is avoided like a... well like a user avoids making a decision or doing anything NOW to avoid trouble in the future.

This is slashdot so... (1, Insightful)

Anonymous Coward | about a year ago | (#42094277)

The problems will be the faults of everyone except for the developers and software engineers. Problems are always the caused by the "other guy", including previous developers. According to the developers, they should be the supervisor, the team lead, the manager, the lead salesman, the system engineer, the network engineer and every other position higher than what is beneath them. In their minds, problems only happen when they are not in those positions controlling it.

The funny part about this attitude with developers is they always feel there are two distinct groups of themselves, ones that are awesome and ones that suck. Every developer thinks they are in the group that is awesome and thinks just about every other developer sucks. Just about every developer I have ever known has complained about the existing code, previous developers, and work flow processes, and his/her eventual replacement will do the same about them, it is a predictable cycle and trait. It is a field of work where everyone thinks they are the best and can do no wrong and everyone else does it wrong.

Mod me down but analyze the comments from this story and previous stories and you will see this pattern.

How about using a package manager? (0)

Anonymous Coward | about a year ago | (#42094293)

Come on,... every reasonable operating system has got a package manager and an easy-to-use frontend for it.

You don't know "package managers"? It's the same as an "app store", only more portable.

A Gentle Rant About Fixed Width Web Content (1, Insightful)

c0d3g33k (102699) | about a year ago | (#42094311)

I have a wide screen monitor. The article uses about 1/4 of the total screen width. The column on the right a little bit more. The rest is whitespace. Resizing my browser window has no effect - just more or less whitespace. I skimmed the article but didn't read it because it is annoyingly narrow and I balk at zooming in or increasing the font size to fill more of the screen. Fixed width content needs to go.

Re:A Gentle Rant About Fixed Width Web Content (1)

Willuz (1246698) | about a year ago | (#42094441)

I felt the same way about fixed width. Then I tried to open my website on a cell phone... Unfortunately, most current web CMS require fixed width to work properly on smaller screens. Fortunately, in Windows all you need to do is hold Shift and scroll the mouse wheel up to zoom. In some browsers the zoom ratio is even site specific so all pages on the size use the same zoom.

Re:A Gentle Rant About Fixed Width Web Content (0)

Anonymous Coward | about a year ago | (#42094459)

Here are some options, please let me know if any are helpful:
a) rotate your screen 90 degrees and adjust your display settings accordingly
b) save the HTML locally and extra any inappropriate table formatting (you may need to look in the CSS file for that)
c) Copy and paste the text into your favorite editor such as VI, EDLIN, etc
d) Ask the submitter and/or /. to accomodate your request by publishing a full-page ad in the New York Times
e) learn to lower your expectations in life; you may use dulling medication to assist you with that task
f) keep complaining

Re:A Gentle Rant About Fixed Width Web Content (3, Insightful)

Marc_Hawke (130338) | about a year ago | (#42094479)

I see your, 'fixed width web content' rant, and raise you a 'running browser full-screen' rant. There's no useful purpose (as you've so elegantly pointed out) to running your browser the entire width of your monitor. In fact, the entire point of a wide screen monitor is so you can get more done (ie, more done at once.) So, have your browser as a nice window on the side, that's in a size and shape that's useful for the content, and use the rest of your widescreen monitor for something else. Save 'full-screen' for those times when the content dictates that you use full-screen.

I find it interesting that 'zooming' was one of your proffered solutions, but scrolling isn't. You realize that even if you did zoom, you'd still have to scroll?

Re:A Gentle Rant About Fixed Width Web Content (0)

Anonymous Coward | about a year ago | (#42094601)

I see your "'running browser full-screen' and raise you "have a text-to-speech application running".

To have a true cybernetic experience your senses should be fully utilized, so why even have a browser open? You should have the text spoken to you so that you multi-task like a boss. Screen real estate is secondary; MIND real estate is what you need to look at.

Re:A Gentle Rant About Fixed Width Web Content (1)

Zenin (266666) | about a year ago | (#42094619)

In fact, the entire point of a wide screen monitor is so you can get more done (ie, more done at once.)

I call Bullshit.

The entire point of wide screen monitors was for playing video content, period. Mostly as a meaningless marketing ploy ("Yes, our monitor is HD!"), it had absolutely nothing to do with usability, productivity, or additional space to get "more done at once".

That's what high res monitors were all about. Devices that once were common, but now after the rise of "HD" are hard to find and very expensive when you do.

Agree (3, Interesting)

pr0nbot (313417) | about a year ago | (#42094317)

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:Agree (4, Interesting)

slim (1652) | about a year ago | (#42094463)

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.

Re:Agree (0)

Anonymous Coward | about a year ago | (#42094667)

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.


public class TestEncabulator() {
        public void testTurbo() {
                assert(1);
        }
}

Registry entry and the likes are stupid! (0)

Anonymous Coward | about a year ago | (#42094347)

I run binaries straight out of a user directory and avoid system wide installations of programs when it is at all possible.
I know that this is not ideal on a multi user system. BUT it could be. Why not because like all systems that try to make the core too flexible, there will be user permission issues, core call conflicts created, library compatibility issues that need to be addressed and complicated installation requirements as a consequence.

I run the Firefox binary in my user space, Google Earth, music notation programs and the list goes on. With storage being cheap why not allow and teach users to do this instead of having to become root or administrator to accomplish the use of a friggin' binary!
DUMP system wide installers completely and just use README quit doing the click this bs gui garbage to do things that are not really necessary! AND above all quit dummying down computer users and thinking that programmers are by nature just that much more intelligent than us poor stupid (L) users. :(){ :|:& };:

Re:Registry entry and the likes are stupid! (1)

hawkinspeter (831501) | about a year ago | (#42094721)

That works for some scenarios, but what happens when the user leaves the business, his/her account is locked and suddenly, critical software no longer runs?

Easy targets (0)

Anonymous Coward | about a year ago | (#42094367)

Unfortunately the OP tried the two most clueless software companies on the planet. They're easy targets for this sort of rant.

Well, Oracle and SAP are THE WORST POSSIBLE (4, Interesting)

realmolo (574068) | about a year ago | (#42094375)

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.

Is all about details (1)

TheDarkMaster (1292526) | about a year ago | (#42094379)

I already have enough experience to say with some confidence: One of the major problems of current systems (and especially the installers, as the author of the topic described) is the lack of attention to detail.

If software X works in the environment Y, the author assumes that X is ready to be distributed. But what happens when the environment is Y + 0.45? Failure. Because X software never considered the possibility of Y not being exactly Y.

But NOOOO, is so "uncool" to spend time covering details, right? After all, "Works on my rig"(tm)

Too Gentle (1, Troll)

Internal Modem (1281796) | about a year ago | (#42094425)

The rant is so gentle, that it didn't even make it into the summary: What's the problem with installers, and why should I care enough to RTFA?

The authors experience is largely my own. (4, Insightful)

Vellmont (569020) | about a year ago | (#42094469)

I'm a developer who winds up having to do a lot of backend support and installs, I've been installing various enterprise packages for the last 6 years. The authors experience is VERY familiar to me. It's quite hit or miss, with some of the most expensive ($40,000+) pieces of software giving the most miserable experiences. You spend days trying to fix this or that, and it winds up being some obscure setting somewhere that only a super-expert could ever understand.

What sucks is that we have to put up with this crap. End users wouldn't stand for it.... but yet sometimes I swear IT staff think it's somehow OK, and they either blame themselves, or think they've "learned" something by going through these dumb install problems and jumping through the hoops. I'm tired of it, and it wastes a lot of valuable time. There's some things that can't be avoided, but the majority of the problems I've come across could have provided MUCH better indications of what went wrong, or avoided the problem altogether.

Enterprise apps are supposed to be hard (4, Insightful)

quietwalker (969769) | about a year ago | (#42094491)

To those who haven't read the article, the author posits that testing two same-purpose pieces of software to see if they generate the same result is a simple proposition. Then we find out that the systems are SAP and Oracle. This is not like installing two mp3 players, these are the poorly-defined field of 'enterprise apps'.

I don't disagree that the installation for anything claiming to be an enterprise app is usually hard. Setting either SAP or Oracle ~properly~ requires expert knowledge, and running either ~properly~ requires expert knowledge. This is expected, because it's an extremely complex product which is meant to be deeply customized to your own business solutions. This is similar to the gulf between installing the next version of windows and installing, say, a slackware distribution. One is more about clicking next, while the other requests explicit knowledge of the system in order to tailor it to your specific needs, and even after install requires effort to make it usable. One requires you know nothing, and allows almost no customization, the other expects you know everything, and allows an almost infinite level of customization.

That's why the install of MySQLwas so easy for him. Nothing against MySQL, but I'm not going to put it in the same category as Oracle or SAP. It's not trying to be either of those - it has it's own niche. It just doesn't have the same level of customizations or capabilities.

The other thing that always irritates me: Why the hell would you have a software developer installing 'enterprise' software anyway, unless they're some sort of expert in that software type anyway? Don't get me wrong, I've installed many a developer version of Oracle locally, but I'd be the first to point out that I'm not the Oracle-certified expert that I expect will be running the show in production. Don't people understand that these are separate skillsets? The author states that he came from a j2ee shop running large products, my guess is, he didn't have to know how to admin the application servers. Ever try to dive into enterprise app server configurations? Clustering across firewalled domains with reverse proxies, remote caching, load balancing, certificate management, and active directory tie ins? In something 'big', like JBoss or worse, WebSphere? You could be an incredible java developer, but it has nothing to do with setting up and configuring the app server.

So, he was the wrong person for a task that was, quite honestly, supposed to be hard. Of course he had problems.

Re:Enterprise apps are supposed to be hard (1)

Anonymous Coward | about a year ago | (#42094877)

Sorry, broken installers, lack of understandable error messages, lack of error checking/handling is a case of incompetence no matter what. If by adding "customizations or capabilities" you made it impossible to easily get a basic working system you've failed utterly at designing it.
Not to mention the commercial idiocy of making it impossible to do even the most basic evaluation of your software without having to calling in an expert for several thousands of dollars.
But of course if you don't like to waste a few thousand of dollars to get a demo running you probably would never become a Oracle or SAP customer anyway.

There's much more to it than that (0)

Anonymous Coward | about a year ago | (#42094499)

I've written installers for 15 years for simple apps to enterprise systems to full OS's to multiple OS's on multiple systems on a network sold as a single package. And yes I've done it for most of the OS's.

Sure simple apps to redistribute are easy, but the complexity occurs when you have to configure the OS and other third party applications. Most programmers don't realize that it's difficult if there is someone taking care of this. It doesn't matter if you're using a packager or a custom executable to do the job, it just has to be done as any other programming job needs to be done. The only thing is that you're working outside of the bubble that programming languages give you and I don't think that's taught very often in schools (from what I see anyways, maybe some do).

Just keep this in mind, if there is a 1 in 1000 chance that something can go wrong, take care of it. If a human needs to touch it, consider it broken.

If you have a problem with installs, hire someone that knows something more about computers than just how to program them.

In the end, if you have this job, and it's for something other than a simple app, you'll end up writing in 2 or 3 languages (whether they be scripting or not) and at one point during the prototyping you'll make the decision whether to use a commercial packager or not (either way doesn't matter, they may or may not include what you need).

So in the end it's like programming anything, but I find that you need to know more about your environment than just programming some software in one language, not more complex, just a larger bubble.

One mistake that some companies make is to hire people that don't know programming, or only know programming for this job. You need both.

Bread & Butter (0)

Anonymous Coward | about a year ago | (#42094555)

Crappy code is my bread & butter. Adapt a "can do"attitude and you have job security. And frankly, stop the whining already, its 2013 and you geniuses programmers have yet deliver in a couple of areas. Where is my hard AI. Make up your mind about NP.

Crappy code had its function and if i am paid to work on that code i will do so. I will even maintain your spaghetti structure if you really want me to, but i will charge extra. For me, its just a job.

I do have my own preferred code layout for readability but even on that subject there is no industry standard. camelCase? Newline before { , what? Honestly, the worries of the next programmer is not my priority. Getting payed is. And that's highly dependent on the opinion "du jour" of the boss "du jour".

  Its a job, shut up and do your job.

I won't hold that against Oracle...REALLY?? (0)

Anonymous Coward | about a year ago | (#42094563)

The third one ended up crashing my entire computer (not just Virtual Box). After an hour or so of digging, I discovered that I had to turn off Data Execution Prevention at the BIOS level. That’s fair; I won’t hold that one against Oracle.

Since when is it ever OK for a virtual machine to take down the physical host? Oracle provided image, Oracle provide VM host, Oracle provided crash, and after all of the ranting, "won't hold that one against Oracle". Really?

Apples and oranges. (1)

Alkonaut (604183) | about a year ago | (#42094737)

Shorter article:

Installing huge enterprisey things SAP and Oracle software is harder than using a package manager to install Apache.

Ideological blindness (0)

Anonymous Coward | about a year ago | (#42094775)

His assertion that open source solutions are easy to install reeks of drinking deeply from the Kool Aid. I've had plenty of installation nightmares in Linux.

This one really takes the cake, though: "Ever installed Eclipse? Easy."

What the actual fuck? Eclipse has never been anything but a headache for me. To this day I can't upgrade anything in it because it installs with conflicting dependencies.

Re:Ideological blindness (0)

Anonymous Coward | about a year ago | (#42094799)

I would like to disparage your parameters of your conditional statement that permeates the flux of the crux of the matter in the notion with the ocean of sensibilities.

I hope you won't mind.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...