DEV Community: Mauro Frezza

The Shame of Legacy Code

Mauro Frezza — Mon, 10 Feb 2020 20:22:20 +0000

The Shame of Legacy Code is the feeling you get when you explain legacy code you wrote, or somebody else in your team wrote, to somebody who is not familiar with it.

I started learning about its devastating effects since last year. I've been helping new developers onboarding in the codebase my team handles and so I have been the point of contact for any question related to the design of the code.
Question after question, I found myself answering more that the design was not good or that some part of code was messy. I paid attention to the reaction of the new developers and I could see in their face the surprise mixed with disappointment or even disgust by the status of the code.

Their reaction hit me hard. Really hard. More than I expected and more than I wanted to admit to myself. Even if I didn't write the code I somehow felt guilty because I let this happen under my watch.

The result was a sense of despair and lack of motivation that made me on the verge to quit many times. Several nights I went home from work and cried out of despair because I felt I was a failed developer, a complete incompetent one.

A developer cannot sustain to do bad work every day for long time without it taking a toll on him/her. One will eventually forget what it means to do something properly.
I did not quit because that is the easy way and I don't believe you grow by going away from the tough situations.

But then again, when is the time you are allowed to walk away?

Practicing PDD - Panic Driven Development

Mauro Frezza — Sun, 07 Jul 2019 12:34:35 +0000

After the initial wave of success of agile development techniques, one particular technique has survived and emerged throughout the years: PDD Panic Driven Development.
This technique shares the core concepts of agile development methodologies but removes all the ceremonies and process burden that reduces velocity in teams.
Let's see more in detail what are the principles of this methodology.

Recent issues have priority

Whenever a new issue comes up in the middle of the sprint, it takes priority over any planned work. New is always better and has higher priority. As a matter of fact it should be one of the principles of the agile development as well.
The focus on delivering value to customer requires the team to take care of new items and postpone previously defined work.

Write enough code to fix the issue

Developers write code for a living. Bugs can be fixed only by code. Design and UX discussion can only slow down the development. Code a solution first, verify your assumptions with the fix.
If the fix works, you solved the issue.

Tests should be a follow-up task

Once the fix is implemented, tests can be planned as a task to be done in the future. Tests are useful but not a priority. You can take care of them later. File a ticket and put it in the backlog.
Manual testing should enough to prove your fix.

Trust your instinct

Programming is art. Art has an intrinsic instinctive component. Trust your gut. Code your solution. Deploy it. Only the bold succeeds.

Process is flexible

Any process put in place to develop, test and release software is just a set of conventions and rules that are not written in stone. Critical fixes require different approaches. It is expected that you bend the process in order to act faster.

It’s a manager driven process

As part of one team, managers are entitled to give their opinions on development matters.
Refactoring or good practices can and should be overruled by business needs. Engineers can express their opinions but they should eventually commit to any need that comes from above.

Conclusion

PDD is a technique that can give great performance improvements in a short period time for every project.
It is practiced by several companies around the world. It represents the core of agile and extreme programming.

Complex Software vs Complicated Software

Mauro Frezza — Fri, 14 Jun 2019 09:29:36 +0000

As a developer you most certainly have to jump into new codebases that were developed by others. When that happens, if you are lucky, you have the possibility to reach out to the developers that have worked on it and can guide you through the code.

I have seen something recurring in this process of knowledge transfer. The developer familiar with the code may often refer to it as "complicated". Hearing "It's complicated!" usually makes me think of relationships where obviously something is not right but nobody can put a finger exactly on the real problem.

Complicated is a peculiar word and I've started using negative words like this carefully when expressing a technical opinion. We, developers, are used to pay attention at each instruction we put in our code, so I feel we should start doing the same for words when communicating with others.

In many cases, we interchange complex and complicated, using them as synonym simply because they have a similar base and definition. Similar but not equivalent. Let's actually see what each means.

Definition of Complex:

involving a lot of different but related parts - difficult to understand or find an answer to because of having many different parts

Definition of Complicated:

involving a lot of different parts, in a way that is difficult to understand.

source Cambridge Dictionary

By looking at the definitions we see that they both share the concept of having many parts involved but the barrier to understand the element they refer to, lies in how these parts relates to each other.
Complex refers to related parts while complicated refers to different parts which implies they are unrelated conceptually between each other.

I think that these adjectives are extremely powerful to represent the status of a codebase.

A complex codebase is usually the result of many requirements that define the product. It might be hard to get a clear picture of the functionalities because they require a certain knowledge of the domain but at least the code models the domain with a proper design and correct software patterns. This gives the confidence that the code does not add an extra layer of logic on top of the domain; developers can infer and relate the business logic from the code with no particular difficulty. It does not mean the code is trivial obviously, but at least it does not put additional cognitive load on the reader besides the one of understanding the business logic behind it.

On the contrary, a complicated codebase can simply be the result of a bad development process. Code is not clear from an implementation stand point; even when the business logic behind it is trivial, understanding how that is implemented requires an additional and unjustifiable effort.

