Not yet another iOS architecture article

There are literally thousands of architecture articles comparing architectural patterns, analysing their benefits and drawbacks and in some cases even suggesting one over another. Especially in the iOS world, where I happen to work, there is always the misconception that software architecture and an architectural pattern are the same.

Personal Opinion

We are definitely fortunate to live in times where information is so easy to reach. At the same time, it has become challenging to filter and find the information we actually need. As a result, writing clean code is probably the easiest and hardest part of a software engineer’s day to day life, apart from naming variables.

It’s definitely easy because of all the information abundance I mentioned before but so hard at the same time because of:

  1. Legacy code

If you face or have faced any of the above, trust me, you are not alone. We have all faced either some or all of these but at the end of this article, I will try to show you that these are more excuses than problems.

All you need to do is a quick search on Google with the term “Software Architecture” and you will find many results that probably contain the answer to even the most complicated questions. But do they answer your question?

When I started reading about Software Architecture one of the first articles I read was written by Martin Fowler. In the introduction of that article, I read a quote from Ralph Johnson that I didn’t fully understand in the beginning but as I grew up professionally it made more and more sense.

“Architecture is about the important stuff. Whatever that is”.

Before you bypass this quote as something ambiguous and abstract, make a small pause and think about it. When we read about architecture in articles do we focus on the important stuff? What is our true goal?

So let’s try to find out the important stuff by trying to specify our needs.

What do we need?

  1. We need the software we write to fit the needs of the product we sell.

Product and Software are connected. There are multiple meetings where “business people” argue with “tech people” on the importance of a feature over technical work. Let’s admit it. This has happened to all of us and we were all wrong. Both worlds tend to forget that they are actually aiming for the same goal.

The next time you end up in a meeting like this, try to set your ego aside and evaluate your case as objectively as possible. If your software is not able to follow the same pace as the product then there must be something you could improve on how you design and implement your codebase/system.

Our product specifications may change over and over and our software should be there to cover our needs. The more frequently our product changes the more important and valuable is to have flexible software.

2. We need to generate fewer bugs

It’s natural to have bugs in your code. You shouldn’t consider that as a personal failure. It is though important to consider them as an indication of how fragile your system is. In some cases, such a fragile system can generate bugs even when we resolve bugs. Being Greek I always envisioned these kinds of bugs like a Lernean Hydra.

So you have two options:

  1. Follow the same strategy as Hercules and kill the bugs (Hydra’s head) with fire (please don’t try that at home, or at the office, or in general)

The more safety nets, the safer we need. They don’t guarantee 100% safety but they definitely decrease the probability of an accident.

3. We want to be able to read our code

Before you give me the title of Captain Obvious let me explain. I know this may seem too generic and too abstract but if you think about how many times you swore because the code you found wasn’t readable, or how much time you spent because you couldn’t understand a piece of … code then you will change your mind.

Next time you spend some time thinking about some variable or function naming you should think more about how much this fancy name is going to improve the overall readability of your code. A readable code is a code we can understand. It’s code where edge cases are not hidden under layers of comments but are handled as just normal cases.

How do we achieve our goals?

I promised that we are not going to speak about the best architecture and that was not a lie. Many people believe that architecture is something you choose. Personally, I believe that architecture is the result, or in other words:

Architecture is a mean to an end, it’s not the goal.

Let’s make an experiment. On your next project start writing code respecting the following rules:

  1. Think about the feature/product and try to understand its details

I bet if you follow the above, your result will be a well defined, readable, clean project and changes would be welcome and not challenging.

Change of Mindset

We all face challenges during our work and yet some people manage to bypass these challenges and produce great results. Their secret is the mindset. I bet that Uncle Bob didn’t write clean code in his first years of coding but he had a mindset on always improving and what better way to improve than having a robust foundation.

So change your mindset and instead of seeing obstacles that don’t allow you to write clean code focus on what you can do. Let’s check again the “excuses” mentioned in the beginning:

  1. Legacy code allows you to try improvements

Next step

So for your next steps, continue reading all the articles as they are all precious and we are fortunate to have such an active community. Keep this improving mindset and focus on the important stuff 😉 .

PS. I would love to hear your thoughts so please leave me a comment.

Software Engineer, always asking “why?”

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store