The risk in cutting corners in software deliveries

We have all been on a project or two, where the delivery date was fixed in time, due to dependant companies, public launch announcements.  Now hopefully those dates are planned around the work that needs to be done, with at least some buffer room for the eventual things that can go wrong.

The reason we have those buffers in software development, is not to rip off the client, or overcharge, the hours charged to the client are the hours worked.  The reason we have those buffers, is so that if something happens, something as innocent as being sick for a day, doesn’t put the team in a situation to have to cut corners when it comes to quality.

I, as most technologists, take pride in my work, and want it to be of the highest quality, and hate being forced into a position that corners need to be cut to meet a timeline or a budget.

Testing

As my good friend over at Quality Captain knows all too well, the first place anyone tries to cut, is in QA/QC, (they are distinct terms and mean very different things), because the theory is, if things work the first time, this is a wasted effort, since you are just double checking that something works.

Quality Assurance

is defined as

QA aims to prevent defects with a focus on the process used to make the product. It is a proactive quality process.

If you cut time out from this step, you will be missing the part of identifying where bugs might arise, and what should be tested for a feature.

In the case of Wired’s JEEP Experiment, the U-Connect system works exactly as designed, and was probably tested as such.  Though what was not done, was the step of “what else can this do?”..  This is a step that is often “cut” because it can be time consuming and costly to a client.  Though this is a critical part of delivering secure and quality software.

Analysis

Analysis has many facets, and should take place at many steps in a project.  Analysis takes many shapes, and covers all parts of a project.  The feasibility of a project, the what should it do, and the how should it do it.  All of these steps contribute to a quality product that is safe to use.

Part of any analysis is not only figure out how should a feature work, but what are the weak points, and failure points of a system.

In the JEEP story, the situation was as follows, the U-Connect system allows the JEEP to access the information on the web, allowing navigational systems, and entertainment systems to better suit your needs.  The one step they did not do was protect the system from incoming transmissions.  This isn’t intentional, and was possibly overlooked, since the U-Connect system has a dynamic IP address, and someone would need to know the address, the make and model, and then find an unpatched version of the software.  The threat vector is real, and possible.  Unlikely for an end user, but can be very serious for someone intent on getting in.

Side Effects

The JEEP example is only one of many that happens in the world of software development.  Whether it be contests that can be rigged because there is no verification that you can only vote once, or a mail server that doesn’t verify that the sender is a valid account.  All these things are small yet important flaws that under the right circumstances can be exploited.

I understand that all projects have a budget, and as long as the scope of the project makes sense for that project there is no issue.  It is however becoming common practice to cut time and amounts to win projects, at a cost coming to quality.  There are countries that do business entirely on this premise,

A conscious choice needs to be made before cutting corners, and all the parties involved needs to be made aware of the impacts.