Choose your weapons carefully, relinquish them reluctantly

I had a link in my last post to an article I wrote about selecting tools carefully, entitled “Choose your weapons carefully, relinquish them reluctantly”. Apparently that link now brings you to a page where you must sign in to the wiki where it’s posted before you can read it. I didn’t realize that when I tested the link because I was indeed logged into the wiki on another browser tab. I apologize to anyone who clicked the link and thought I was trying to lure them into joining yet another online community, I hate that kind of thing just as much as anyone else. Here’s the write-up that the link was supposed to point to.

As a seasoned veteran of software design and implementation, every architect is armed with an array of weapons they’ve used with repeated success. For one reason or another, these technologies have found favor and bubbled to the top of our list of preferred solutions. Most likely they’ve earned their rightful place in your arsenal by defeating fierce competition. Despite this, a barrage of new technologies constantly threatens their position. We are often compelled to lay down our weapons of choice for these new alternatives but don’t be too quick to dismiss your trusty armaments. To cast them aside for alternatives that haven’t been proven through similar trials is a risky proposition.

This doesn’t mean that once established on our list of favorites a technology is granted infinite tenure and it certainly doesn’t mean that you can bury your head in the sand and ignore advancements in software development. For each technology the time will come when it needs to be replaced. Technology moves quickly and superior solutions are on the way. As architects we need to stay abreast of industry trends, we just don’t need to be the first to embrace fledgling technology. There’s usually no huge advantage to being the first to adopt new technology but there can be several drawbacks.

To justify the risk involved with selecting new technology its benefits should be a quantum leap forward. Many new technologies claim such advancement but few deliver it. It’s easy to look at new technology and see technical advantages but those benefits are often difficult to sell to stakeholders. Before you decide to blaze a trail with new technology, ask yourself how the business will benefit from this decision. If the best outcome from a business perspective is that no one will notice, rethink your decision.

Another important thing to acknowledge is cost associated to the shortcomings of new technology. These costs can be high and are difficult to calculate. When you’re working with familiar technology you’re aware of its idiosyncrasies. It’s naïve to think that a new technology won’t come with its own collection of pitfalls. Adding problems that you haven’t solved before will destroy your estimates. You’re far more aware of the costs involved when implementing solutions using familiar technology.

One last thing to consider is future relevance. It would be nice if we could simply identify and select superior technologies but things aren’t quite that simple. Great technologies don’t always win. Trying to predict the winners early is a gamble that doesn’t yield a large payoff. Wait for the hype to die down and see if the technology settles into a space of usefulness. You’ll find many just go away. Don’t jeopardize your project for a technology that doesn’t have a future.

Selecting the technologies we use to attack problems with is a large part of the software architect’s job. Choose your weapons carefully and relinquish them reluctantly. Let your past success help to ensure future success and evolve your technology stack cautiously.

Stop Inventing Frameworks

Why is it, that with every project I work on, I seem to run into yet another homegrown framework? Some mad scientist has decided he’s got a better way to process http requests than the fine folks who wrote Spring MVC or Struts. I’m not talking about servlet based frameworks that print HTML and were written ten years ago. Sure, it sucks to be on a project like that but you can’t really be that angry about it – those are the tools that were available back then so that’s just how people did stuff. I’m talking about the projects that started a year ago, yet still have some guy’s pet project MVC or data access framework.

I’m not sure why this seems to be such a common occurrence. Perhaps the culprits are those who’ve just finished reading their first patterns book and really feel the need to put together a nifty framework using all those patterns. While implementing a framework may be a useful academic exercise to become familiar with patterns, using such a framework in lieu of a proven solution that solves the same problem is probably not a great idea. Many of the patterns required for a web application have already been implemented in existing frameworks. In fact, identifying patterns in a framework such as Spring is also a good academic exercise.

While it’s very possible that you’ll need to extend an existing framework or write something that is domain specific, it’s not very realistic to think you’re going to single handedly write something like a data access framework that’s on par with an industry standard solution like Ibatis or Hibernate. Don’t get me wrong, it’s not like I think I’m going to be using the same set of standard tools five years from now. However as I've mentioned before, once a tool has made my list of preferred solutions it takes a quantum leap forward for me to trade it in for something new. In all fairness, maybe you’ve created a solution that is indeed a large enough advancement to justify replacing an industry standard technology. If you truly believe that to be the case, ask yourself how you’d feel about releasing your framework to the open source community. Chances are, your gut reaction will be that you don’t necessarily want engineers from around the world scrutinizing your code just yet. It’s easy to push your solution on a captive audience of co-workers. Things tend to change when the people evaluating your solution are a group of completely objective strangers.

It’s easy to become enamored with your masterpiece and convince yourself that it makes sense for your company. The reality is that teams of talented engineers have created the tools you’re trying to replace. An endeavor of that magnitude is a large project in its own right and would require your full attention. Most likely you’re not able to make that type of time commitment. Even if you were able to replicate their results you’d be creating a proprietary solution for a problem that’s already been solved using technology that’s familiar to developers everywhere. It’s very hard for me to envision a situation where the cost incurred to develop, maintain and document that proprietary solution would be worthwhile. Do yourself and the people who inherit your project a favor and take advantage the technology that’s available.

Simple Minded Software

“There’s got to be a better way”. I’m not sure how many times I’ve uttered that phrase, but it’s certainly more times than I’ve said “this is too easy to understand”. One thing is for sure; many of the solutions and explanations we encounter are more convoluted than they need to be. In a world where obfuscation often shrouds solutions in an apparently necessary cloud of cryptic ones and zeros, I’m constantly in search of what I consider to be true software design elegance - simple solutions for complex problems. Sadly, as I’ve said before, it seems much easier to stumble across software utilizing overly elaborate solutions for simple problems. While it may not be immediately obvious, most of the time when I find myself thinking there must be a better way, there is. I’m not saying that all problems can be resolved with equally simple solutions. Transaction control and remoting solutions are probably always going to be a little more difficult to understand than input validation; that’s just the way it is. However, I don’t think I’m the only one that found myself saying “there’s got to be a better way” when I was writing EJBs in 2001. Like most software professionals who’ve been at it for a while, I’ve got my fair share of rants. Overly complex solutions seem to be a recurring theme that is often at the crux of those rants. The evolving quest for simpler software design and development solutions has brought more principles, ideals and opinions to my attention than any other topic. Hence, this is Simple Minded Software, the place where I vent all the things those closest to me are tired of hearing about on a daily basis.

image source: The European Patent Office website