alex.rosiu.eu

When Democracy Fails

In a sane working environment, everyone seeks consense whenever decisions are to be taken, whether on minor or important matters. It is desirable for everyone involved to feel ok with the future plans, as it really helps not only for people’s morale, but also for getting things done.

Humans tend to be good at what they do if they do something they like. There are however cases when correct decisions can only be taken on - if you will - scientific grounds rather than their popularity. Consider, for example, the architectural redesign of a pretty large software application, which had evolved year to year into something difficult to debug, develop, or even understand. You will most probably organize technical meetings with the right people (not too many!), in order to figure out a solution. In those meetings, there is a significant possibility of rather different views to take shape. In such times, the handy approach would be to select the solution by voting, but it would be much preferable to do it by weighing the advantages and disadvantages of each alternative.

It may not please some for the moment, but in the long run, everyone will be happy to benefit from a wise, however not popular, decision.

All the Right Pieces

Building a strong team usually relies on finding skilled people you can trust, each one of them bringing value to the whole, by their personal, unique strenghts and qualities. Once you succeed in this, it’s up to you to take the challenge of offering them the opportunities to develop their skills, enabling them to become trustful experts which you will always rely on, when being asked for estimations, plans or just plain technical oppinions.

In this context, thinking of them as replaceable only makes you set an artifficial barrier on the way of their personal and the team’s evolution. The only replaceable one should be you, as achieving this translates into a powerful, self-organizing and tightly bound team. You don’t have to be afraid of this, because your company will most probably see it as an act of performance; and if they don’t, you wouldn’t probably want to work there anyway. Also, it’s nice to know you can take a one-week holiday once in a while, and when you come back things wouldn’t be a mess.

People usually like taking challenges, so empowering them to do things a little beyond their current knowledge will only help them develop. No proffesional would like to do the same well-known things every day, so by offering them tasks that require study, prototyping or exchange of knowledge with senior colleagues would usually motivate them in their work, so it’s a win-win situation.

Letting your people know about their value should make them feel more responsible for what they do. Still, remember to avoid establishing an environment where everyone tends to be a “star”. Try to create a Star Team rather than a team of stars, by encouraging them to collaborate rather than compete. They need to understand that they all need each other in order to succeed.

When you are fair to your people, they are fair to you in return. This enables them to benefit of evaluations, and improve their skills by taking your positive or negative feedback as useful input in their own development. It is therefore up to you to provide them useful information about their actions, and not theirselves - you don’t want to change them, you want to help them act as needed.

Having the right pieces, sometimes unfortunately means parting with the people that don’t “fit” in the picture you and the others are part of. If there is nothing you can do any more to help a person be on the “right” track, it is in everybody’s interest that he/she moved on. This doesn’t necessarily mean firing them, as you could help them find their place in another team in the company. However, it’s good to keep in mind that negative influences spread quickly, but so do positive ones.

Title picture © Ilya Postnikov | Dreamstime.com

The Bigger Picture

Mark was feeling worse, as the cold was taking over him. This was a somewhat new experience to him, as he had always been so healthy that it was really hard to even remember when he’d last felt that way. But his condition got pretty bad, so he picked up the Yellow Pages from the top of his nightstand and looked for a doctor. Although it was late in the evening, he found this very kind Dr. Harris who came right to his appartment and, after having him examined, prescribed him Darvon, 2 tablets each day, for his coughing problem.

As he was finally getting better, Mark could now go to work. But during his week off, a decent amount of files, one more urgent than the other, piled up his desk. He was really doing his best but he was still having a hard time sleeping every night due to the great deal of responsibilty that was screaming in his ears all the time. There came a time when, combined with his coughing problem, the situation became unbearable, so he had to do something to be able to sleep. He remembered his friend Andy, who used to take Diazepam for the same problem, so the next day he met Andy during lunch time and got a few tablets from him.

He could finally sleep. His cold was also getting better, and he was catching up with the unfinished work at the office. Things were looking better for Mark, until one day when he died in his sleep.

The authopsy revealed, not surprisingly, significant amounts of Dextropropoxyphene and Valium in his blood, which - taken in decent amounts - are not dangerous for the human body; hovever, when combined, they can usually cause allergic reactions and, to the least fortunate, even death.

Say It Out Loud!

Communication is one of the key factors that drive teams towards their goals, making possible the exchange of ideas, plans or problems. It is therefore crucial to do it efficiently, while keeping in mind that you’re still talking to humans and not some kind of information processing machines.

It is therefore essential to choose your media wisely according to each situation, but to my experience so far, nothing compares, in terms of efficiency, to just saying out loud what you have to say. Emails may be useful for storing decisions or ideas, but it’s by live talking that you can transmit them in the best way.

Personally, whenever I need to discuss something with my team, I always prefer talking to them rather than exchanging emails or leaving offline messages on their IM accounts. I do write emails on important matters, but mostly aiming to archive the discussions for later reference, or when they involve many people which may not be in the same office or on the same schedule.

 Title picture © Ghubonamin | Dreamstime.com

What’s in it for Me?

