"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 (http://www.flickr.com/photos/alwarrete/), original photo]
Did you like this? Please share:
The Lost Year: A Failed Experiment to Switch Away From Mac
Fed up with the Apple Keyboard, I bought a ThinkPad, installed Linux, and promptly decided that I hated computers.
Maker's Space, Manager's Space
The Grand Remote Work Experiment: A Retrospective
The COVID-19 pandemic has lead to an unexpected experiment in remote working. What has worked and why?