Dependencies

I have tried hard to get KDevelop going on CentOS 6. And I wasn't the only one - I saw that it also happened to some people who do such things often. Yes, I have some experience with it myself, too - so I tried it anyway. But this time, I couldn't get Cmake to find Qt. I gave up.

When it doesn't work, the cause of failure is usually a problem with the dependencies. Software engineers know this. Pure developers tend to use as many external tools as possible, but software engineers try to minimize the dependencies. The more experienced you get, the less you like dependencies. As long as you get the services of a perfect system that guards all dependencies you're OK. But it breaks down. What kills is not only that you cannot find the right versions, but also (slight) changes in interfaces or implementations.

Moderns systems are riddled with dependencies. On the OS for one - something you cannot avoid. Luckily OS's are managed by others, and they often do that quite well. As an app developer you will have to counter the annoyances of OS changes, but these are usually not so bad. Even better, OS's provide more an more tools that used to be in separate libraries that you had to manage yourself - separate dependencies.

The decision to start using an external tool is a very important decision. Beginning developers often don't care at all and try to find something for every problem they encounter. They don't bother that they're using just a tiny piece of something, and have to take in a huge mount of dependencies. This quickly results in a dependency nightmare. That's why at OpendTect we actively kick out things as soon as we see that the usage less than strongly required. For example, we did that with FFTW (the MIT FFT library). The benefit of a few percent extra performance in the FFT routines did not outweigh the hassle of the dependency. While kicking out you often diagnose your whole situation, and that makes the operation even more beneficial. We based our FFT on the SU way of doing things, and then found some other things we could do smarter. So in the end we lost the annoying dependency, and FFT-ing is faster than ever before.

For Agile, you don't have to use loads of external stuff. You do have to have basic things like GUI building, 3D visualization, zip/crypt, and so forth. It's important to figure out what can satisfy your needs, but remember that one of your needs is minimal dependencies! Very often your bare needs may be satisfied best using a mix of many small packages. But in the end, you can use much less 'luxury' tools and take in packages that have other good properties like light-weight (no fluff), integrated (just one, rather than many dependencies), robust (maybe not so slick), stable user base (will be there tomorrow, and will still support a changing outside world).

And then ... after a few years you discover that you still bet on the wrong horse. But that's life for you. Murphy's law.