Categoria: Career

As software engineers, what are we really building?


I never liked the bridge building metaphor very much and I know many software developers also didn’t. Many criticize the whole engineer thing and prefer the craftsmanship metaphor.

I can see value in both, but I wasn’t able to express what exactly was the problem with them. At least until a few days ago, when I watched this cartoon with my son about a tractor loader stacking numbered little cubes of various colors.

The building block metaphor


The first thing that came to my mind was the analogy of building software using components. If we think on these components as blocks, we can go even further. When we stack a block on the top of another or gather them side by side we can call the surface touching another block’s surface as the interface between them.

The problem is, in software, greater contact area between two components means coupled code that’s hard to change and maintain, right? However, real blocks benefit from friction and are more stable when they have direct contact with a greater number of blocks. While real blocks support each other, too much friction between software components makes them unusable.

So, when you think a little deeper in this analogy, you realize it didn’t work very well.

The bridge metaphor

Going back to the bridge analogy, after having watched that cartoon, I realized a subtle but crucial difference between a real bridge and that one that fills the gap between client needs and running software.

When professionals build a house, a building, or a bridge they go to the physical place, inspect, measure, do the calculations, bring the material, put each thing in their place. If some material is missing, they just buy more. If something is not fitting in, they just tweak it. When they finish it, they can see exactly whether they met the expectations or not. Of course a bridge can fall, someone can do incorrect calculations, but in general engineers are somehow able to assess its stability.

What can I say about software development? It’s abstract. It can’t be seen. It can’t be measured properly. You can test it in some manners, but it doesn’t guarantee it’s correct. But you already knew about all these characteristics, right? Yet there’s something perhaps you have missed, as I did. That is, in software, we don’t just build and delivery.

Actually, we do not build a bridge at all. What we really build is an abstraction. Not an abstract bridge. We build an abstract bridge builder.

At low level, every time an application is executed it builds a concrete bridge. That bridge needs to fit perfectly unknown places and shouldn’t fall under uncertain weights. In another words, it brings and loads and gathers and connects all components, and when they’re ready it’ll do whatever it was designed to do.

So a software bridge is more like a bridge you can carry in your pocket and use whenever you need to cross some valley or river. Depending on the user, he/she will complain that bridge won’t take them from America to Europe.

And about the Mona Lisa?

I think we can apply the same principle to software craftsmanship. Think for a moment. Even if we switch to this analogy, with developers producing binary masterpieces and programmers painting Mona Lisa’s, it doesn’t change anything in the nature of that problem.

We’re still making an abstract artwork builder. When the software runs, it should creates instantaneously a masterpiece according to the instructions of its master.

Is there a proper analogy?

Sorry for disappointing you, but in fact I have no idea. 🙁

On the other hand, I have strong reasons to think that much of our problems in software engineering will be solved by finding the right analogy.

As cubes and rectangles and circles are properly used as abstractions to build bridges and paint masterpieces, it there should be proper abstractions to software development.

One thing I do know

As software developers (engineers or craftsmans) we should be simple. We need master simplicity.

I think it’s clear for anyone who have ever worked with software that complexity should be avoided at all costs. It’s not by chance the latest frameworks and tools and processes and methodologies and techniques try to be as simple as possible.

Nevertheless, I have something against them. They’re becoming too shallow.

For instance, I’ve seen many people doing agile because they hate documentation. But throwing it away won’t solve their problem. I’ve seen many new flavors of tools and frameworks and methodologies that do exactly what the existing ones do, except for promising they’re easier. I’ve seen people that hate everything that seems to be old and love every novelty though they have no clue about the reason.

They just want to work less. They just want to think less.

We’re living the era of lazy programmers. But not the kind that would automate repetitive tasks, as noticed by Steve McConnell in his book Code Complete, or avoid useless documentation. Unfortunately, there are plenty of lazy programmers today that don’t even want to understand the problems they face. They want some magic easy solution so they don’t need to think and do the hard work.

Simple but deep

When you have a problem, there’s basically two alternatives: ignore it and hope that soon or later it’ll disappear, or face it and do whatever it takes to solve it.

Despite many advances in the field, I think we’re still living a software crisis. I see many companies and professionals completely lost having so many options to do the same thing, while others jump from technology to technology by a matter of taste.

Well, I have my personal taste for programming languages too, but that’s not the point. I’m talking about the fundamentals. I think people are just attacking the wrong thing. They’re ignoring the real problem.

It’s not sufficient to make things easy and cool without solving the real problem.

Software development today is simpler than some decades ago. Nonetheless, as spotted in Brooks’ Mythical Man-Month, it happened because we overcome the accidental difficulties of programming. We have now better debugging, rich-featured IDEs, faster personal computers, and son on. But few initiatives attack the essence of the complexity in software development. And here dwells our biggest challenge.

