The 5 Common Mistakes When Building Software

Building software can be challenging, and there are many pitfalls for the inexperienced and unwary. Having worked in software for over ten years, I have experienced just about every issue in existence. Looking back on these experiences, there are a handful of issues that are exceedingly common in failed projects. In this article, I present some of these common mistakes in hopes that you can benefit from the mistakes of others.

Many project owners start out with an overall idea of what they want the application to do but overlook some of the essential planning and upfront design work before moving into development. In some cases, this is simply due to unfamiliarity with the software process, and in other cases, it is intentional because many people feel the budget is better spent on actual development. This is one of the most common and impactful mistakes made when building custom software. Unfortunately, this mistake is not just limited to the inexperienced business owners as we also see technology professionals, typically software engineers not well versed in project management principles, make this same mistake.

Building software is a very concise and detailed process

Like any engineering discipline, building software does not work well when requirements are loosely defined and require interpretation. Sometimes it is easy to forget the “engineering” part of software because it’s not a physical construct. However, just as you shouldn’t build a bridge without proper detail and design, building software without proper detail and design can often lead to failure.

Let’s take a look at a simple example: Let’s say your first requirement is that you want a secure application that requires a login. A login sounds like a basic feature so you may write a requirement that states “User must first login to access the application” and then move on to more exciting requirements. When a software architect reviews that feature, a whole host of additional questions are likely to arise such as:

● Who will get a login?

● Will they get immediate access or do they need to be approved to log in?

● Do they need to have an account pre-created before they get a login or do they register?

● Do they need to pay a fee prior to login or do we need to log each login for future charges?

● Should the user be able to login with their Google or Facebook account or create a site-specific login?

Even with a login, there are a lot of details that go into defining the security, feature access, and user personalization features of an application. Defining these detailed parameters is essential to a functional software application. In most cases, with a little guidance, a non-technical business owner can easily make the necessary decisions to make sure the solution is serving the business objectives; however, this rarely happens without proper consultative assistance. Having a Solution Architect help uncover all of the technical decisions will make the process much easier. It will ensure that the requirements are more specific and that the details are properly aligned to the business goals rather than leaving them unspecified by downstream development teams.

A few other common mistakes that are made during a software build are:

1. Developer skillsets are mismatched with project needs
2. Making your software developer a business partner
3. Unique challenges that arise from working with offshore vendors
4. Not setting aside enough time and business priority for User Acceptance Testing
5. Having an unrealistic budget for the business objectives and finding out late in the process due to lack of upfront planning

Although these may sound like harmless possibilities, let’s take a closer look and you will understand.

1. Developer skillsets are mismatched with project needs

It would be great if all tech professionals were experienced in every component of software development. However, it is just not practical. A software engineer is not necessarily skilled at solution design, user experience design, or project management but might be great at writing efficient code. It is important to understand that delivering a full-featured software application requires the collaborative effort of a team of individuals, each with their own area of focus.

Over the years we have seen many software projects fail because a business owner started a project with a friend, neighbor, or acquaintance who was a professional software engineer. The assumption was that the developer had the required skillset to deliver a software application. On the surface, this may seem logical but it’s really no different than assuming any medical doctor can solve any medical issue you might have because they went to med school. The reality is that technology, like healthcare, has a broad array of specialties, and enterprise-class solutions often require different types of resources for different tasks and phases of the project.

Having a trained Solution Architect, who specializes in the design of software solutions, involved with your project at the beginning will save time, money, and headaches in the long run and help avoid costly mistakes.

2. Making your developer a business partner

Many companies attempt to partner with their software engineers and software development companies which may seem like a viable option to save money, show loyalty, and share responsibility. However, there are large pitfalls that are often difficult or impossible to overcome.

As previously mentioned, most tech professionals do not have the knowledge and experience to handle every aspect of software development which can easily result in a software solution that does not fully cover the project’s requirements. A successful software solution requires the skills and resources of many types of tech professionals.

Some companies consider partnering with their developers in an attempt to save costs. Although it may sound like a plausible idea, the downside is that it often costs more than if the proper professionals were hired in the beginning. First off, it has been our experience that, like in any partnership, there is often disagreement regarding the ownership of the finished software.

