Look At It Carefully And You Will Find Something To Improve

I propose you an exercise: when you come back to work tomorrow morning, navigate through the source code of your project and try to find opportunities of refactoring. Do it even if your boss didn't ask for it. Do it because you want some exciting time at work.

Refactoring is the art of changing what is already working fine. But to do refactoring you need an excuse. It could be design improvement, performance issues, security roles, and many other reasons. That's a risk you take to reduce the technical debit of the application, making it more stable and, somehow, improving your own productivity in the future.

This is not about being nice with the company or with the boss, but being nice with yourself. Why? Because problems tend to accumulate and, at some point, you will lose the control of your code. You will face hard times to deliver results and it will ruin your career.

Well, let's see this from a brighter perspective instead. You will learn a lot in the process and will soon realize that you are producing better code than you ever did before. The more refactoring you do, the more clever you become until a point where you may reach the level of innovation. But, what does it mean and how do you know you are getting there?

Innovation happens when you find a clear opportunity for improvement on what you are doing and you realize nobody else did it so far (at least you couldn't find it). That's not easy, but it usually happens when you do something repeatedly and you find yourself thinking about what would you do to do the same thing faster or cleaner. Let me illustrate this with a true story.

It was about String concatenation in Java: a classical issue stressed by numerous specialists throughout the years and probably ignored nowadays. Before JDK 1.5, despite its readability and simplicity, String concatenation using the operator "+" could produce a very inefficient code. Behind the scene, this operator was replaced by the bytecode equivalent of StringBuffer, which actually implemented the concatenation. The more you used the "+" operator the more instances of String and StringBuffer you would have in memory as well as a good amount of processing time to manage all those objects. Because of that, developers were pushed to use StringBuffer straight away and ignore the "+" operator. Look at the following example:

String title = "Mr.";
String name = "John";
String familyName = "Smith";

String message = "Dear " + title + " " + 
                 name + " " + familyName + ",";

Developers were used to write like that, but they were pushed to write this instead:

StringBuffer sb = new StringBuffer();
sb.append("Dear ");
sb.append(title);
sb.append(" ");
sb.append(name);
sb.append(" ");
sb.append(familyName);
sb.append(",");

You may agree with me that the first example is more readable than the second one. It's just natural for developers to use the "+" operator when concatenating strings, thus it was unfair to abandon that syntax. Fortunately, compiler guys did something about it, making sure that the JDK 1.5 would optimize concatenations. Instead of using StringBuffer, a thread-safe class, they created a new one called StringBuilder (non thread-safe, thus faster) and they made sure that a single instance of it would handle all concatenations as illustrated in the first example. That's an important move because they favored elegance instead of technicalities. The first example is automatically transformed at compile time into something like this:

StringBuilder sb = new StringBuilder();
sb.append("Dear ").append(title).append(" ")
  .append(name).append(" ").append(familyName)
  .append(",");

However, concatenations within a non trivial logic still require you to write StringBuilder in your code because the compiler is not that smart yet. For  example:

List<Student> students = studentBean.findStudents();
String intro = "The following students were approved:\n";
String listedNames = "";
String separator = "";
for(Student student: students) {
  if(student.approved()) {
    if(!listedNames.isEmpty()) {
      separator = ", ";
    }
    listedNames += separator + student.getName();
  }
}
String msg = intro + listedNames;
messengerBean.sendMessage(msg);

would be more efficient if written like that:

List<Student> students = studentBean.findStudents();
String intro = "The following students were approved:\n";
StringBuilder listedNames = new StringBuilder();
String separator = "";
for(Student student: students) {
  if(student.approved()) {
    if(!listedNames.length() > 0) {
      separator = ", ";
    }
    listedNames.append(separator)
               .append(student.getName());
  }
}
String msg = intro + listedNames.toString();
messengerBean.sendMessage(msg);

Ups! Did you noticed anything strange up there? It might not be obvious at a first look, but see how they check if the variable listedNames is empty before defining the separator. The class String has a nice readable method isEmpty() introduced in JDK 1.6, but StringBuilder still uses that pretty old way of comparison. Why didn't they do it for StringBuilder and StringBuffer as well?

Discussing the issue at the core-lib-dev mailing list, it turns out there is no apparent reason why they didn't do that before. Perhaps they simply forgot it :-) Thanks to a large refactoring, trying to improve inefficient uses of string concatenation, it was possible to find such inconsistency. I believe they still have time to fix that for Java 8, which is coming out next year. And they would fix that by adding the method isEmpty() in the interface CharSequence to make sure that every other implementation will be equally elegant.

That might be a simple thing, but every single detail matters when Java is under heavy criticism for being such a verbose language. So, go for some refactoring and find opportunities to improve your code as well as the language you use to write it! Let's move Java forward!

Great Experience at Frankfurt Airport and with Lufthansa

With all those crazy things going on all around the world these days, I believe sharing good news may help to compensate with good vibes all the negativity out there. It's a good thing to recognize good actions made by people around us.

Having said that, I devote this post to send a big thanks to Frankfurt Airport and to Lufthansa Airlines. I don't know how these companies are evaluated by their customers in general. Perhaps, we were simply lucky, but what has happened and the way we were treated are worth spreading.

We arrived at Frankfurt Airport in an United Airlines flight coming from the US (I have nothing to say about this company btw :-/). We were three: My wife, my one year old boy and I. The airport is enormous, but it couldn't be easier to get directions inside. We experienced good accessibility carrying our baby's stroller, with a negligible delay in comparison to other ways.

Everybody was genuinely gentle, from the immigration to the arrival in Brussels. No silly jokes, no excessive friendly behavior, just fine :-) That was the first contact we had with those people, thus they have no reason to exceed kindness, unless they were selling a false image of the company, which they didn't. We actually felt relaxed dealing with those people. We needed that after a exhausting 8 hours flight from the US.

