Fast, Cheap, and Good; How to get all three.

High-quality product can be created quickly and cheaply if the available resources are utilized wisely.

Posted by Tejus Parikh on March 24, 2014

Rapid application development gets all three

Rapid application development gets all three

“Fast, cheap, and good; pick any two” is a standard axiom of project management. Software development in innovative markets is one area where this no long holds true. Teams in this environment need to deliver on all three and these are some tips I’ve found make it possible.

Make engineering easy

Building good software is an iterative process. Code, build, test, repeat till it works. Get tools that improve development speed and reduce the cycle time. Slowing down the iterative cycle has a direct impact on the length of the project and the bottom line, making cheap an impossibility.

Easy engineering also improves quality. Quick turnarounds focus the developer’s attention, whereas long builds have them drifting to their open reddit tab. Focused developers make fewer mistakes.

When starting a new project using languages designed for rapid application development, like Ruby on Rails is ideal, but almost any software stack can be reworked rapid cycles. We’ve nearly eliminated turnaround time in our Java application with JRebel and Intellij IDEA.

Enforce quality standards

The myth holds that quality is time in software engineering. Like most myths, this is untrue. Well understood design patterns, open source libraries, and good tools make building software the right way easier than building it wrong. Initial investments to define a programming philosophy, rules for using libraries, and code structure standards do much to make software easy to write, maintain, and expand. Using a pre-built framework that predefines those dogmatic decisions saves even more time.

Allowing poor quality to slip into the codebase should not be allowed since it will quickly turn the project into quicksand. It is the responsibility of the senior and most experienced members of the team to police quality and they should be given the latitude to do so.

Emphasize automated monitoring over automated testing

Knowing that something is wrong before the customer does is critical in running a production system. Nothing kills timelines and efficiency than firefighting in production.

One approach to prevent production defects is high coverage automated testing. I’ve written at length about my thoughts on automated testing. For this discussion, the problem with automated testing is it’s “imagine a perfect sphere” approach to software quality.

The real world is not a perfect sphere. Users will find paths to the system that the developer could never imagine. Servers and infrastructure will fail in strange ways that will be new to even the most experienced sys-ops.

Monitoring with tools like Graphite, Logstash, Nagios, Kiss Metrics and New Relic can help immensely with the identification and triage of the problems that arise when real people use the system. It’s a small investment to gain the same knowledge that automated tests provide.

Use the application like the user

Issues found in production are more expensive to resolve because of all the necessary communication. The customer care group needs to talk to the user and the developers, tickets need to be written and timelines communicated. Even a streamlined process will incur some overhead. Developers using the application will spot these errors long before the products get into the hands of the users. They would have noticed the button didn’t work, fixed the issue, and moved on with nary an email sent.

If computers, not people, are the real users of the product, then this is the one area where I’ll support automated testing. Building an API without programs to test it is irresponsible.

People are expensive, things are not

All these tips really are about one thing, spend on “stuff” in order to save on people. Technology gets cheaper while people get more expensive. If you want to maximize all three project management axises then focus on getting the best out of the most valuable part of the team.

[Photo credit Álvaro Campo García (, original photo]

Tejus Parikh

I'm a software engineer that writes occasionally about building software, software culture, and tech adjacent hobbies. If you want to get in touch, send me an email at [my_first_name]