Better than /= Good

The problem to compare things is when you lose any type of absolute scale. Getting better is not always synonymous being good, better than is not the same as good. In development, this is an extremely important concept. This directly impacts the quality of the product was developed.

Like all important things, this is as important as it’s neglected.

Complex systems

A lot of things have to come together for a new system to be designed. It takes a combinations of several technologies, generation of lots of knowledge and lots of data processing in order to obtain a new product. Take a refrigerator, for example: it is necessary thermodynamic and mechanical knowledge to build the frame and insulation. One needs to know electromechanics, so that the compressor is understood and used properly. One also needs to know electronics to control these systems. Even design should be understood properly, as refrigerators integrate the kitchen environment.

I will not get into details of each piece but it is important to say that all those pieces have a lot of knowledge behind them. Of course I will not spend the space of the post with a complete specification of a refrigerator. I will take into account those who built it, as usual.

I say this to every developer: “put something in your mind, development is a social activity”

I say this to every developer: “put something in your mind, development is a social activity. Okay, it’s a “techno-social” activity: a group of people with some sort of  knowledge come together to do something and receive a payment for it after a while. I don’t get tired of repeating this. It is a delusion and a direct way to never ending projects when a developer thinks that he, alone, will design something ingenious. And because he can’t, that’s where the problem starts…

As a social activity, development can’t be made without interaction between people. When people interact, people compare. When comparing,  who knows what can happen.

Versus

First I did not understand. When I began to understand, I began to do it. When I got tired of that, I observed. One day I got tired of seeing it, when I was promoted to management, the hardware guys, programmable logic teams, micro-controller programmers  and embedded software people (from the driver programmer to the web designer) discussing what part of the project was the worse. I’ve even seen it in the same team.

I will not dig into merits or necessity of such discussions as they might be a good thing if done right (cross developer reviews are very helpful). To take criticism is a much more noble art than that of criticize. Those who are acquainted to me knows that I’ve always hit hard, but at the same time, I have never neglected that something I did was poor after I was made aware of it.

The problem with these arguments come up when criticism is used as defense mechanism and it does not aim technical quality of the system or the implementation style adopted. It manifests itself in the worst possible way: the individual does not admit he is wrong. Even worse, he may be doing the pact of mediocrity by denying to improve. I wrote about it in Autodesenvolvimento  (Self-development for Developers, the book I wrote, only in Portuguese for a while).

Technical Vanity

Besides having described about the awful mediocrity pact on Autodesenvolvimento, I also wrote about Technical Vanity. That is a bad thing. I’ve always been proud of my work, something that many people confused with technocracy or vanity. I’m pretty sure it is not the case. Why? Because I know the exact day that my Technical Vanity fell to the ground …

I had just finished a hardware schematic and send it to board layout. The layout guy  had some pins changed for a buffer to ease board routing. I had to do some changes and I didn’t pay attention to that. Prototypes got wrong. When I fixed it, I fixed unaware that he had made more changes and it went wrong again. We did not lose the prototype cycle, because the software developer was brilliant and managed to do some workaround. I’m sure he only did it because I didn’t put any blame on anyone. I humbly admitted my mistake and asked for help.

It is human to make mistakes. After making the same mistake twice, I became a lot more critical on me to the point of being suspicious of everything I did. I lost confidence and I fell to opposite mistake: whenever I was confronted to my previous work, I actually wanted to change everything I did. It was important for me to learn that during a system development, I was constantly learning and whenever revisited some work, I had the hard way to learn to resist the urge to do it again.

This attitude (to know that I’m always learning) now complement the first (to take responsibility for my mistakes). Anyway, why am I putting these things here? I do because many discussions that takes place between development teams happens when one team figure ways get out of any blame for sloppy work. On top of that, another colleague makes another work, considered of poor quality.

In the end of the day, a the sum of bad work leads to bad products.

 Crappy Products

I often say that if a product is crap, it is also crap the result and social interaction quality of its developers. There are developers (and maybe even some whole companies) that do not care to put crappy products on the market. There are numerous reasons for using it. I never considered neither of these assertions as valids.

In  fact, from a system point of view, to design a product with good quality is independent from the involved technology. I’ve seen awful products using the hi-end technology and I have seen excellent products (some even brilliant) using nothing more than 8bit micro-controllers. In the same way, product usefulness does depend on design quality.

All product development steps should be accomplished in a  way considered “good” or “well done”. Old wisdom often says that the journey is more important than the destination… Perhaps for development there is one analogy, that implementation is more important than the final product.

It is definitely unfortunate and misplaced to say that a product is “not so bad as before.”

Leveling down

A product well-run, well-developed, is something that depends on coordination. It depends on interaction. It does not help to criticize the work of a colleague knowing that your own share of work is bad. In the end, the discussion may or may not have been won, but who wins when the mutual goal is crappy?

This kind of thinking sticks to developer’s mind over time. We are not vaccinated against bad habits that we have acquired. For those who want to understand why habits are important, I recommend reading behavioral therapy. In a simplistic summary which is going to make psychiatrists turn their eyes, it is the logic that our thoughts influence our behavior and our behavior influence our thoughts.

Now think about how many times throughout his career, a developer who uses logic “mine is less worse than the others, so I’m good” is not comparing his results with the lowest performing team member. To this we call “leveling down”.

The technical vanity can lead the developer to create a crazy habit of leveling down. When someone levels down, he tends to produce systems with ever decreasing quality, leading to ever increasing need of unnecessary discussions to defend the indefensible, which is a bad implementation. We are not touching the lack of productivity which is made evident.

Just do it right

I mentioned earlier that we are constantly learning when developing a system. Therefore, the concept of “good” is constantly shifting. Is it complicated to know then when we’re doing a good product? Can you tell when you’re doing it right?

It is not complicated! You can tell!

However, it is not easy, though simple. To make a good product, One must do the best he can think of, the best imagine with the knowledge he has and the resources he has. One should seek collaboration. One must understand the colleagues views and must be open to suggestions.

The most important, in this case, is to be with a clear state of mind. To look after the best should be a habit, not one single action. A developer must seek leveling up, should seek progress in all aspects: technical, professional and personal.

About rftafas 183 Articles
Ricardo F. Tafas Jr graduated in Electrical Engineering at UFRGS with focus on Digital Systems and achieved his Masters also in Electrical Engineering on Telecomunications Network Management. He also author of "Autodesenvolvimento para Desenvolvedores (Self-development for developers). Ricardo has +10 years experience on R&D Management and +13 years on Embedded Eystem Development. His interest lay on Applied Strategic HR, Innovation Management and Embedded Technology as a differentiator and also on High Performance Digital Systems and FPGAs. Actually, he is editor and writer for “Repositório” blog (http://161.35.234.217), editorial board member at Embarcados (https://embarcados.com.br) and he is Management and Innovation Specialist at Repo Dinâmica - Aceleradora de Produtos.
0 Comments
Inline Feedbacks
View all comments