Change is one of most people’s greatest fears, and therefore introducing it usually meets significant resistance. We all tend to stick to what we know, as we usually get quite good at what we’re used to do. Thus, when being faced to important changes in our lives, work or habbits, we will most probably react by trying to reject them, unless we really understand the benefits.

This is why, whenever you need to introduce new concepts, technologies, or working styles to the people you are working with, you need to ask yourself “what’s in it for them?”, as you can bet they will all ask themselves the same question in their own minds. If you are really lucky, they’ll even say it out loud.

Even if they didn’t, it’s still fair to ask yourself this question, as you wouldn’t want to introduce something that brings them nothing useful, you wouldn’t want to do the change just for the sake of it. It’s up to you to take the challenge of finding the fair arguments that will make them understand the benefits of walking a new way, rather than accept a decision.

Title picture © Ilya Genkin | Dreamstime.com

SDBP08

Between October 26 and 30 - 2008, I’ve been fortunate to attend the Software Development Best Practices Conference in Boston MA. Apart from the opportunity of listening and free talking to people like Ken Schwaber, Bjarne Stroustrup, Mike Cohn or Scott Ambler, it has been a great time to visit a very beautiful city.

Forbidden Words

Communication is part of our every-day life, it is the key to all our relationships, personal or business, good or bad. In a high speed society like the one we live in, we tend to overlook the importance of words, spoken or written, therefore being misunderstood by our interlocutors. Hi-tech environments like IT companies, where we are mostly used to “talk” to machines by giving them clear and brief commands, expecting immediate action and answers in return, may sometimes make us forget that this doesn’t always work for people, who have feelings, beliefs, backgrounds and perceptions different from our own.

It is therefore essential to communicate not only efficiently, but also “humanly”. This latter notion involves respect and care for the others’ oppinions, beliefs and efforts, values that make or break, by presence or absence, relationships, friendships and teams. When you really believe in these values, you come to realise, more or less consciously, that there are some words that you might want to avoid when talking to your mates.

Must

You are a free person, so there is nothing that you must do. If your boss tells you otherwise, it is only because he’s not willing to take the time to explain to you why it is better, for you and everybody else that relies on you, to take those actions. It is much easier to tell people what to do then explaining them why to do it, taking advantage of a position.

You may say that there are still things that you must do, whether you want to or not. Like, for example, paying your taxes. If you think deeper, you will realise that you are in fact weighing the impact of different situations in which you land if you take one or another decision. As a rational being, you will then do what is better (or less bad) for you, but you still don’t have to do it. You’re doing it because you chose to.

Fault

When something goes wrong, the first thing that comes to your subconciousness is to make sure that you’re not “guilty”, and the easiest way to achieve this is by pointing fingers and passing the blame. Good news is, that you don’t need to do that when you are part of a team. There is no such thing as “fault”, “best” or “most” in a team. Responsibility, success, failure and difficulties are shared by all members, acting as one single bigger force which overcomes everything much easier than you alone.

Impersonal Passive Voice

How often have you read e-mails or heard news saying that “this and that has been decided”, or “has been done”? Have you ever asked yourself how come these things have just happened? Did they just occur by themselves, do they have a mind of their own so that they can take decisions by themselves? Why aren’t the people who have decided or done them, able to take responsibility for their own actions?

It is what it is

When things go really wrong, after there is nobody left to blame, and nothing obvious left to be done, people just say that “it is what it is”. Bad news is, that it’s not what it is, but what you made it. There are no dead ends and unsolvable problems, but there are people without the will to fight further.

I did my job

You might be one of those who finish things faster than the rest, and do them very well. Still, the project is falling behind schedule and it is likely to even fail completely if things go on like they did so far. It is the time for you to chose to be a superstar or a helping hand. Winners usually take the second choice, because there are no personal victories in a team sport.

Title picture © Aleksandr Stikhin | Dreamstime.com

Don’t Copy If You Can’t Paste

Xerox-boy

Matt used to be an appreciated developer at his previous job, but now he succeeded to join a much bigger software company, one which he and all his friends had always admired. His new colleagues started to trust him also, so he was assigned with creating one new plugin for their application. They were even so nice to show him other plugins’ source code, and explain him how they worked by means of code samples. In one week’s time, he got it all woriking well, but when his code was reviewed, this came out:

/*
* class CGuiSettingsPlugin
* Manages settings for the Graphical User Interface
*/
class CCommunicationSettingsPlugin
{
…
} 

He is now known as “Xerox-boy”.

As a developer, you are often faced with the situation of creating software components very similar to others, in terms of structure and behaviour. In those times, the easiest approach is to simply copy entire functions, classes, or even source code files and do some changes here-and-there. This habbit, however, has several darker sides which usually strike back sooner or later, one way or another.

Why Copy and Paste? 

Because it’s easy. Why rethink an architecture, why bother to try and convince the managers that the (proper) changes would take more time, why even bother when you can just copy that class, change its name and slightly modify one single member function? It has already worked for you so many times before, so it’s pretty much supposed to work this time too… after all, you are just duplicating something that’s already working.

