Cheap, Fast or Good Software – Pick Two. Pick Right.
There is a lot of buzz out there about the pace at which software is being made today. Forty-eight hour hackathons, endless “sprints” pushing developers to their breaking point to crank out new features, and countless nights trying to finalize “just one more” feature which was added to the project scope at the last moment. Many of us have been there. The issue is that the prevailing perception appears to be that cheap, fast code is “good enough” for everyone. However, that is not at all the case and here we intend to quickly describe why cutting corners is simply not good for business regardless of what the up-front tangible costs may be.
The problem first seems to occur when the “business” side of organizations make their push to generate new revenue through the creation of new features or products and, at the same time, insist on cutting back drastically on programming costs by outsourcing to far less experienced developers. In such a situation, the pressure is on from the get-go to deliver as fast and cheaply as possible. However, what they don’t realize is that for every $100 saved in costs or gained in revenue by launching a few weeks early with this “good enough” code created by comparatively cheap novice labor, your company will end up spending $1000’s more at some point in the future when conditions necessitate hiring senior developers to patch, refactor or outright replace that code. Believe me, it will happen.
This type of thing is a problem we’ve been seeing more and more of and one that we have been hired to fix many times now: software running just fine for years at a time even, but then completely breaking down or getting hacked at some point because of poor coding, bad architecture or insecure practices brought about by business pressure to launch fast while drastically reducing development costs. You can’t possibly expect positive results in such a scenario in the long term. In some cases, these problems can easily become catastrophic if not fixed immediately and most often they will require capital outlays in the range of tens of thousands of dollars (or more) to effectively remedy the situation. So, in raw economic terms, that $5000 you saved a couple years ago during development just became a $50,000 expense to fix a broken or insecure product.
What Can Be Done To Make Things Better
Don’t fall into the “cheap and fast is good enough” trap. Insist that software is developed right the first time around and stand strong when there is pressure to do otherwise. Unless your particular organization is perfectly fine with the increased legal liability and the ruinous effects on their reputation that insecure, buggy software brings about, it is far wiser to devote a few more senior development resources and budget some more time for your coding and testing regimen up front. Also, get some standardized processes in place if you don’t already have them. Software development is no longer the wild west full of rogue cowboy/cowgirl coders – someone is going to have to support that product, so be considerate if you care at all about your career and professional reputation. Best practices are named such for a reason.
While I’m on the subject of standardized processes and best practices – you are testing…right? I’m talking the full gamut – unit, functional, component, integration, etc. – whatever is needed based on the scope and scale of your application. If not, the problem is even bigger than what I just described and it’s time to completely reevaluate your development practices (something we’re quite good at doing for you, by the way, to get you on track for success). Even in the era of “lean” teams, startups and businesses, there is absolutely no excuse for putting your users at risk with insecure, buggy code that wasn’t tested and reviewed adequately before a launch or release.
So, after all is said and done, here are a few tips to get on the path to software development success:
- There should be at least one very senior development resource for every three to five junior or mid-level ones on your team. This is to ensure that all code is, at the very least, reviewed by someone with enough experience to know when something isn’t quite right.
- Test, test and re-test. At the minimum, functional testing (black box or white box) is needed. But, we almost always advocate for a multi-tiered approach consisting of unit testing through end-user acceptance testing for every new feature at different intervals. You need to include time for this in your schedule, or accept that you’ll be producing a bug-ridden product which will ultimately be reviled by your users or clients.
- Don’t cut corners for the sake of saving time or money up front. You need something delivered rapidly? Either plan to spend a little more money to get it done right or plan on producing a vastly sub-par product. Need something done cheaply? Then either give those junior developers you just brought on ample time to get up to speed or plan on and budget for your product needing a complete overhaul at some point in the near future.
- Processes. Too much becomes a bureaucracy, too little and it’s utter chaos. Find your particular balance and put in place just enough of them to get everyone on the same page. Standard processes need to be documented, even if just in a quick bulleted list that is distributed to new team members. While you’re at it, do a little research and see what other organizations have in place or hire a company specializing in software project management, like us, to set your projects on the road to success with a set of documented best practices tailored specifically for your organization’s needs.
I’m sure some of you reading this will have your own stories and tips, so I encourage you to share them in the comments section.