In software development, the premise of good, fast, and cheap is difficult to achieve. Can we get all three? Is it possible to achieve a balance? We will tell you about it here.
Many of us who work in the software industry, when we start working on project quotes, consultations, or estimates, have faced an almost inevitable must from the market: developing good, fast, and cheap software. Is it possible to have these three variables at the same time? Is this idea utopian?
In order to answer this question and see the feasibility of this postulate, it is important that we first review two key ideas.
What price do you put on an intangible entity?
Software is an intangible product; we cannot see it, nor know its goodness until it is finished. Putting a price on a software development is something complex (unless you buy packaged software instead of custom development), not only because of the subjectivity that exists of its value (based on many criteria), but also because of the existing differences on whether the project is easier or more complex to carry out.
Estimates, a pillar for success
Given the juncture of the intangible, making a correct estimation –and as accurate as possible, given that it is an approximation–, is very important so that budget overruns and time wasting are avoided.
Bearing in mind that a good estimation is the foundation for the success of a development project, we cannot ignore the fact that every estimation is translated into man-hours. The professional quality of the team members and their experiences are directly proportional to the cost of the development.
In short, knowing that the estimation, planning, and execution of a project are carried out by people, we can deduce that the quality and expertise of the professionals affect the cost of a project.
The good, the fast, and the cheap
Having understood that software is an intangible entity whose price is difficult to define, especially if there is not a clear estimation, let’s go on to explain the attributes of the good, fast, and cheap and how it is possible to combine them but not have all three simultaneously.
1. Good and fast
It is possible to do something good with speed. To achieve this, it is essential to make a good estimation and then have a good execution plan of the project so that the speed does not affect the quality of the result.
The key to achieving quality and speed lies in the people working on the project, who must be qualified enough to tackle the project. Remember that the quality of the professionals is a determining factor in the cost.
Take into account that speed can be counterproductive to productivity: In theory, a team (and its members) reaches its peak of production in a given time and maintains it until the end of the project. The higher the speed, the shorter the time the team will be at peak productivity.
Likewise, coordination will also be a factor to analyze: The more people working in parallel, the greater coordination required (perhaps more people should be added as coordinators).
The good and fast applies especially for critical or key projects, where the quality of the product must be guaranteed at all costs. In these cases, it is necessary to have teams with a lot of experience. If this is the case, the solution will be good and fast, but also expensive.
2. Fast and cheap
Here is the second of our combinations of the three variables: The simplest way to do something fast and cheap is to do it without quality or, at least, be aware that it may be inferior to the desired one. We could sacrifice quality up to a point, as long as the software does not handle critical information, or it does not depend on some sensitive part of the organization.
For speed effects –since in the future the quality of the application can be improved–, it is possible to go into production with the key features for the product to work. In these cases, this is what can be done:
- Minimize the quality of the code
- Simplify its usability
- Leave the code reviews aside
- Reduce quality controls and testing.
By doing this, we will most likely get a tool with a basic functionality, but we will not get a 100% satisfactory product. Its usability may not be the best, as well as the quality of the code, and its extensibility (possibility of change or extension) and reusability may be problematic.
This applies to demo applications, concept testing, non-critical software, or any application that is scalable or extensible over time.
3. Good and cheap
I give you the last of our equations: If the client wants a good and cheap solution, he cannot expect a quick delivery.
Something good and at an acceptable cost can be done but to the detriment of time. Basically, if there is time, it is easier to plan –since there are not so many tasks in parallel and not as much coordination is required–, and the productivity peak of the people involved is going to be at its peak for longer.
Getting something good and cheap is suitable for projects where time is not a critical variable, as well as for incremental projects or with teams with partial times (that have internal projects or initiatives).
To Sum Up
In software development, the postulate of software development good, fast, and cheap is very difficult to achieve. We will always be able to get two of them, but we will have to abandon the remaining one. In this way, it is possible to achieve quality in stipulated times and at a reasonable cost; it is only necessary to know how to find the balance between these three variables, knowing the implications and how they interrelate with each other in order to reach that balance.
Approaching this equilibrium will be possible as long as the estimations, the coordination, the team selection, the working methodology, and the use of tools and technologies are the right ones.
Have you achieved a balance among these variables in any project? How did you do it?