Balancing Basics in the Software Development Complexity

As developers, we tend to display our technical knowledge as often as we can. It feels good to showcase how much we actually do know in our specific areas and we feel really professional when we code something really clever. But the one thing we often forget is to ask a really basic question: Why? Why are we behaving like that and do we really need to do that?

Quick note: This article is written by our head of development Vilim Stubičan!

The Yearly Challenge

Every year, to celebrate my own growth, I choose a specific challenge to see how I’ve grown in the past 12 months.

Two years ago, I spent a lot of time diving deep into the JS world, so naturally, I decided to tackle advent of code in a specific way. I decided to solve daily challenges with JS, but following the rule of ‘no keywords’. It was really interesting and I got even deeper into the core definitions of JS and how things are being handled. If you are interested in what this actually looked like, you can check the source code.

Spoiler alert: I didn’t finish the challenge completely, but I did get to the point where I was really satisfied with my understanding of JS.

Last year, I was really focused on soft skills and interview processes in tech companies. Following my own growth in that area, I got into more than 30 different job interviews during the whole year. This allowed me to test my new social skills and to learn about selection process in top companies in Croatia.

I changed my approach, from one interview to the next, from being really positive to indifferent, from being punctual to late, from chatty to secluded. I solved tasks, I missed deadlines, I’ve been a junior, an intermediate and a senior. Finally, I’ve learned about the benefits and drawbacks of almost every combination of these basic behaviours.

This year, I’ve focused on frontend development and being a true problem solver, in a sense that I don’t want to talk about toolsets (frameworks, libraries, programming languages) until we “solve the problem”.

Challenges for this year:

In light of that, I gave myself two challenges this year. The first one was to solve this year’s advent of code in 25 different programming languages, thereby testing my “problems before tools” mindset. The second: making a game using only CSS.

Making a Game Using Only CSS

After a lot of searching and even going to the extent of reading the rendering engine’s source code, I found that not everything can be changed dynamically, especially the things I had envisioned. This finally led me to the end of that idea, but I still implemented a game with arrow movements using only CSS.

If you want to see the whole code and the process of developing the game only with CSS check out this article.

I also had a “bug” of not being able to block further gameplay with only CSS but here you can play Advent game with only CSS (for the best experience, go into fullscreen mode and please read the instruction on how to play it).

Complicating Solutions

We as developers tend to do this really often. We understand something to the core and we want to let everyone else know we have this knowledge because we spent a lot of time getting there and it feels good to get the acknowledgment for our efforts.

The problem in that is we shouldn’t force-feed our knowledge to others. We need to be smart enough to know that we don’t have a golden hammer and that not every problem we have is a nail. We need to find the best possible solution for every problem and that won’t always be the tool we are most comfortable with. And that’s OK. 👌

Simplicity Over Ingenuity

When approaching a problem, we have to balance a few things: the team working on the problem, the business requirements, client experience, the stage of your company’s growth and many others.

If you have a fair amount of juniors or intermediate developers, you have to keep your code and processes simple enough so that they can contribute easily.

Meaning, if you have that one rockstar ninja developer that writes code he/she and only he/she can maintain and understand, you have a problem. That person is not replaceable, which means they can never go on a vacation and they will have to handle all the bugs alone since no one else understands their software. Also, they are probably well on their way to burnout.

Business requirements are problems that we are solving for our clients, but that doesn’t mean everything actually is a problem. We have to ask our clients to determine if something actually is a problem or if it is something that they have just heard somewhere. There will be times when those two situations will overlap, but that is mostly an exception, not a rule.

Furthermore, those same clients maybe just don’t have enough experience in the kind of problem they are trying to solve. In that case, we will be the ones explaining our solutions to them. If we choose something ingenious just for the sake of being ingenious, we are going to have a hard time guiding the client through the solution. One very useful approach you can use to find out if your solution is too complex is the “5-year-old test”. If you can explain your solution to a 5-year-old child, you have a solution that is simple enough. If you can’t explain your solution to a senior member of your team with over 10 years of experience, then you have a problem.

Sometimes you, as a company, haven’t evolved enough to implement great, but complex solutions. These days, almost all backend developers are in favour of doing Domain Driven Design or CQRS due to their modularity and code cleanliness. But if you are a small agency just breaking out to the market, you want to earn money and reputation among clients so that you can build your presence and continue with your growth. Even though those solutions may seem like the better approach from the code perspective, it is not the best solution for your company at the moment.

Scaling Your Simplicity and Complexity

At the end of the day, you have to see what works best for you and your company. Don’t fall into the trap of choosing complex solutions just because they seem like the best for one part of your business.

Scale simple solutions for as long as they are fulfilling your needs to their best possibility. When the moment comes, go for the better solution, (probably) the more complex one.

Check out our final advice on this topic in the last paragraph in our article at Async Labs.

And let us know if you tried anything really complex just to prove something to yourself? We would love to hear from you hello@asynclabs.co.