Can You Defend Your Technical Decisions?

Some days, you have to search the news and various sites to find something interesting to write about. Other days, the topic appears in your email. Today, there was a blog post and an email that just fit nicely together. The email asked what being a software engineer was like, and I will answer that in a full post later this week but the blog post goes into one of those things all software engineers need to do. The post is about “The Most Important Question, Why?” and comes from Jason Falls at Social Media Explorer. Jason is specifically talking about social media and business, and this quote should resonate with a lot of people:

Too many times, especially when it comes to social media and technology, businesses flock to the hot new trend or the shiny new object with delusions of grandeur. Two years ago, clients would come to me and say, “I want a blog.” Today, they say, “I want a Facebook page,” or “I want a Twitter account.” My answer has always been the same: Why? Seldom can answer that question.

As a software engineer, you need to ask yourself why almost every day. A software engineer needs to make technical decisions at almost every step in the development process. When the project is first in design, we may determine that the software will be developed in Java and deployed to Apache and Tomcat servers. Why? Can you defend your reasons for picking Java and Tomcat? Does the application need to be deployed into a web infrastructure or does it make more sense as a desktop application? Can you defend your decision against someone that thinks the application should be written in Ruby?

In many cases, engineers may take the lazy route and just make decisions based on what they are comfortable with. In my case, that likely means Java on Tomcat. By taking the comfortable route, you may miss opportunities to make a better choice, or even learn new things.

In addition to the initial platform choices, there are several other things that need to be decided. If we are writing a web application, do we use traditional servlets, Struts, Spring or some other framework? This is when the decisions start to get really interesting. Spring may be the best choice for your organization, but are your developers familiar with Spring? Maintenance is a significant concern for any development organization. If your developers can not maintain an application due to a lack of technical knowledge, you have failed as an organization. Sometimes, you may be able to get training on the newer technology, but other times you may have to choose the older but known technology. These decisions get fairly hairy as well because people tend to feel very strongly about their favorite frameworks.

Once the core framework is chosen, the persistence framework needs a direction. Sometimes this is guided by your core framework, but frameworks like Spring allow you to integrate almost anything. With Spring, you can easily integrate Hibernate, iBatis or standard JDBC. You can also use JPA with any of those technologies as the JPA provider. Why you choose one persistence framework over another is highly dependent upon your organization and what you plan to do with your persistence layer. Hibernate is really good for straightforward data models that can easily be mapped to Java domain objects. iBatis allows you to customize your SQL fairly easily and allows great flexibility in your SQL. JDBC allows you to focus on the actual SQL without any of the quirks of the frameworks. JPA is considered the future of Java persistence, so it is a good technology to start working with.

This is really just the beginning of the decisions made on a project as well. There are various design decisions that are made every day that typically do not get questioned until a problem arises. You may be able to save yourself some time by questioning all of your decisions. Did you make the decision based on sound reasoning or did you make the same decision as you did last time because it is simpler to keep the same direction? Can you answer why? More importantly, can you explain why to your fellow engineers?

5 thoughts on “Can You Defend Your Technical Decisions?

  1. Even if you’ve made the technical decisions based on lots of technical knowledge and strong rationalizations, that doesn’t mean the choice is defensible. I’ll give a simple example.

    When I started the project, it was going to be a stand-alone web appliance that operates outside of the normal IT infrastructure. Just plug it in, and it works. Because of this, I picked a custom data-persistence approach. I basically built a simple, but hugely flexible quasi-relational database that required absolutely no human management. Since the data itself was mostly read-only, not only did this make the solution super-fast, but it was also super-expressive (and very simple to build on), and super-reliable. It worked exceedingly well.

    The product morphed into an enterprise-based software product, and the first question everyone asked was “What is the database you are using?” In those days, the mantra was “relational or death” (or something equally extreme), so every time I tried to explain how the database worked and that it needed no administration, I was often shouted down by IT insisting that I use their X-brand database. It was a sad introduction into how inflexible people could be.

    From a commercial product perspective, it’s easier and way better to just go with the established technology of the day. It’s what they want, and it’s what they know (even though it might not be what is right). A crappy product that sells (unfortunately) is better than a great one that doesn’t.


  2. Paul

    The changing requirements are something that completely changes a project. At the time it may have been completely reasonable, but if assumptions or requirements change, then your technical decisions may become an issue. Decisions need to take into account what purpose is as well. Internal applications have different restrictions that applications being sold as an installable product.

    I once had an application that needed to be designed so that connectivity would not be required. As the project progressed, the basic assumption had changed due to some connectivity contract that was made. We had to change our design of a large portion of the project in order to work with the new assumptions. It happens.


  3. Sure, it happens all of the time. History is one of our most common reasons why “it is not perfect” 🙂

    Still, if the original choice works and there is no real ‘external’ incentive to change it, then we tend not to. Until there is enough technical debt, the choice stays the same but the defensibility of the choice is considerable eroded.

    I tried to explain my above rational once at an interview for a consulting job, only to have the interviewer (rudely) tell me that I was “wrong” (one should NEVER create their own database, ever).

    I believe that nothing about software should be picked randomly (or by habit), but that doesn’t always mean that my rational for making a choice will remain reasonable over time. Sometimes I can’t defend myself (so I always try not to).


  4. The choice is available for software development organizations creating their own product but for consultant organizations and their developers it is difficult to make a call on the technology or the software to be used.


Comments are closed.