Tuesday, October 14, 2014

Are you solving problems by solving it with new technology?

Talked recently with a old colleague of mine about the solutions we are working with. We both worked with legacy and green field projects together and now he's tearing several old Tomcat systems apart and creating smaller (but not Microservices) services. He's using Dropwizard and this is a particular cool platform and I was eager to hear about it. My current assignment is working with a couple decade old JEE applications which has been somewhat ported to JBoss (which for the record, has not been impressive as a platform). But what we had in common on our new jobs were the fact that we had to take care of loads of legacy code. Both systems are lifting a heavy load and serving millions of transactions each day, and one system is from a successful startup.

There were two conclusions we made:

The first is that it really doesn't matter what you try, your code will look like crap or at least the guy coming after you will think of it does. Even the best intentions of keeping it nice and neat, if not given time or its large enough, it will deteriorate into a ball of mud. Both applications has been "customer" driven and whenever something major has changed, the developers hasn't been given the time to do a proper rewrite. For different reasons even the rewrites is not optimal and probably is the result of the second conclusion.

The second conclusion is that, for some reason people tend to solve problems by throwing technologies at it, like a NoSQL database or some fancy framework instead of just using plain old code. Whenever they are trying to solve stuff with the "new cool tool" they might solve the immediate problem, but loads of others problems turns up. Part of it that the developers doesn't understand how to use it or its just too damn hard using it, or its not working as they thought it would be. Or they end up with different frameworks entangled, both not fully understood or adapted.

I think we all have been guilty of being the one throwing "that new cool tech" or pattern at a problem instead of actually solving it with the current choice of technology. Every time someone starts blabbering about patterns, and particular when I know they even haven't understood the implications or details of that "pattern", I can almost feel the deterioration of that particular code. Or when you incorporate that, on the paper, beautiful BPM or <insert architect's new favorite tech solution which he have studied but never used> which you really don't need and poorly understood, because the only thing you need is code. And this is also one key factors which adds to crap code, is the idea of buying some other thing which should be able to "fix" the mess your code is, instead of just writing proper code.

On the other hand, as a developer you automatically assume that the guy which touched this before you is a dumb redneck which fell asleep on the keyboard which he have happened to pass on his way to the toilet. As the Dilbert strip so eloquently pictures it, do we as a professional admit the last guy actually did a good job? I know I've been guilty of thinking in those terms, but lets face it, most people does these things to put food on their table, not building the most beautiful piece of code ever existed.

I think most of the time you just need to sit down and think hard on what you could do with your current solution can do for solving it and not being seduced into using some technology.

No comments:

Post a Comment