Why does software application development take so long? Why is it so expensive? Why is my team consistently failing to meet project milestones? Despite all the advances in technology, these are questions we hear all the time. Some might say that there just aren’t any shortcuts – I would disagree, but more of that later.
The common reasons why software takes so long can boil down to five key factors:
In our experience, this is critical and too often ignored. In the same way that you have an architect design a house, you need to understand the basic structure of your software application and map out the details of the different business processes it will need to perform. To continue the analogy, you don’t need to specify where every light switch is going to be, but you do need to know the fundamentals such as the number of floors, rooms, bathrooms etc.
Even if you have a good idea of the software application you want to be built, without exception all our clients tell us that the upfront planning process is time well spent, as it gives the business owners and the technology experts the space to explore the best way to deliver specific functionality.
This can also be a low-risk first step of any project. The business needs to work closely with your chosen development team to build the deliverable. If the relationship works well – commission them to build the application. If the chemistry isn’t right, you still have a valuable deliverable that you can hand over to any software development team.
Changes are a very common occurrence when building software – especially if there has been a minimal definition of business needs upfront. Some changes are easy to accommodate, and others can be a lot more complex. The better the job that is done in point 1 above, the more you can mitigate the impact of any changes. The challenge is the way that software is traditionally built. If you make a change in one part of the application, you need to do comprehensive testing to ensure it doesn’t affect other parts of the application. In practice, this creates a significant iterative process that the development team must go through if they are using traditional software development techniques, this frequently means missed milestones for the project.
The larger the development team, the more of a challenge this is. A formula often used in the development world shows that if you increase your team size from 7 to 9, you almost double the number of interactions required between team members. You will find many views on what the ideal team size is. In our experience small, focused teams are much more effective than large teams. The general industry view seems to be that 9 is a large number.
As important as the Development Team, is to have a strong Product Owner. This is the person who acts as the liaison between Development Team and the business.
there is an important misconception amongst the business community, that software development code is easy to read for another developer. Whilst well-documented code can be read by another developer – in practice given the volume this seldom happens and often, people end up building new code at some level (industry sources suggest this can amount to 39% of a developer’s time). What is clear is that each Development Team will have their own way of creating code and establishing its own nomenclature and standards.
If you lose members of your team, they need to read the code that has been created. To give you a sense of this challenge – a typical iPhone application can easily run to 900 pages of code if you were to print it out. Facebook would be over 1M pages. Consequently, changes to your development team can have a very big impact on how long a project will take if a new developer has to read through and digest hundreds or thousands of pages.
The size of your code base – this is a fundamental challenge that not only slows down software development projects but makes them more likely to fail and if they do succeed, more complex to maintain. It is also one of the biggest barriers for innovative start-ups with a disruptive idea – because of the costs required to create and manage a large base of code.
Not only that but creating and managing a large base of code is complex, time-consuming and full of unpredictability. The longer it takes to build, the greater the risk that there will be changes in your development team and the more complex and expensive it will be to support and maintain once you have completed the project.
If you can reduce the size of the code base significantly, it will be faster to build, easier and faster to maintain and update. All of this reduces your risk, cost and sleepless nights. Imagine being able to build software that has a code base of at least 40% less than using traditional software coding.
Some will point to the new low-code, no-code tools. These certainly help in reducing the time it takes to build the software. However, they tend to automatically build the same amount of source code in the background. This simply shifts the challenge to the point when you go live as you still have a large base of code to support and maintain.
The SCAD Software approach is fundamentally different. We have a technology framework that makes extensive use of metadata (think of data stored in a database). We use this in place of a programming language that is prone to multiple updates during any given year.
Using Metadata rather than traditional programming languages, means we can expect to reduce the size of an application by at least 40%.
It also means we future-proof our clients from changes in the underlying technologies, which reduces the risk of technical debt.
This is a much faster way of building Customised Software. It also leaves you with an easier and lower cost application to maintain. This is how we can deliver software on average 75% faster than using traditional software coding.
1. Establish your Business Requirements up front and at a fixed price
Invest quality time working with your Development Team to build a proper set of business requirements. This means thinking through as many of the business permutations as possible. Define the reports you want from the system as this helps validate whether your Database will be designed in the right way. This will require an iterative process with a core team of experts from your side and the development team. Ensure the team have the space to invest in preparing thoroughly for this phase of the project. You don’t want it to drag on – but you do want it to be a high-quality set of interactions.
Once you have this, ensure you get a fixed price from your Development Team. This will have a caveat that if you change the specification, they will need to come back to you for further discussion. However, this should not include them returning because they didn’t realize the scope initially.
Talk to your software development partner – the smaller the code base, the easier it will be to manage and update going forward. It is vital to consider not just your build cost, but also the cost of ongoing maintenance and support. If your development team can have the same people that built the application be involved in the ongoing maintenance, we would suggest this is an added advantage.
The relationship you have with your Development Team is critical. Senior Business Leaders will often say to me that they always want their Development Team in-house so that they can eyeball them on a Monday morning. Whilst I can concur with this sentiment, we don’t believe this is always the best option as you will have the ongoing cost of recruiting, managing, motivating and developing that team. Not only are Development resources at a premium at the moment, but as you can see from the table below from a pure cost per head, there are cheaper places to look.
Outsourcing is becoming increasingly popular and to do justice to this topic would require a separate article. The one word of caution we would mention here is not to be seduced solely by lower day rates.
We have spoken to too many customers who have reported that whilst the upfront cost was lower, the overall project ended up costing them a lot more. The important considerations are cultural fit, communications and a partner that isn’t so much larger than yourself that you don’t get the support you need,
Experience suggests an optimal solution is an outsourced team with a similar culture, with local management in your country as the primary interface and a commercial agreement that is fixed in the initial build and that both sides are heavily incentivized to ensure the application’s ongoing success. This should enable you to find a solution that commercially makes sense and is the right team for your business.
We believe this relationship should be seen as a Partnership, where both sides share the project’s cost and risk. We would define success when you view your Development Team as a logical extension of your business.
There is a fair amount of research that has been carried out looking at the optimal size of a Development Team. Industry sources suggest that above 10 is too many and less than 3 is too small. Ultimately it is a fine balance between additional resource capacity and the communications overhead on the downside. Some people would suggest 7- 9 is the right number, clearly depending on the size of your project.
We are strong advocates for very small focused teams. With a strong Product Owner to provide the interaction between the business and the development team and a strong Scrum Master (a person who leads the development team, removing obstacles, and ensuring they are efficient as possible), you can create a very dynamic and agile team.
The title of this article in part has been the driving factor in the creation of SCAD Software. For the last 20 years, we have believed that some of the fundamentals of the way software is built and the commercial models around have been flawed.
We have developed a way of building software, using established industry-leading technology and methodologies that enable us to deliver software 75% faster than traditional software coding. The reason being we reduce the size of the source code base by at least 40%. Not only does this provide many technical benefits, but it also enables us to change the established business model. We feel it is important to provide a fixed price on the back of a clear set of requirements and share some of the risks of the software build with our clients.
These are big claims. However, we have a track record to support them. The table below illustrates some of the projects we have been involved with and the time it has taken us to build them.