Why the Quality Software Delivery of Your Project Will Take Time

Isn’t it a wonder how engineering projects can be built with greater accuracy than delivering software development projects without bugs?

This article is not in any way meant to defend the timeline of software development. In fact, it is here to show common industry issues that are faced by both the development team and stakeholders. It is never as ‘easy as pie’ to build a solution from scratch to completely resolve a business’s long struggle in a particular area. But with advanced knowledge of certain obstacles in the path to success, the following list can be useful in helping to avoid any major delays.

The software industry remains relatively young

As humans, we have been constructing buildings, roads and bridges for thousands of years. With a glance of a simple web search, we can see that our past knowledge of building does not mean everything built today is perfect. Mistakes are still made.

Given we only have about 50 years of software development behind us, we have a ways to go before reaching a point whereby the vast majority of projects can be ‘pre-fabricated’ in advance to considerably reduce development (a.k.a. construction) timelines. Pre-built components are always in sight as the solution to some lines of code that must be repeatedly input by hand into each project. It is not a copy/paste world.

Any line of code can be a point of failure

All new projects are custom built. That said, every line of code is unproven until it is proven. In order for that to happen, every line must be tested first. While this theory is great, in the real world this is impractical.

Dozens or thousands of possible inputs, outputs and dependencies will affect each line of code. This also goes both ways in that the code may impact the inputs etc. as well. Tracing down unknown factors affecting the code will take time.

Each line of code is a part of the grand ecosystem that is the project software itself. As each part needs testing, the overall software project undergoes similar testing as well.

Aside from general testing timelines to any given project, factors governing the complexity of the project must be accounted for over and above. If the software project will literally affect lives of humans, it will need to be vigorously assessed over and over (smoke testing, automated regression testing, coding standards, unit testing, design and code reviews etc) all of which, over time, will improve the quality of the software.

To be honest, all too often, software testing is the ‘rushed’ phase of the project. At some point in time it will be determined that continued testing of the software is weaker to the bottom line than the resulting errors that may come up post release. You see this quite often with commercial releases of software with companies knowing full well there will be bugs brought forward.

User input matters

It remains the top factor in project continuance. Lack of user input reasons can include:

·        Software is being promoted by management while the business users had no buy in from the start

·        The users who are affected are too busy to offer frequent feedback and feel they have more important things to do

·        Relationships between the company users and IT team are poor

It goes without saying that a lack of user involvement with the design team will lead to project failure. The user should be an expert in their domain and given authority to make the decisions necessary to carry the project forward to meet timelines.

Translating vision to reality hits bumps

Truth told, it isn’t until the users actually see what the software looks like in front of them that they know if they like it or not and more importantly, understand what they see and are using.

This is especially true for new software that has never been used before.

The average project experiences about a 25% change in requirements along the way from the original proposal agreement. This is where the infamous ‘scope creep’ problem shows up. Users will see that they will need more complexity as they realize the potential use(s) of the new software.

Software is affected by external factors

Even though software can be considered ‘mindware’ and a physical form, it is still affected by external constraints. Hardware, integration with other software, legacy software, government regulations, scalability, performance criteria all play a heavy-handed role in a successful delivery of the project.

It is next to impossible to identify and prepare for every one of these external factors. Something seemingly simple as being able to support all web browsers increases the probability of an error(s) surfacing significantly. Adding support for multiple versions of each of those browsers has now given rise to an exponential increase in complexity of programming.

The science of estimating is not a science at all.

We now know that projects are custom built and complex, they will have scope creep, they will be affected by external factors. Given this information it is no surprise that estimating a delivery date for any given project is not written in stone as much as it is a goal to achieve provided everything remains as it was during the initial scope and planning of the project agreement.

Agile methodologies have helped tighten up timelines, it is not the solution for all projects. Projects involving complex external interfaces or new technology will create more difficulty in holding true to a given timeline from concept to delivery.

To sum up

Software development projects are similar to icebergs. 90% of the work completed is not visible. The vast majority of the complexity involved is below that ‘waterline’. Before assumptions are made, it is always best to keep lines of communication open to be aware of challenges faced on each side.