Fat Apps!

What is a fat app?

An app is too fat when it takes over half of a work day (that’s exactly four hours) to have one line of code changed, deployed, and made to be used by the public / end-users.

I could say that an app is too fat if it takes too long to change a simple feature, but this definition too vague, and doesn’t fit the software engineering mentality. Neither does it truly serve the purpose since every single engineer on the planet has his own version of how long is too long, and how simple a simple feature really is.

Why apps get fat?

Apps are like some people, they get too fat when they are over-fed, except that apps do not get fed food, they feed on code and policies.

For a while I thought the solution for these bloated apps was the micro services architectures, but soon I realized it makes it even harder to locate an issue that’s happening amongst these micro services without intensely logging and monitoring each and every action that a given micro service performs. Not only that, but you have to notify the entire team that something went wrong with a feature somewhere, it takes exponentially more time when the problem is located in multiple parts of the system.

So while micro services make it easy to develop a feature in a given domain, it makes it even harder to tackle a problem with too many moving parts in the system, unfortunately it’s the best thing that we have out there amongst other architectural patterns.

Another reason that apps get too fat is over-engineering. Sometimes engineers try to impress each other, or “out-nerd” each other by showing their abstraction skills and their [INSERT_LANGUAGE_HERE]-Fu. When it comes to solving some problem, the result is an overly complicated app that requires more time to understand than it takes to solve the problem.

A fat app could be as small as fifty lines of code, but the governing rules around implementing features and deploying them for the end-users is what actually makes it a fat app. The “fat” here is located in the governing area of the app development process, not in the app itself, and that’s an easy problem to fix because it doesn’t really require technical engineering. It becomes more of social engineering solution (in a good way) to change how things work around the app delivery processes in which case the actual complexity here lies in the flexibility of the governing team to change their methods of deployment and certification of a given app.

Solutions

Just like most of the overweight issues, there are multiple things one could do to avoid producing fat apps. The first of these solutions is exercise - not the exercising one does at the gym, but exercising simplicity. Every so often we engineers work so hard on learning the latest and greatest in a given technology, or a development methodology, but very seldom do we exercise simplicity. Simplicity is an art form of solving a problem without overthinking, or over engineering a solution.

Simplicity, however, is not another definition for readability either. A piece of code could be very readable, but it may still be very complex and over-engineered. Determining if something is simple, or not is so easy, a team needs only to let the most junior developer on the team try to understand and explain (maybe even make a simple change) the given implemented feature, and if it takes them over an hour to understand something, then that’s your fat app sign right there. In this pattern, junior developers on teams are just as important as the senior ones because they are one of the scales that developers could use to determine if their app is overweight or not.

Another solution is to be realistic about implementing apps. The act of not worrying about what might be needed in the future (and only focusing on the now) creates a dilemma. The “now” are the requirements in hand which should lead to less abstraction and more simplification toward what a piece of code is trying to do.

Too many team members = fat apps, or too many cooks spoil the proverbial broth. Since each one of us has his own right way to get something done, we may end up in a middle ground amongst the team members in a situation which they might agree on a solution, but that solution isn’t necessarily a simple one. Again, in this case the junior developer on the team should be the judge.

If everyone on the team happens to be a senior guru, then extracting the solution into a flowchart and showing it to a non-technical person might be a great way to determine the complexity of the app. Normally, non-technical folks are pretty honest about how nerdy something is when it comes to looking at flowcharts. You may also pay attention to their eyes as they look at the ceiling or checking their phones, in addition to their yawning as you to explain something to them.

Flowcharts (the dead lost art of visualizing a process) are pretty self-explanatory when it comes to indicating the complexity of a given app.

A look to the Future

I personally still think there’s a big chance out there to come up with a better architecture pattern to assure simplicity without having to bear the costs of software development, but I also still believe that apps are a reflection of our thought processes. If we view things in a complicated way, this will be reflected in the apps that we make. Our apps, after all, are like our children - they only know what we teach them!

The reason I believe this is because the most complex “app” we use on daily basis is this universe around us - our bodies, our surroundings, and this infinitely expanding universe around us. With all of its complexity, the universal system is still built out of very simple molecules that effectively communicate with one another into bigger systems. This should be one very strong source of inspiration when it comes to offering intelligent yet simple software.