If we agree on this terminology, a lot can be conveyed by using these adjectives correctly. A developer who is getting onboarded on the codebase can understand what to expect and get an idea of what are the parts he can touch more confidently and which are more fragile.

For the developer familiar with the code, deciding whether to use one or the other should involve a level of introspection to understand the quality of the code which may have been overlooked because it was considered simply the result of a complex business logic.

Since I have started to pay attention to the difference of these two concepts I feel I have gained a powerful tool in my toolbox; I am now better at evaluating the status of a codebase and therefore provide better estimates for the work I am supposed to do it. Also this attitude helps shining a light on unseen technical debt and fuels discussions over design improvements.

Lazy developers write tests

Mauro Frezza — Sat, 18 May 2019 22:59:19 +0000

Consider Lisa, a developer. A smart one. But lazy.
So lazy that she wants to reduce at minimum the time spent to talk to other developers explaining his code.

She wants to just write her code and move to the next ticket. Sure, she likes to talk to other developers about new technologies, frameworks and patterns. But when it comes to her code, she doesn't want to explain why she added that if-else code or why the function she wrote checks the if a parameter is null. She enjoys discussing why she chose a certain design pattern or used a certain library to solve a particular issue. Those are the interesting and important things to take care when sharing knowledge with the team.

But the small details, gotchas and edge cases you consider when coding do not belong there. They are important of course. But when you write and read the code. So the code should be the keeper of this knowledge.

Requirements and specification documents? Too generic and high level. Sometimes there are things in the code that are not present in the requirements because they are a pure result of the implementation.

Documentation in the code does not help. It gets old pretty fast and you always forget to update. Nobody reads it anyway.

If the code is the keeper of this knowledge, the code should reply these questions. And when the code doesn't because it is not clear enough, only one thing can.

Tests.

A test represents a part of the knowledge. It might come from the requirements or it might be new knowledge the developer acquired during the implementation. All these pieces of knowledge compose your product. And you want to make sure they don't get lost.

Once a test is written, it stands as a guard. It tells every new developer the story of why the code is like that. It shouts whenever someone dares to change something that should have not be changed.

It is an entity on its own which does the job for you.

Be lazy. Be smart. Write tests.

Why don’t you give a presentation? If only they would let me do it…

Mauro Frezza — Tue, 16 Jan 2018 11:34:21 +0000

During 2017 I have been applying as a speaker to several Android (or Java) conferences throughout Europe. It was my 2017 resolution to try challenge myself to do so. I’ve been watching and attending several Android conferences so I thought I could have contributed in some ways with what I’ve learned in all my years of Android development.

I’ve always thought that, in order to talk at a conference, you must be some kind of a super smart developer with decades of experience in development. For this reason, the idea of giving a presentation at such conferences has always looked crazy to me before. But recently I’ve realised that not all the people that do presentations are “geniuses”; Many of them are good programmers that keep improving themselves and learn from their mistakes. And in that I could see something resembling myself!

So I decided to give it a try.

I’ve worked on Ray Super Remote for quite some time and there I’ve learned a lot about Android, software development and I got the chance to work in a big team with several other Android developers.
I’ve learned what it means to build long complicated on-boarding flows where you need to collect a lot of information about the user and the navigation is not linear but is more like a state machine. Where the user will go next depends on the information collected so far.

We had to structure our app in a way that allowed us to create a system where it is easy to create new sub-flows and connect them to others. We had to ensure the system was flexible and powerful enough to accomodate all the needs coming from the UX and product team.

Of course the initial solution was bad and had several problems but nevertheless it was working. So we learned from our mistakes and we came up with a better solution for such problems. We then applied this solution(s) in another similar project with great results.

I’ve been the main architect of the new solution so I’m particularly proud of it. It covers several aspects; from architecture design and managing requirements to improving code testability. My colleagues started telling me that this solution is worth it to be shared with other developers. Even if the scenario is quite specific, the solution, up to a certain extent, can be reused in other apps.
So I did it. First I gave the presentation in a local developer meeting in the city where I live; just to try it out and get a sense of it. The presentation went “well-ish” but from it I learned that some adjustments were needed.

Then I started applying to several Android conferences.

I first applied to around 5–6 but I got rejected. I thought that maybe my abstract was too confusing and not appealing. So I changed and made it simpler and “cooler”. Less detailed but more “catchy” to tickle the curiosity of the reader.
I’ve submitted the new abstract to several other conferences. In the second batch of attempts I’ve also targeted small conferences, less popular, hoping that they would be more interested in an outsider.

None of them accepted me. One of them even informed me two days before the conference, telling me I wasn’t accepted (better late than never you say).
I was very disappointed because despite my will to challenge myself, they were denying me the opportunity to give it a try.

Then I got curious and determined to understand why. Was my presentation so bad compared to others? Was my topic not interesting or not useful in other context? I sincerely thought to give up because maybe I was preaching topics that were really not appealing to anyone in other contexts. But something didn’t feel right…

