I think the most important things developers should consider is the target OS (and version), the programming language (and version), and the libraries (and the versions) you use when building a tool. All of these challenges can be thoroughly tested using continuous integration, but to take full of advantage of those features we would need to write tests to cover all the methods and statements, and to write good tests we need documentation. Therefore, I think it would take a lot of work to get most academic software to the point of using continuous integration because I can't think of many toolkits that actually have a test suite and documentation (not just a readthedocs webpage because that is not helpful at the command line or for developing).
Getting there is much easier than you might think though, every Perl package I build has tests to check syntax, formatting, and check that every method is documented, so I can focus on more important things. Of course, a prerequisite to building a system like this is to use version control because you can't maintain a script/package from just your computer and expect it to work in another environment.
You asked for examples, so I will share some features of Perl that I wish more people in bioinformatics knew about. Since Perl doesn't consider whitespace significant you can use tools to pack your dependencies into a single file, so every script/app is dependency-free. This also works with C libraries, you can compile a Perl script and the C libraries it uses into a single binary. Also, there are some fantastic admin-free tools like perlbrew and cpanminus. Both of those tools are examples of my previous point, they can be installed with a single curl command. Therefore, no one should ever have to use "sudo" to do anything with Perl. From a developer's perspective, you can easily manage many versions of Perl with Perlbrew or plenv, and use them all to compile a script with a single command (though I use CI to do that for me). With cpanminus, I use a cpanfile (which is a dependency spec just like a gemfile for Ruby), so I can pin my installation to ensure one library version doesn't break the build. There other tools for managing dependencies also, like Carton and Stratopan, and those allow you to ensure that "version 0.07" always ships with the same libraries, not newer ones that the package manager decides to install.
I don't have a general solution for shipping core dependencies like graphics libraries, I wish there was one. You would think that people who use these in industry have clever methods for updating and deploying these tools rapidly (maybe Docker, as you said).
Shouldn't this be Forum? It's a bit of an open-ended discussion trigger, some might reject the premise in this generalized form even. What's the evidence for the fact of being 'hard to install'? Is this statement meaningful at all or without a comparison: maybe it was meant "harder to install", then what to compare it with, commercial software, all open-source software? That the answer to the other question has been upvoted doesn't necessarily mean it is true.
Changed to Forum.
I think you can quantify it, count the number of dependencies (and add up the lines of code) and the number of steps required to build a working version of the tool. Both of these factors will determine your time investment. Even if you feel it natural to compile large libraries like EMBOSS as a dependency of a program, wouldn't it be "easier" to just get the program with curl, if that were an option?
Maybe one reason is that academic bioinformatics software is often developed for Linux see also: http://www.psychocats.net/ubuntucat/software-installation-in-linux-is-difficult/
This is definitely one reason. On Windows/Mac, developers typically ship self-consistent binaries compatible across multiple versions of OS. On linux, it is recommended to compile from the source code due to the differences between distros especially in dynamic libraries. I think Linux does the wrong way. While some programs do benefit from compilation from source, a lot others can be shipped with cross-distro binaries.