Month: August 2017

Over the course of my career, I have seen all kinds of advancements in programming — some of them good, others bad. Today, there seems to be a trend to use all kinds of frameworks, design patterns, and technologies in an effort to save time. Unfortunately, what seems to save time in the short term often causes trouble long term. I must start out by saying that I’m not suggesting that all frameworks and technologies are a bad thing. For example, using an MVC approach for developing web applications is an excellent idea as responsibilities are cleanly separated between the HTML, the business logic, and the data access code. This works very well and improves maintainability of code. However, other frameworks are less valuable to me. For example, the popular lombok package allows Java developers to create data classes without manually creating the getters and setters for fields. This sounds like a great time saver as you can avoid writing code! But here’s the problem — it’s often useful to be able to find where variables are set, and you simply can’t do that if the setter doesn’t exist until compile time. Furthermore, this package saves little time since Eclipse has the option to generate (real) getters and setters already. Why is this package needed? I don’t believe it brings any value — just another technology for the sake of technology. In Android code, I see all kinds of frameworks being used. Unfortunately, most of them only obfuscate the code. While there is value in the MVP model, many Android activities are too small to really gain much from this model and the excessive number of interfaces begins to be a drag on development. Speaking of interfaces, they are probably the most overused design pattern. Again, I have to start out by saying that I absolutely love interfaces. Properly used they are one of the most valuable features of Java. Unfortunately, when everything becomes an interface and you need dependency injection to create the objects things start to complicated — often without any real benefit. Interfaces allow us to plan for the future — to admit up front that other implementations may be needed later. But in many cases this is simply never going to happen. Database code should certainly be written using interfaces wherever possible because it is not only reasonable but indeed likely that the project will — at some point during its lifetime — use a different database. Other things may make sense for interfaces too such as code for credit card processing, sending messages, etc. Ask yourself — is there a reasonable expectation that we will have multiple ways to do this? If the answer is no, why are you using an interface? Again, I have no problem with these technologies. But for me, my first choice will always be to use the simplest stock Java code I can and only move on to more complex frameworks when necessary. My code footprint is smaller, code is easier to maintain, and new developers can more easily move into developing or supporting frameworks with fewer complex patterns and technologies.

I started tinkering with computer programming twenty years ago. It started pretty simple with learning HTML, then I moved on to learn C, then C++, and Java. Along the way, I picked up numerous other languages. For the last 17 years, writing software has been my profession. I consider myself an expert programmer, particularly in Java. But what does expert mean? I see resumes of people who have 3 or 4 years of experience and claim to be an expert in Java. Is that possible? Unfortunately, I think the IT world has cheapened the idea of being an expert to a point where it is meaningless. In the competitive market for software developers, individuals market themselves as an expert so they can acquire the most lucrative job opportunities. Does this really hurt anyone? Yes, it really does. Companies have self-proclaimed experts write their software. Then, when that worker’s contract is done, or another more exciting project comes up, that expert jumps ship. Now, the company is left to maintain that code. And this is usually the point where the business finds out that the ‘expert’ they hired wasn’t an expert at all. Expertise in computer programming means an ability to analyze the problem and come up with a solution that is maintainable and stable. But all too often, we find ‘experts’ writing code that nobody wants to maintain because it is convoluted, poorly documented, fails to comply with style and naming conventions, and buggy. We find database schemas that are bloated and make no sense. We see poor project hierarchy and little object decomposition. In short, we see garbage code. When you hire a programmer, don’t let them fool you — if they’ve only been writing code for a few years, they’re not an expert.