Here’s how to make the decision.
Admit it: Sometimes it’s more important to get a software development project done fast than to get it done “right.” Maybe it’s a storefront for an application that needs to be done by Christmas, or a mobile app scheduled to support the World Series. If that’s the case, it’s more important for the project to launch by a specific delivery date; a great storefront app that comes out in January isn’t going to help anybody. Maybe the opportunity cost of delaying while the software is perfected is too high.
Good software tools can help you minimize the tension between “done on time” and “with the quality that makes software developers proud” (and we like to think that Mendix’s platform is among them). Yet, sometimes, you really do need to choose.
Assuming you are faced with such a situation, here are some factors to consider.
What’s forcing you to choose? There are always gating factors for any development project, but what they are helps determine the best course of action. “Very early in a project plan, you identify if the project is constrained by time or by resources,” says Doug White, a New Jersey-based business intelligence and solutions architect. “For time-constrained projects, you continue the decision tree based on risk of failure, penalty of missing the deadline, and priority of this project. For resource-constrained projects, explore the cause of the constraint (builders’ availability, buyers’ ability to fund – to build and later own), and also, the priority and opportunity cost of significant delay.”
What is the application’s purpose? While programmers might not always want to admit it, you don’t always have to go full out for everything. “’Fast’ may be necessary to meet external or even internal deadlines or free up resources for an upcoming priority effort, or to take a bullet for the client or a new client, to bail them out of a bind,” White says. “’Good’ is for the strategic, flagship efforts: the transformational technologies and business solutions. Also included here would be core utility functionality, where accuracy and / or reliability are of utmost importance.”
In addition, some applications more readily lend themselves to iterative approaches, says Pearl Zhu, president of Brobay Corp., a San Francisco-based global e-commerce and procurement service provider. If it’s a new app to serve the end user and optimize customer experience, then use Agile methodology to improve iterative communication and collaboration, and provide faster delivery and customer satisfaction, she says. “Continuous improvement is key.” On the other hand, if it’s infrastructure modernization or enterprise architecture-level integration, or application life cycle management from consolidation, rationalization, to optimization, “get it done quickly” may only be a Band-Aid solution. To build software to last, Zhu says, diagnose the root cause and leverage the best fit solution, not necessarily the fastest.
Another factor to think about is: If the application gets done quick and dirty, what’s the worst-case scenario if it fails? A website that might look ugly for a day or so is a different situation from crashed airplanes or things exploding.
“If I’m going to be forced to ship crap code, I don’t want to wake up in the morning to hear a train crashed because the software for the switching station failed,” says Judy Tyrer, who switched to game development after being told by a previous employer that she shouldn’t worry so much about the bugs because she’d have two years after shipment to clean them up. “At least in gaming, the worst thing that can happen is some gamers have a bad night.”
“If I was working on a small brochure site, then ‘Fast’ will trump ‘Good’, as long as the result met the client expectations,” says Peter Connolly, technical director for KP Direction, a Layton, Utah-based web development firm for media companies. “If I was working with on-engine software for an airline engine, ‘Good’ just won’t cut it. There, we had to be perfect in every respect, even if it took a little longer.”
How long will the application be around? It may be that the time is short because of external factors, such as needing to respond to a competitor or being around for the Christmas shopping season.
But unless it has a limited lifespan, chances are you, or someone else, will be touching this app again at some point. The Mythical Man-Month, the seminal 1975 book on software project management, is laughably dated in places (PL/I?), but it’s still one of the best sources for how to manage programming projects. “Plan to throw one away – you will, anyhow,” Frederick Brooks advises. “The only question is whether to plan in advance to build a throwaway, or to promise to deliver the throwaway to customers. Seen this way, the answer is much clearer.”
Even if you plan for the first version to be a throwaway, ensure that the software is not of such poor quality that it poisons the well for future versions. Stephanie Myara, former manager for a software company she understandably didn’t want to name, described how the company decided to develop a program with both free and premium versions. Due to time constraints it didn’t fully implement the bug fixes and cut some features from the free version. Consequently, while the first, free version of the software came out on time, its reviews were so awful that few people ponied up the money for the premium version, she says.
And remember that even software that’s intended to be thrown away has a habit of sticking around. “If it is to be throwaway, my advice is to have that in writing in many, many locations,” says Sharon Evans, a Winnipeg-based former developer and architect who is now a consultant. “We all know the lifespan of throwaways, so ensure that it is documented and can’t cause any repercussions.”
Chances are, though, you still will encounter times when you need to make sacrifices for speed-of-delivery. But there’s ways to do it while maintaining quality, developers say.
Cut features. “Release quickly and build for the long haul,” is one option, “which we accomplish by cutting down the feature set to the minimal features required for success,” says Jessica Zeckel, an Indianapolis-based software developer for a medical device company. “If we can do a follow-up release with a couple more features in another year, then it’s not so much of a burden to not have those features in the first release.”
“It’s better to get it done right and not have as many features than to try to pack all the features into a first release and either take forever to do it or suffer quality problems,” Zeckel says. “Maybe your first release only satisfies 50% of your target customers, but if you can keep doing feature-added releases on a quicker cycle, then in a couple years you may have 90% of the target customers satisfied.” In addition, by waiting until after the first release, you get feedback from your customers about what features they think are important, she says.
Prioritize. “What are the essential (bare-minimum) features required for this product to 1) Function correctly (according to its goals)? 2) Sustain its necessary level of maintenance? 3) Be commercially viable/competitive within its market-space?” says Brandii Grace, CEO/Chief Creative Officer for Transform Entertainment, a Los Angeles-based gaming company. “Once these things have been decided on at a highlevel, you have your list of features required for a ‘minimum viable product’ (MVP). You must complete the above things with sufficient quality to have the product considered ‘complete.’”
You could also have a list of nice-to-have “stretch features” to add should the base product be done in time – but make sure you add them to a copy of the base product, rather than to the base product itself, in case they’re buggy, Grace recommends.
Let it be ugly. If you’re doing something quick and dirty, now is not the time to worry about optimization or crafting the most elegant code. You can fix that up in a later round, if there is one. “I’m willing to discuss feature tradeoffs to speed up or slow down the development time, but how ugly I leave the code is my decision, just like which data structure I use is my decision,” says software engineer Beth Andres-Beck. “That expertise is part of what I get paid for. If you can’t trust your developers not to prioritize over-engineering technical solutions rather than producing useful features, the problem is the developers.”
Look for ways to leverage existing code or use off-the-shelf products. Instead of reinventing the wheel each time, think modularly and design for reuse. For example, one client wanted to show his investors a concept application to showcase as a hardwired prototype app in two weeks, with no constraints on what goes below the hood, says Sridhar Dhulipala, co-founder at Bizosys Technologies in Bengaluru, India. “One such feature was Search. We were given some dummy data and files. We had a ready-to-use Search as a Service component (accessible via REST API) running on a multi-tenant cloud infrastructure, so we just gave him an interface to upload content to it. Two weeks later, when he went to demo and showed a ‘real working app,’ the crowd was floored, asking, ‘How did you get it to this level so fast?’”
Estimate schedules correctly in the first place. Part of the solution is to make sure that you accurately predict how long development will take. For example, The Mythical Man-Month recommends that fully half the schedule be devoted to testing, and only one-sixth to coding. “Reasonable work weeks, testing, and code reviews aren’t optional,” agrees Andres-Beck.
Similarly, Grace’s “MVP” means your schedule must include sufficient time to complete all of these things… plus a buffer of 10-30%, she advises. And this isn’t just because of the “Scotty factor,” by making people think you accomplished miracles by finishing the work more quickly than scheduled. The fact is, people aren’t perfectly efficient, and stuff happens.
The Mythical Man-Month describes one manager who discovered his programming teams were taking just about twice as long as estimated for everything. When he had them log their time, he discovered why: His teams were actually programming only half the time. “Machine downtime, higher-priority short unrelated jobs, meetings, paperwork, company business, sickness, personal time, etc. accounted for the rest.”
On the other hand, this could come back to bite you. “Go ahead and use cloud, Agile, and any other techniques to manage risk and increase productivity, but don’t be surprised when your new level of performance is taken for granted and a senior stakeholder becomes convinced that someone else can do more in less time and for less money,” warns Richard Barton, IT Enabled Business Change at PA Consulting Group in Guildford, U.K. “The need to manage stakeholder expectations and help them make well-informed choices does not go away for very long.”
Eventually, says the Mythical Man Month, estimating will be on a sounder basis. Until then, “individual managers will need to stiffen their backbones and defend their estimates with the assurance that their poor hunches are better than wish-derived estimates.” After all, it notes, “The bearing of a child takes nine months, no matter how many women are assigned.”