3 Principles for Reducing Development Costs Without Compromising Speed or Quality

Bidhan Baruah

October 20, 2020

3 Principles for Reducing Development Costs Without Compromising Speed or Quality

Marc Andreessen’s observation that “Software Is Eating the World” is as true today as it was when he published his famous Wall Street Journal essay nearly a decade ago. The idea that “every company needs to become a software company” is not a trivial undertaking regardless of their industry, age, or size.

The pressure to make high-quality software in less time is not new, nor is the pressure to do more with less. And the perceived tradeoffs between cost, quality, and speed seem impossible. Here are three principles we use with clients when building software on-target, on-budget, and on-schedule.

Relationships Before Requirements

If speed matters, then it’s worth remembering, as Steven Covey says, that “business moves at the speed of trust.” We believe that’s also true for software development. Trust always affects two measurable outcomes: speed and cost. Levels of trust are based on the quality of relationships. Strong relationships increase trust. Trust increases speed. How? Through closer collaboration and rapid feedback.

Close collaboration built on trust fosters the exchange of ideas. Mistakes aren’t hidden. Barriers are quickly identified. Silly or not-so-silly questions are safe to ask. Developers and stakeholders can talk directly rather than playing the telephone game through layers of management.

Productive relationships lead to rapid and frequent feedback. The easiest way to avoid rework, getting off-target, or catching errors is by rapid, frequent feedback. Challenges are inevitable when developing software. However, when relationships are strong when trust is present, and when communication is open, small issues are quickly spotted and addressed they can fester.

Design Before Development

Humans are visual beings, and we like to see things to understand them. Design thinking and design practices make abstract ideas and concepts concrete and visible. Napkins and dry erase markers are faster, cheaper tools for getting clear than jumping straight into code. Skipping design and going straight from concept to code.  We use design to get clear on two critical factors: business value and user goals.

Functioning software isn’t enough, even if it’s pretty. It should improve business by increasing revenue, decreasing development costs, or reducing risk. We first want to understand how the software will increase productivity, save time, simplify operations, create competitive advantages, or ensure compliance.

Equally important is understanding user goals. A bad user experience is bad for the business. Software that doesn’t create business value or isn’t used by people is a primary cause of waste. It’s easy for time and money to slip away when project leaders and developers are operating in a grey area. The best tool here is your eyes and ears. Observe people in action. Listen, ask good questions, and listen to some more. Curiosity and empathy are more important than knowledge at this stage.

Before the first line of code is written, we first get clear what needs to be done and who it needs to be done for. Sketch it out. Map it out. Talk it out. Create wireframes. Create a prototype. Then it’s time to code.

Adapt to Change Over Following a Plan

Dwight Eisenhower said, “planning is everything, the plan is nothing.” As a custom software development company, we strongly believe in planning. Why? So that we can effectively adapt to the rapidly increasing rate of change. Market conditions and solution options are never static. Customer expectations are rapidly evolving.

Through planning, we break work down into smaller parts of value so we can develop, test, and deliver them every two weeks. These rapid cycles of development and testing help catch issues early, when they are easier and less expensive to correct. Problems caught today cost less to fix – and are more quickly remedied – than problems caught tomorrow.

We expect change, and even welcome it. Working in shorter cycles allows us to produce incremental yet meaningful and verifiable units of value. Each day’s work is reviewed and micro-planned. And every two weeks we show verifiable work progress. Frequent testing allows developers to keep projects pointed toward dynamic and ever-evolving goals.