Apps Can’t Fly (But We Keep Trying to Make Them)

What if I told you your car could be a plane, too?

Just strap a couple of wings to the side doors, drive to the top of a hill, and start barreling down as fast as you can.

If physics plays along, you’ll be known as Maverick from that moment on.

Of course, you’ve perfectly attached the wings, calculated their position, and crafted the most aerodynamic shape. You even tweaked the engine for that extra push. The whole thing looks like an engineering marvel. But in that crucial moment – when you leave the edge of the mountain – where do you end up?

The coyote from Roadrunner probably knows the answer to that one.

A similar scenario unfolds in meeting rooms around the world. I found myself in one not too long ago. Back then, I didn’t take my app’s “feelings” into account. The result? Weeks of stress and production issues.

But let’s go back to our not-so-hypothetical meeting…

Can it fly though?

In that meeting, developers are asked whether it’s possible to add a new functionality to the app.

It can already drive – so why not make it fly? Why not turn it into the one solution that meets every possible customer need? That would make everyone happy, right? Developers get the chance to build something new, ambitious, and creative (which we all love), and the business/product side gets a shiny, money-making feature.

But what if the app isn’t ready for something like that? What if adding that extra load doesn’t make it better – but makes it suffer? Or worse, what if it actually causes harm?

I think the app should have a say in all this, and since it can’t speak for itself (something I’m sure the AI guys are already working on), somebody should be there to take its side. And who could do a better job than the people who develop, maintain, and are the owners of the app?

This is the mindset that has helped me make better decisions, have more confidence in defending them, and contribute more to the overall development process and roadmap, while also avoiding unnecessary pressure and stress that can arise from giving hard-to-keep promises, which could have been “decided away” right from the start.

Can we add a new type of data analysis that would dramatically increase the number of inserts, updates, and deletes in our database – which isn’t really suited for such operations? I mean, can my friend over here lift a rock that weighs a ton? Or better yet, what if I somehow handed him the rock and expected him to hold it above his head? It would hurt him, to say the least.

I know the same would apply to the app – I’ve seen it, and it was not pretty.

Objecting to such proposals – or offering more appropriate solutions (like giving him a smaller rock, or paying for his gym membership until he buffs up) – can help set the right expectations and better determine the proper course of action.

Saying ‘No’ before saying ‘Yes’ to features is an art

The first pitfall this mindset has helped me avoid is something I like to call “The Implementation Enamoration.”

After all, we’re programmers – our creativity knows no bounds. If there’s a problem, there’s a solution. Given enough time and tinkering room, we’ll come up with something. And we’ll be proud of it, because no one thought it could be done, and we just proved all the doubters wrong.

(I’ll stop here – got a bit carried away, sorry – but it’s something along those lines.)

We like the challenge. We enjoy the process of thinking and talking about how something can be done, and how we would do it. It’s the thing we jump to right away when presented with a challenge – erm, sorry, I mean a request for a new feature.

Someone with less experience might even start talking about how it could be implemented on the spot, without realizing that promises are already being made to the non-developers in the room. And those promises? They can be very difficult to backtrack on – though I suppose how hard that is depends on the kind of person who made them.

First of all, we should ask broader questions.

A feature is requested, but let’s talk about whether it should be done at all. Does it make sense? Whoever requested it should try to sell it to us first – that’s how we get the ball rolling. That’s how we have meaningful conversations that address the underlying problems. Before the prospect of solving a problem gets us so excited that we lose sight of the big picture.

If our app is expected to be living and breathing 24/7/365, let’s ask how it would feel if the feature were implemented without proper time for testing. Even if we do have time, we might not have the means to test it in a controlled environment. Our app could end up in a very bad place if we burden it with work it wasn’t originally designed to handle.

Every app has a “purpose”

This leads us to the second pitfall: “The Car-Plane Edification.”

We cannot expect our app to handle anything thrown at it, no matter how many ways we can think of reaching a solution. If we stretch the definition of what our app can do just to accommodate outside requests, often in practice, or to use a more appropriate term, production, it will fail.

This whole idea revolves around a fairly abstract concept: that an app has a “purpose.” This implies that everything already in the app was designed to support its main functionality. Adding something new should also contribute to this original idea. If it deviates too much, maybe it falls into a different domain that another app could handle better.

If it is still decided to go ahead with this new feature, it should be considered and presented in a different context. Our app is now becoming something else, and as is the case with all big changes, it will take much more time and work to get it done. Now, everybody is aware of how much time will be spent, and whether it’s wise to spend it can also be taken into the equation.

Be kind to your app – it has its limits

Thinking about these aspects has led me to become more involved in decision-making, and my input hopefully carries more weight.

Considering the bigger picture surrounding my applications has helped me become a better communicator with non-developers. The code comes later; the implementation is the consequence of already-established agreements. Those agreements are the parts that get ironed out with clients who don’t know about the code. The code is something I’ll end up discussing with my teammates when it’s time to implement.

Our time spent on the implementation can be much easier if we do not misrepresent our app. If we are aware of all its limitations, as well as the limitations of its environment, we can at least say, “We told you so,” when the route against our better judgment is taken.

Just like with people, setting someone up for failure doesn’t bode well for your relationship. So, to remain on good terms with your app, try to be more considerate towards it. That way, both of you can succeed, no one gets stretched beyond their limits, and untimely crashes are avoided.