In 2011, Marc Andreessen famously declared that software is eating the world. He talked, in that article, about software companies making inroads into all domains in the years to come. He also talked about software based organizations like Amazon displacing traditional ones, like Barnes and Noble. In the six interceding years, this trend appears not to have slowed.
The upshot is that you simply can’t escape software development. Startups and Silicon Valley have known and felt this for decades, of course. But it’s spread so far and so wide from there that now the stodgiest of industries feel the pressure. In the heavily digital reality of 2017 even the IRS has a mobile app. Yes, you read that correctly.
Any competitive modern company has to become, at least to some extent, a custom software development company. Whether they source those efforts purely in-house or farm them out to agencies and custom software company, the business of software development is everyone’s business. So we all have to come to grips with the reality that every company has a vested business interest in understanding how to improve its software development efforts.
Also read: Trends Shaping the Future of Custom Software Development
If you go looking for general advice on how to improve application development, you’ll certainly find it out there. But a lot of it dives straight down into the weeds of design patterns and performance optimization. I’d like to offer a different spin on improvement suggestions, however. Let’s take a look at some business-savvy technical practices that can improve your app development. Make no mistake — these are specific technical practices. But you can trace a clear path to ROI for them.
Avoid “Not Invented Here Syndrome” with Judicious Use of Third Party Tools
At some point in your career, you’ve probably brushed up against not invented here syndrome (NIHS). This happens when a group prefers to write its own tools, perhaps as a matter of pride, rather than use (generally better) ones built by outsiders. Perhaps a custom app dev agency decides to implement its own CMS for its public website. Or maybe a Fortune 500 company with a large internal staff writes its own quirky internal logging framework, rather than use an open source one. Whenever you see it, you can recognize it by the whispers of “you know, we could just use X and avoid all of this nonsense” that follow in its wake.
As software developers, we love to build things. This holds doubly true when the alternative is a confusing interaction with someone else’s tool. “Ugh, I don’t understand all of this XML configuration stuff — I could write my own logging framework faster than I can figure this out.”
Resist this impulse if you want to make your app development outfit best in class. You need to focus your energy on solving problems that your users have — not problems that your developers have and want to solve by building their own tools. At some point, you must ask yourself whether you want to build the 8000th logging framework the world has seen or whether you want to build your app.
Some people will argue that you can go overboard with this, trying to use third party stuff for everything. And, that’s true. You can make this mistake too. You walk the line by favoring existing solutions, but quickly recognizing when you face a unique problem.
Also read: 5 Reasons to consider Software Product Development services for your Business
Release Features Instead of Products
Using third party solutions has an obvious ROI arising from making development more efficient. But the ROI on releasing features comes in the form of risk reduction.
Historically, software companies would unveil some massive software release the way a theme park unveils a roller coaster. They’d show it to the world with much fanfare, and then quietly work for a year or two on the next one. That’s unavoidable in construction, but not so much in software. And, in software, that approach creates a ton of risk. If you spend two years writing software without releasing, your entire effort is waste, right up until the moment that you release and start realizing success. If someone were to pull the plug when you were 95% done, you’d realize 0 value.
To mitigate that risk over the years, teams have moved from big bang yearly releases to quarterly, monthly, weekly, and even daily releases. And then, to get even more granular, they’ve started releasing things at the module and feature level. Think of this in terms of a release maturity model.
You want to get to that feature granularity to mitigate risk. You can use feature flag management to roll single features out at a time and even to roll them back if things don’t go well. Do this, and you get to market much faster and with fewer headaches.
Robust Automated Testing is a Must
Speaking of risk mitigation, let’s talk testing. Just as the years have seen a dramatic advancement in release maturity, software testing has come a long way. We no longer live in a world where you test software only by launching it, clicking buttons, and seeing what happens.
Your team should strive to build an automated test suite that creates a conceptual test pyramid. This means that you write a ton of granular, automated unit tests. Then, you write a decent amount of integration tests that exercise the interaction of components of your codebase. And, at the top of the pyramid, you have a small number of tests that prove how it all fits together.
But that’s only a good start. You should also automate non-functional testing considerations. This includes load testing, stress testing, and general performance testing.
Without automated testing, you start at square one every time you do a release. Your QA group will have to test the new stuff, and then laboriously re-test all old behaviors. Or else, they’ll skip that last part, exposing you to risk. With a robust automated test suite, you can focus on the new stuff and on exploratory testing.
Instrument Your Application for Business Flexibility
I’ll conclude with something that should appeal equally to business-minded folks and technophiles. I’m talking about instrumenting applications for business decisions. From a technical perspective, it’s an interesting architectural challenge and a cool way to gather data. From a business perspective, it removes formerly technical constraints and allows you to iterate much faster on strategy.
Consider, for example, A/B testing. Using feature flags you can release a piece of software in which you show half of your users one screen and the other half a different variant. For instance, maybe you want to see which “buy now” page results in more purchases. Instead of convening focus groups and guessing, you can just run an experiment in your production code. When you have your answer, you can phase one out entirely in favor of the other.
And, beyond this style of split testing, you should make sure that your application produces plenty of actionable runtime data. Look to track things like user engagement, frequency of errors or issues, outages, and the like. Doing this lets you respond more quickly to problems, and it also lets you make intelligent business decisions based on actual data from your app.
Staying Ahead of the Curve
You can improve your app development game in all sorts of ways. As I mentioned earlier, some exist in the technical weeds and, in spite of that, help you realize very real gains in efficiency and productivity.
But I chose to focus on business-oriented ways to improve your app development game and to lead in by talking about software eating the world. 6 years after that quote, software continues to devour the world at an amazing pace, taking over and fundamentally altering every other industry in the world. And that didn’t happen with efficiency gains resulting from design patterns and frameworks. It happened because app developers learned to respond to business needs in those industries.
So if you want to improve your mobile app development, raise your technical game. But raise it specifically in ways that improve the bottom line.