In order to make software development even simpler, it’s necessary to dig deep into the dirty of complexity, face the hard things, try solution after solution, year after year.

We need people that do not put blind faith in new tools and methods, that aren’t lazy to do whatever needs to be done, that really understand what they are doing. And we need people willing to persist in this direction, instead of being apathetic and choosing the easy path.

Only those who discipline themselves in this craft will be able to provide us with a real improvement in software development some day.

Results of a social experiment


After a few years working on IT, always learning new things, I think I came to a point where I have a reasonable experience. However, I noticed that talent and effort aren’t equivalent to professional growth and recognition.

My influence as professional were only over my small circle of colleagues, inside my company. For the rest of the world, I was just nobody.

No, it’s not about fame I’m talking about, but in showing who really I am. If someone put my name on Google today, what he/she will see? An unknown? Or a professional respected by what he does, knows and is?

At the beginning of 2013 I decided to start a personal and social experiment, taking the heat for exposing myself.

The scenario

In the first 5 years working with IT there weren’t one day when I haven’t studied or created something different, even if it was one simple pattern applied to one simple class. But even then I often felt kind of stagnated.

On the other hand, sometimes there was a “wave of maturity”, when I felt a sort of adrenaline rush realizing I was improving a lot and fast. But, as the time passes, the growth stops and soon the stagnation shows up again. In order to start it again it was necessary to reinvent myself time after time.

Despite of it, though I was distinguished inside my small circle, I was nobody for the IT community. There wasn’t anyone outside my company who knew my reputation, nothing online that proved something about me.

How to overcome that?

Analyzing previous improvements

One of the major “waves of maturity” occurred to me while I was writing a paper about software estimation at my post graduation (specialization) course. My advisor professor was Dr. Ítalo Vega. In each analysis of my text, he explained concepts far beyond what I had learned in college or reading books. I learned so much about how critical thinking works and about the difference between objective versus subjective arguments. I can say my entire worldview was affected, the way I thought about facts, evidences, and opinions.

What happened there? What started that evolution? I could comprehend the following main points:

  • Exposition of my work to analysis and critic of a good professional.
  • Work together with someone who knows (a lot) more than I.

How could I reproduce that experience?

The first action: this blog

With my mind blowing with new ideas and a new vision of IT acquired from my specialization, my first act was to start this blog.

I had a double intent: help less experienced professionals and disseminate a few things I had learned. This way, if one wants to know who Luiz Ricardo is, he just would need to spend a bit of time reading through this page to have a good idea about my profile, experience, depth. I can say these goals was and are being achieved.

But there’s a problem with the blog (as any website): isn’t not enough to publish content online. I had to interact with good professionals, so I decided to join…

Online developer communities

Knowing about communities like GUJ (Grupo de Usuários Java, Java User Group) and StackOverflow, I bet it would be an interesting way to asset my knowledge. Could I help other professionals as I did with my colleagues? Or did my knowledge is restricted to my small workplace?

GUJ Respostas (GUJ Answers)

My first “target” was GUJ Respostas, a platform like StackOverflow, different from traditional forums. Users ask questions and others answer them. Users can vote for or against questions and answers. Clarifications can be made via comments. For each vote received, the user that asked a good question or gave a good answer earns a few reputation points. Votes against questions or answers subtract points from the user.

As I started answering questions, I had a few snags. When we deal with someone personally we can hear the problem and ask or check whatever we want. At distance, it’s necessary to pay attention to details, suppose correctly, and realize that if we write nonsense someone will be there to point this out. It’s a good training to the Chrystal Ball all good software engineers must own.

I joined GUJ Respostas in October, 2013. Three months later I reached the first position in the rank.

StackOverflow em Português (StackOverflow in Portuguese)

Some time later, on December 13, 2013, the Portuguese speaking community version of StackOverflow began. I joined since the first day of private beta!

StackOverflow is a community with goals like organizing and centralizing information about programming and related issues, though there are other interesting communities sharing the same ideal on StackExchange network. StackOverflow is more demanding about the content, moderators act boldly to maintain the level of quality.

I don’t need to say that I had some issues in the beginning. But, once more, exposing myself to other professionals I was susceptible of analysis and critics.

In the end, the results were also very positive. After three months of active participation I reached the first position in the rank.

Review of the experiment

Obviously, reaching the first place on both sites doesn’t prove at all I’m better than any other user. This isn’t also an objective qualifier of my skills.

However, at least I can say as a professional I was useful to many people, I have a fairly wide and deep knowledge, enough to help in different areas. 😉

I also won confidence before interviews and discussions about technology in general.