Our baby arrived at the airport sleeping and stayed like that until Brussels. That's what I call the smoothest flight connection ever :-) The baby spaces are separated from the toilets and they are accessible within a range of 50 meters maximum. The security check has a special track for people with strollers and wheel chairs. We followed the procedure calmly and fast :-)  All that is so convenient!

Even things that rarely work were working that day :-) We didn't have our seats marked in the flight to Brussels due to some technical problems during the reservation. We were afraid to have seats far from each other and be forced to negotiate rearrangements within the airplane. Fortunately, the attendant managed to put us together. It never happened before! I may admit we were lucky ;-)

It couldn't be better until the boarding time when our expectations were exceeded! A lot of first and business class people around and the attendant called us to be the first ones to enter in the airplane. She called us out loud using the microphone and explained to other passengers that the baby would require some extra effort during boarding and it would help to gain some time after all. I call it intelligence and good judgment because that's exactly what I would do in her shoes :-)

Unfortunately, many airports out there banned such practice, which is the case of Brussels Airport and Washington Dulles, the ones we have been with our baby. Those airports following such stupid rule should give attention to families with babies and people with disabilities because this is not a privilege to a minority, but a necessity. They ignore the fact that it's tough to travel with a little baby. Thanks to Lufthansa, we arrived very relaxed in Belgium, with a big smile on our faces :-)

Interviewed by Java Magazine

The March/April issue of Java Magazine is released! You should definitely check this out!

By the way, they actually published an interview we did some time ago, together with Bruno Souza (SouJava, Brazil) and Michael Huttermann (Jug Cologne, Germany). That's cool! But I'm not a big star as they are, just a Java passionate guy! I do appreciate that! You can read the interview in the picture below or directly in the latest edition.

Many thanks to Java Magazine's editors for publishing that interview!

On The Illusion of Controlling People's Time

Software Engineering is going through an identity crisis. The old school has failed because of too much control, moving people away from what they really have to deliver. The new school, or agile fever, is more focused on humanities, directing all the attention to human beings. This approach practically decimated the old school, showing that writing software is not an exact science. It is actually unpredictable and cannot be done without creativity, inspiration and transpiration. Maybe the old school, which insists to exist, got confused by the fact that software execution, data processing, and system and hardware design are engineering stuff, but it doesn't mean that developing those stuff is also engineering. On the contrary... it's human and social.