Additionally, if something goes wrong and the vendor/partner does not live up to the original agreement, what options are available?

● Do they get fired? If so, how is the partnership severed?

● What happens if the software does not meet the requirements?

● Will a dissolved partnership result in software that neither party can claim without going to court?

● What would happen if the developer simply stopped and left before the software is finished? Additional funds would be required to see the project to its completion.

This type of situation happens all too often and can easily be avoided from the onset by nailing down the types of technical help that will be needed. Again, this is when consulting with a Solution Architect upfront will save time, money, and avoid tenuous situations during the software build.

3. Unique challenges that arise from working with offshore vendors

Offshore resources have become a common option over the last few decades and there are plenty of situations when hiring one is perfectly appropriate and risk-free. For example, one-off projects that do not require a great deal of communication or direction are plausible situations. However, large projects, such as software development is not recommended for a myriad of reasons.

This is not to suggest that offshore companies are not skilled, or that they are necessarily providing poor customer service. In fact, many techs we have come across from India, Pakistan, Afghanistan, etc. are extremely willing to please their customers. It is simply that there are barriers that come with the territory.

Many companies believe they are saving money as offshore companies offer low estimates on software projects. Yet, there are several reasons for these lower prices that should be considered at the onset.

1. The initial information-gathering step is often abbreviated resulting in a less-than-perfect solution.
2. There are language barriers that are often overlooked in exchange for lower prices.
3. Consultancy is not offered therefore questions that would normally come from a detailed Solution Architect are not asked, which translates to problems and errors during the process.
4. Offshore companies generally expect the software to be previously designed; they plan to handle the subsequent steps. However, design rarely accomplished in advance.

Miscommunications are fairly common and rectifying development issues take more time due to the time zone differences, as well. The end result may be an application that does what was requested, but not in the way it needs to work. Software development intrinsically includes several stages that can go awry even without inviting these potential obstacles and pitfalls that arise when working with a company offshore.

4. Not setting aside enough time and business priority for User Acceptance Testing

A good software development company will normally include quality acceptance testing in the model for implementation in the plan. But those who are new to software development may assume that the vendor building the software will be testing it along the way. That is not the case. No matter how good the team is, they are generally focused on the technical aspects such as making sure the code is functioning the way it was designed to operate as opposed to trying to recreate the exact business flow and steps that its users are going to follow when using the software.

Unfortunately, misinterpretation of requirements and process-related issues are often found at the end when the application is being tested by users. The proper amount of time needs to be set aside to have users or supportive customers going through each function of the application, getting familiar with it, and signing off on it before it is considered live. It is relatively easy to resolve issues when you’re in the development stage, it is much more complicated when fixes and patches need to happen after the application has been placed into production. Don’t underestimate the importance of solid, thoughtful, and dedicated user acceptance testing.

In short, as a business expert and end-user, you have a unique perspective and manner in which you will test the application that is separate and distinct from how the development team will test.

5. Having an unrealistic budget for the business objectives

Another very important aspect of the design is making sure that your limited financial budget is being spent on the most important features and minimizing the chance of running out of budget before your software is fully completed.

Budgets are a reality that should be discussed early on and not much later than when the software is being designed. The problem often stems from not going into the details of the project’s requirements at the beginning rather than waiting to determine a budget once the project has started. If proper upfront diligence and planning transpires as noted, then this situation can be avoided. It will make an enormous difference in the outcome and with expenses.

An additional issue to avoid is starting a project with a low estimate and requirements that are too lightly defined. The low estimate is continually revised as clarifications occur, the scope grows and causes the budget to become unrealistic. The best way to avoid this is to ensure that your project estimates are associated with well-documented requirements and design work. Typically, this occurs when project owners jump into development without doing their upfront design and diligence.

The best way to determine a budget is to discuss your requirements with a Software Architect at the project’s inception. Ask for a detailed estimate that itemizes that which is optional versus functional necessities. You can then determine exactly what you can afford. It makes sense to get more than one estimate to ensure you are getting software that solves and strengthens your company’s workflow.

Software development is not inexpensive, however, when handled correctly, the ROI will be worth every dollar, particularly when you can avoid the potential pitfalls.

If you’re interested to learn more about what you need to build great software, I’m including here a link to a downloadable eBook, Checklist for Great Software.