Because others also did it before you. You are faced with adding a new branch to a decisional “switch”, that already contains 30 other alternative cases. You’re not supposed to change the whole logic right now, are you?

Wrong

Nobody said it was gonna be easy, and after all, it’s not always necessarily supposed to be. There are times in products’ lifecycles when architectures need to be revised, and code needs to be refactored. Postponing those times for too long may force you to eventually do the right thing exactly when you have no time for that.

You may not want to start thinking everything all-over by youself, and it also wouldn’t be advisable, but the least you could do would be to raise the problem, and make people aware of it. There will be for sure many who will understand the need of allocating time and resources for finding the right solutions.

Title picture © Mafoto | Dreamstime.com

0 error(s), 0 warning(s)

The boy is smoking and leaving smoke rings into the air.
The girl gets irritated with the smoke and says to her lover: “Can’t you see the warning written on the cigarettes packet, smoking is injurious to health!”
The boy replies back: “Darling, I am a programmer. We don’t worry about warnings, we only worry about errors.”

Many developers tend to give little attention to writing code that generates no warnings at compile time, thinking that since there are no errors, it’s all good.

However, if the compiler issues a warning, there is a good chance that there really is a not-so-obvious problem hidden in the code. If you dig deeper, you might find issues like 32-bit pointers used on 64-bit architectures, comparisons between signed and unsigned variables, and others alike.
What is more, these real problems will be obscured by the tens of “not important” warnings, and you will most probably miss them.

“Unimportant” warnings

If you come to think about it, why do you get these “unimportant” warnings?
Usually it’s because you forget about a declared variable which you no longer use, leave function parameters unhandled,  and so on. Problem is - why live with them? In fact, they only scream to you “Clean the code!!!”. Why wouldn’t you delete a parameter that you’re not using, or why would you keep an unused variable?

#pragma warning(disable …)

You may be tempted to easily prevent the warnings to annoy you by simply disabling them. Well, this “ostrich” approach is one of the worst practices that you might do as a developer.
There is one exception though, specifically when you are using 3rd party modules which are poorly coded and thus generate warnings at compile time. In that case, you really have no fault, there is nothing you can do about them, and it might be a good idea to disable them. Good news is, that you can disable the warnings only for the included header file, by wrapping it with a #pragma warning(push) / #pragma warning(pop) construction:

#pragma warning(push) // disable warnings for this header only

#pragma warning(disable:4213)
#include “header_with_warnings.h”

#pragma warning(pop)

The Bottom Line

Do not treat compiler warnings superficially. Use your compiler at its highest warning level and, if there are warnings that appear when you compile your code, understand them and eliminate them by fixing the code, rather than by disabling them.

Title picture © Les Cunliffe | Dreamstime.com

There Is no “I” in “Team”

Teams work thanks equally to all of their members, as they all share the same goals, problems, successes and sometimes failures.

As each one of them has a very important role, in the end there can be no good result unless they all work well together. Even if at some points, some of the members might seem to balance the team “weight” towards them, due to special events that might involve them more than the others, in the long run they all have the same contribution.

I like to think of a strong team as an orchestra playing a symphony: each instrumentalist plays his own score, contributing to the beauty and completeness of the whole concert. If any of them would stop playing, the symphony will just not sound right any more.

Let’s take the well-known Canon in D by Johann Pachelbel and see how it sounded if only some of the instruments would have played (the complete track is played by a violin, a cello and a viola).

Here is the violin playing what you might call the main tune. However, you will see later on that this tune sounds so much better when it is accompanied by the other two instruments.

Taken out of context, the cello’s part seems to have no meaning, even though it has a significant contribution to the whole musical piece:

In the end, please take some time to listen to the complete track. If you focus, you will probably be able to isolate each instrument’s part, but most importantly, you will surely be moved by the beauty resulting in their teamwork.

Title picture © Les Cunliffe | Dreamstime.com

“My Code Has no Bugs”

Even though it is practically impossible to write bug-free source code, some people really think they do.

It was the case of one of my former colleagues from a company for which I have worked for a couple of years. He was really thinking that he was extremely skilled (and he was… but not as much as he thought), which unfortunately for him, has led him to adopt a quite arrogant and distant attitude towards everybody. And I mean everybody, as you are about to discover later on.

Durig a tremendously difficult installation for an important customer - a pretty big hypermarket which had just opened - the service team has discovered a blocker bug within the system: transactions weren’t properly saved to the application’s database. After spending a considerable amount of time in order to properly reproduce and describe the problem, it came out that there was a problem in one of this guy’s modules. So they called the company’s HQ and described him the problem.

Well, this is where arrogance and ignorance came in. He totally denied that the problem existed, even though the service people were looking straight at it. There was no bug. They’ve uselessly struggled to convince him, but the problem was so big that they had to escaladate the issue. As ridiculous at it may sound, it was the CEO himself who tried to convince him to look after the problem. Even then, he kept denying that there was a bug, and only when the boss became really “persuasive”, he took a look at the source files.

It appeared that his code did have bugs.

So when you’re thinking your code is perfect… better think you didn’t test it properly.

Title picture © Alexandr Anastasin | Dreamstime.com