Lessons We Should have Learned from Jurassic Park
One of my favorite lines from Jurassic Park is when the new arrivals to the park are having lunch and discussing for the first time the concept of having living dinosaurs walking around at the same time as modern man. All the scientists agree that it's not necessarily a good idea, some going so far as to say it's a horrible idea. The quote is from Dr. Ian Malcolm:
I'll tell you the problem with the scientific power that you're using here: it didn't require any discipline to attain it. You read what others had done and you took the next step. You didn't earn the knowledge for yourselves, so you don't take any responsibility for it. You stood on the shoulders of geniuses to accomplish something as fast as you could and before you even knew what you had you patented it and packaged it and slapped it on a plastic lunchbox, and now... you're selling it... you want to sell it!
So how does this effect software development? Easy. There are tools like Eclipse, and frameworks like Spring that allow decent-to-marginal developers to take such terrific shortcuts that they never really have to have the discipline to really make the system they create stable, reliable, maintainable.
In short, they get to hack their way to something that works, without ever really taking responsibility for the system they're building. Let me give you a case in point, but this is by no means the first time I've seen this type of thing happen.
The one app I've been looking a lot at recently is a Tomcat web system that should be a fairly simple collection of servlets doing data collection, aggregation and serving it up. Nothing fancy, but there are details to the process that are important to get right. The developer didn't choose the traditional approach, but rather decided to use Eclipse and Spring to make it easy to re-wire the application at a later date. Tons of interfaces, hard to navigate the code and find what's doing what, and for an app that should have a dozen classes, at most, this is saying something.
But it's classic Spring.
Meaning that the XML configuration files are equally as important as the code it uses. I've had quite a bit of experience with apps like this and in the end, it's always a support nightmare as the configuration of a real app that does a single, well-defined, and well-designed function does not need to have the level of configuration that a Spring app does, and because of that, there's a tremendous risk of messing things up when you do have to do a slight modification.
Now if this developer had to really design this system without using Spring or Eclipse, then they'd have to see where the data was that they needed, and leverage that. They'd say "listen, parsing XML is OK, but it's no way to get the dozen parameters I need - I'll get those from a properties file - or a database." When you have to do it, you think about what's necessary and what's not. You are forced to design the system.
Now, in the hands of a good designer, I have no doubt that Spring can assist in the development process. But in the hands of someone looking to skip a lot of the work, it's a dangerous tool. You have to understand the tools to effectively use them. Just like Jurassic Park.
In the coming days and weeks, I'll be taking over this application and there are a lot of things that I'll be changing. I might rip Spring out completely. The problem isn't that hard, and the configuration issues are one of the major brittle features of the system. Something has to give, and I'm not convinced that Spring is adding the kind of value that it's meant to.
There's nothing wrong with getting a leg up with tools like Spring and Eclipse, but when using them means that you don't really understand what's going on in the workings of your application, then these tools are doing you a disservice. Any developer needs to understand first, and then work on the ease of development.
There really is no free lunch.