I’ve started looking at the conferences I’ve applied to to see who was talking there; in particular about the topics of their presentation, where they work and whether or not the presentation was new.

It turned out that there were always the same faces in all the conferences… This is something I’ve realised before but I’ve never bothered to verify how much actually it was spread.

And when there was someone new, he/she was most often from a big company or from a company that was sponsoring the conference.
I then looked into the topics, hoping to find interesting things. Many times there were presentations on something that has already been covered extensively or presentations that were talking about topics that could easily be covered in a small post. The worst thing was that there were presentations that have been given for more than a year in several conferences…

But, Mauro, what are you trying to say with that? (every reader at this point)

Well I think there is a problem in many conferences. Big names (people or company) attract people. People means money for the conferences. Also big company can afford to pay the expenses to their employee who attend various conferences; this saves the conferences from having to cover for their expenses (this is my theory so if someone can prove me wrong, I’m open to objections).

In addition I think there is a vicious loop. To have more chance to make a presentation you need prove you have experiences in them but where do you get that experience? Well, you get the point…

So it happens that someone who has given a good presentation before and became popular can afford to have bad presentation on another topic but still look more interesting because of his/her popularity.

In my struggle to be a speaker, I somehow lost the trust in the quality of certain conferences. Don’t get me wrong, I’ll definitely keep trying and maybe I will manage to get a chance.

There’s also a good chance that it will turn out that I suck big time at it! But I least I can say I tried…

I leave you with one thought: how many good presentations are out there that are just waiting for a microphone and a projector but can’t get a chance?

Once upon a time there was a programmer…

Mauro Frezza — Mon, 11 Sep 2017 20:07:27 +0000

Why is it so exciting writing software?

I found myself trying to explain to non programmers why I find so interesting writing software so many times that it became a question stuck in my mind. And I realized I couldn’t answer it. But then it hit me: writing software it’s like writing a book.
You start from a blank paper and a lot of ideas floating around in your mind. You feel the need to write them down so you can give them a shape. First you lay down the structure of your project, confident that everything will fit perfectly and the story will work smoothly and flawlessly.
You start defining by your characters; at the beginning their profile seems pretty easy to describe, no need to make them too complex. Every character does a specific set of actions and the interaction between them are clear and simple so the reader can easily follow them.

…you can’t stop writing because you and the book are so deeply connected that you can see yourself among thoseÂ lines

All the character live in a perfect world where everything goes as it is supposed to go and you, as the writer and creator of this world, have perfect control and power on what is going on in there.
So you keep writing your story under the excitement of seeing your ideas becoming real; you can’t stop writing because you and the book are so deeply connected that you can see yourself among those lines. So hours, day and maybe months go by and then finally you finish your book.
Everything is there: clear, simple, perfect.

At least that’s what you think.

What you think is the final version of your book is barely a draft. Some people will start reading the book and, with your big surprise, they will start complaining that the book doesn’t make too much sense. What the characters do seems stupid, the interaction between them seems too simple or weird. Something that in real life does not make any sense.

What?! How dare they? Don’t they see how perfect the story is?

What you imagined and defined is an utopistic world that only exists in yourÂ mind

That’s the problem: the story, the characters are too perfect to fit the real world. What you imagined and defined is an utopistic world that only exists in your mind. But you didn’t know how real world works because you were in your room, sit at your desk dreaming of a different world where everything was black or white. Real life is complicated and nothing is what it seems at first glance; not everything can be defined under specific conditions and many things evolve during their life passing from one shape to the other.
Now that you faced the reality it seems that the whole world around you is falling apart. Your certainties disappeared and even you start thinking that your book does not make any sense, that you should probably throw it away and focusing on something else. Many writers do this. They just give up on this because they cannot tolerate that what they imagined is not true. If that is not true and readers cannot understand it then it means it’s not worth working on it anymore.
But luckily for us, many other writers don’t give up and accepts and understand that what they imagined is not real and they embrace the reality hoping that their stories and ideas can still work in a world different than what they designed.
Here you see the difference between a good writer and a real artist.
Good writers just change the plot, the characters and the environment of the book just enough to make it real and understandable for the most of the readers. They simply attach everything to the real world. The result is something that most of the readers understand and in general they appreciate it. Let’s be clear, the book won’t probably be remembered and studied by people for years but it does his job. It entertains the readers just enough for him not close it.

Who reads their book must found answers to questions he has never askedÂ himself

Real artists, instead, do something different. They think that connecting the book to reality is not enough. They must understand the real world and the readers deeply. They want to know what the user wants to read even if he consciously doesn’t know it yet. Who reads their book must found answers to questions he has never asked himself. But these question will appear so important for him, that he has to keep reading to get them or he will feel restless.

Exploiting the real world is what gives these writers the right to be called artists.

So after all this, you still want to ask me what’s so interesting in writing software?