Keep your code stupidly simple!

Simplifying (and keeping) the structure of all parts of your software can save a lot of work time (a precious resource).

When I say simple, however, I am not talking about something unfinished or badly done. It is often even more difficult to do things in a simple way (that is why it is common to see workarounds that make things so complex over time). It requires a little more planning and experience.

Thinking “simple” but planned is something that improves day after day, refactoring after refactoring, but which ends up bringing benefits in the short and long term.

Let's take as an example, a software that has a “Labels” module: labels that can be assigned to certain entities (let's assume that such entities are Posts, Products, etc.).

Due to several decisions that left simplicity aside, over time the structure of these "Labels" became more and more complex, and whenever a change was necessary, many hours or even days of work were lost.

See this example of an old code existing in this software, responsible for obtaining the labels of a given entity:

<?php

// Complex code caused by lack of simplicity
$labels = DB::table('labelables')
    ->select(['labelables.*', 'labels.id as label_id', 'labels.slug', 'labels.title'])
    ->join('labels', 'labels.id', 'labelables.label_id')
    ->where('labels.title', 'like', '%'.$search.'%')
    ->where('labelables.labelable_type', $request->labelable_type)
    ->whereRaw('(SELECT count(id) 
        FROM labelables AS count_labelables 
        WHERE count_labelables.labelable_type = labelables.labelable_type
            AND count_labelables.project_id = labelables.project_id
            AND count_labelables.labelable_id = ?
            AND count_labelables.label_id = labelables.label_id
            AND count_labelables.color = labelables.color
            AND count_labelables.deleted_at IS NULL) = 0', $request->labelable_id)
    ->groupBy(['labels.title', 'labelables.color'])
    ->orderBy('labelables.updated_at', 'ASC')
    ->limit($limit);

And this was one of the most subtle parts (the problem, in this case, was in the root/structure of the data, which ended up generating the famous “workarounds”, to solve the problems).

Over time, the different solutions to the structural problems were piling up and turning the module into a large “spaghetti code”.

At that moment, it was almost impossible to read the code without "driving crazy".

That is why a complete reformulation of the structure of this module was made, from the database to the code, always with the concept of simplicity and objectivity in mind.

In the end, the software had the following code to perform the same task:

<?php

$currentLabels = $this->getCurrentLabels();

$labels = Label::where('company_id', $company->id)
    ->whereNotIn('labels.id', $currentLabels);

Just by looking at the code, you can see that the simplification of the structure has already generated improvements in readability.

To achieve this result, several steps were necessary:

1. Review the current structure (time-consuming and complex, but necessary)
2. Decide what goes on and what comes out of the business rules (some rules added over time were unnecessary) - This is the stage of talking and really understanding what is expected, and what can be left out
3. Reformulate the structure, from the database to the code
4. Implement the code (testing during the process) - It is common, at this stage, to have to create code to adapt the data to the new structure, renaming and creating new tables in the database, etc. It is also common, sometimes, to return to the previous step (3) since developing is a process of discovery and some incongruities may go unnoticed.

The curious thing is that the structure was very simple at the beginning of the system, and many of the rules added later, which ended up generating this complexity, were discarded.

The famous KISS principle (keep it simple, stupid) is a great concept to be applied to any project, being software development or not.

According to this principle, making and keeping things simple makes them work much better than if they are complicated.

In accordance with this principle and with what we saw here, we can conclude that it is important to question everything that can add layers of complexity without bringing real benefits.

Perhaps, having kept everything simple, really analyzing the need for certain rules and features, would have avoided so many headaches in this software module.

And finally:

Even the complex can be approached in a simple way. Keep it simple!

If you liked this post, please consider following me on Twitter to be notified when I post others.