When I see managers trying to measure the time spent on people's daily activities, I understand they are taking into consideration only the transpiration of their teams and completely ignoring the creativity and inspiration. These two last aspects are so subjective that it's hard to compare their manifestation on different people. How to compare artists? We may find artists' comparisons out there, but they heavily rely on who is producing the comparison. Let's ask ourselves: why on earth would someone use quantitative criteria, such as time and money, to measure and compare subjective matters?

Measurements are only useful when we're capable of making comparisons with them in an objective way. We compare the date of our birth with the calendar to know our age. In times of crisis, we pay attention to our water, gaz and electricity consumption and make comparisons, finding ways to save money. Climate is measured because we need to decide which clothes to wear or which precautions to take by comparing with previous experiences or common sense. Notice we put measured subjects into perspective to understand the real dimension, the scale, the direction, and then we're able to reason about trends, behaviours, issues, patterns, etc.

When it comes to subjective matters, we might be able to make comparisons, but measurements are just useless in this case. Actually, we can come closer with a lot of statistical methods, multi-variable analysis, multi-criteria craziness, but do we really have time and resources to produce all these analyses in a daily basis, and even take the risk of being probabilistically far from what it's expected? It sounds complicated, isn't it? That's because it is. :-)

In software development, every activity is different from one another. It's impracticable to precisely compare two activities even if they look the same and are done by the same person. It's all subjective, otherwise it would be easy to put the project on schedule by adding more people in the team. We know that since 1975, when Frederick Brooks published "The Mythical Man-Month". So, when a manager asks their developers to inform the time spent in every activity, he/she is in fact collecting lies (or non-truths). If he/she prepares a report with those collected times, this is going to be the spread of an even bigger lie (or useless information).

But why lies? There are two good explanations for that:

1. most people don't track exactly how much time they spent on their activities, thus they actually inform safer figures, which are usually higher than reality;
2. time control gives a feeling of surveillance, making developers believe their manager wants to know whether they are really working or not, thus they smartly add some extra time to mask non-productive time.

Managers should also be aware that time control also kills creativity. When developers have new ideas, potentially useful for the project, they cannot simply turn them into activities because of scope constraints or just because those ideas are not clear enough to be described. Without activities, developers cannot report their time. Therefore, if they spend too much time working on their ideas, it will look like huge time gaps for their managers.

Eventually, managers are moved to implement time control because of visible procrastination. I remember once when a new project was starting, a big room was allocated to a team of 12 people, and the project manager asked the team to choose their places in the room. There were 15 places available, 12 with monitors facing the wall and 3 with monitors facing the door. Guess which places were left available? That's right! The three ones facing the door :D I remember the symphony of mouse clicks and sudden movements when the manager walked through the room. That was so funny! :D But time control wouldn't solve that problem because inputing time on activities is also a distraction. Anything that is not building deliverables is a distraction. We may never eliminate them, but we can always reduce them. The solution for procrastination, in a single word, is: Motivation!

But, is time control totally out of sense? It has some sense when the work is fully based on time, which is the case of consultants payed hourly. This is about their business model, not software engineering. That's a good practice for consultants to inform to customers how many hours they had spent because it's directly related to their payments. Notice that this kind of service is for a short period of time and for highly specialised skills. However, we are talking about software projects that last longer.

Finding ways to motivate your team is the best strategy to put them on track and fully productive. Every form of control that threats their feelings will put them down. Motivation doesn't need to be monetary or entertaining. Sometimes, it's enough to show their wins, how important is their work for society, how it changed people's lives, and why it's important to keep doing what they're doing.

"One reason programmers dislike meetings so much is that they're on a different type of schedule from other people. Meetings cost them more. For someone on the maker's schedule, having a meeting is like throwing an exception. It doesn't merely cause you to switch from on task to another, it changes the mode in which you work." - Paul Graham

Featured on Oracle's Java Magazine

I'm glad to see I was featured on the latest edition of Oracle's Java Magazine (Issue January/February 2013, page 67). I would like to thank Oracle on behalf of the CEJUG Community. We have been partners for so long and this is a nice way to demonstrate that you guys, at Oracle, recognise our contribution to the Java Community.

It's important to say that they cut part of my hair using Photoshop. I'm actually more handsome than it looks like... hehehehe :D Joking! Back to work!