Furthermore, many times I was criticized. With good reason in some occasions, not so much in others. Sometimes other professionals answered better. Little by little, I compared my approach with theirs and improved my reasoning and thought process.

I don’t know for how long I’ll be in the first position on these sites. Indeed, it doesn’t matter. Perhaps I’ll spend my time in other activities to get better in different aspects. But it certainly was a great experience!

Conclusions for the reader

I believe those principles mentioned above count for every professional, namely:

  • Expose yourself to analysis and critic.
  • Learn/work with better people.

Leave your comfort zone

Maybe you are the best in your group. But, probably, you are the best only in the stuff you are better. And what about the areas where others are better than you? Probably you have something to learn, isn’t?

There’s always someone better. It’s a basic principle.

Be social

Even good professionals can get out-of-date and alienated. Make sure you have contact with different IT subcultures and increase your contact list. This can bring many benefits to your career, and I’ll list two of them:

  1. Learn how to express your thoughts better and defend your ideas. This can contribute to get a promotion.
  2. Be aware of the news in technical and market issues. This will keep you above the average and could even help you go get a better job.

Is it worth repeating my experiment?

It depends.

Participating in developer communities is a valid way to help remote colleagues and gather knowledge outside your daily environment.

However, I don’t recommend invest too much time or impose on yourself to reach a specific position in the rank.

There are other ways to improve yourself professionally. This is only one of them. Maybe, in your case, it would be better read those dusty books on your shelf, make a specialization course, or participate in open source projects, where your code will be assessed by more experienced developers.

The important thing is: always reinvent yourself and don’t stand still!

Does good developers write complex code?

Did you ever see a developer boasting of himself because he created a hard-to-understand code? Perhaps you ever fancied yourself doing something like this:

void Run( const std::string& v, int tgt, int start ) { for( ; tgt >= 2 * start + 1; ++start ) Run( v + ' ' + boost::lexical_cast( start ), tgt - start, start + 1 ); std::cout << v << ' ' << tgt << std::endl;} int main() { Run( std::string(), 10, 1 ); getchar();}


Complex code is bad code

spaghetti-code A good developer knows complexity is his enemy. When we work with real software we have to fight it. Complexity hides errors, makes software obscure, and is a hindrance to maintenance. If all that doesn’t bother you, think in your own wallet, mainly if you’re a consultant, a freelancer, or own a company.

Did you ever work with code written by yourself a long time ago and had a hard time? How could you write such a hideous thing? If you were more careful, perhaps it would keep you or a colleague from future nightmares, isn’t? Of course it would! And hope shines if you are now able to see that!

Complex code is bad code. Maintenance will require too much refactoring and testing. Did you ever see a messed program you prefer rewrite it thoroughly instead of just make the changes required?

“Oh, but we have comments, don’t we?”, you can argue. Not so fast! Many will oppose to you. To begin with, processes like XP (eXtreme Programming) states that the code should be clear and self-explaining. Comments often are our enemies too. They can indeed fool us stating something the code doesn’t actually does. In excess, they pollute the code visually and make our sources longer.

Be simple

One approach to escape complexity is the principle known as KISS: “Keep It Simple, Stupid!“. Let’s outline a few steps from this “rehabilitation program for bad developers”:

  • Be humble, don’t think of yourself as a genius.
  • Break down your tasks in sub tasks: don’t work more than a few hours in the same code.
  • Study seriously about cohesion, coupling, class and method responsibility, SOLID principles.
  • Solve the problem first, then code the solution.
  • Don’t be afraid of throw code away.

An experienced software engineer should know how to use the available tools to produce the desired result with the minimum complexity and effort.

On the other hand, developers love to reinvent the wheel. In my first years as a developer, I thought to my myself: “I have no reason to learn framework XYZ if I can write my own framework!”. Yes, I’m guilty. I wrote a lot of small frameworks. Did it help me? Of course! I tested my own limits, learned the internals of these little monsters and then realized the importance of the work of other developers. I threw much code away and now I’m happy using frameworks and tools knowing exactly how they work and why they do what they do.

Simplicity example

Watch this video as if the guy at right was you in college and the guy at left you with years of experience.


Who cares if the program takes a bit less time to run or how much “pretty” the code is? Are we talking about the developer’s ego?

A mature IT professional should strive to improve his communication abilities. Whatever is your specialization, all artifacts in the development process should fulfill its purpose in communicating the information as effectively as possible.

Furthermore, it’s better keep our artistic skills for things like the International Obfuscated C Code Contest:

#define _ -F<00||--F-OO--;
int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO()

Creative Commons O blog State of the Art de Luiz Ricardo é licenciado sob uma Licença Creative Commons. Copie, compartihe e modifique, apenas cite a fonte.