Archive for September, 2009
Crusades are long past events in history, or are they? When was the last time you were involved in a software development crusade? Think about it, it could have been a discussion regarding calling a requirement functional or non functional or deciding what is the best text editor… The truth is that as developers we praise ourselves for our high rational capacities and for our ability to make objective and non emotional decisions/statements. Well let me just say: Ha!
Religious wars are one of many cancers from software development. Whoever wins feels like Richard the Lionheart trying to conquer Jerusalem, invincible and the unique holder of the real truth. On the contrary the losers feel outraged and waiting for revenge. It is obvious then that whenever you can, try to avoid them in your work environment.
Is it worth the discussion?
This is the key question to be asked, if you are about to start a new crusade evaluate if what you are going to fight for is worth more than 1 minute of discussion, if it doesn’t, then simply don’t take more than one minute discussing it. There are many techniques you can apply.
- Take a vote
- Ask the person with more experience in the subject matter to make a decision.
- Ask those involved in the discussion to make a joint proposal.
- Ask the formal leader of the meeting to make a decision.
But this is an important issue, and it is becoming a crusade. What can I do??!!
Sometimes it happens that the crusades are called over big issues that can’t be just short circuited. For these situations:
- Despite the egos, try to focus the conversation on the subject matter not on the persons.
- Remind what the goals are. I’ve seen crusades where the different sides will hold the flag of different technologies, swearing that their approach is the best remedy to all the bad things in the world, but, who cares if they are not the best tool for the goal you want to achieve?
- Have a clear prioritization.
- If you are stuck in a meeting, call it off and ask the crusaders to write a document explaining their proposal, and then revaluate the next day.
What you should never do in case of a crusade is to let the battle continue, or arrange to for new battles to come. You have to stop organizing brainstorming meetings involving all parties just to keep discussing over the same principles. That’s like motivating the crusaders to keep up their fight to the last man. Whatever it is, just make sure that you do something to stop it when a religious war starts in your office.
The non technical factors of a project are sometimes even more important than the technical ones, what follows is, in my opinion, the seven most important non technical factors to be taken into consideration to deliver good software.
1. – Have a clear development process.
A good process is fundamental for a successful project. It should be as lean as possible and everyone in the team should embrace it. It doesn’t matter if the process is agile oriented, or waterfall oriented, having a clear understanding of what to do and how to do it is basic to reduce waste and to align everyone in the team in the same direction, not having a clear development process is highly unproductive.
2. – Understand the vision and goals of the project.
It is easier to fulfil the customer needs when everyone understands the reasons behind the product development, that’s why every project should have a vision document and a list of goals, these documents should have high visibility and all the team should know them.
3. – Use iterations.
Even in waterfall projects it is a good idea to deliver the product in iterations:
- It helps to know if the development is going in the right direction.
- It makes easier the development by splitting a big problem into smaller ones.
- It provides value to the business sooner, so the ROI is maximized.
4. – Transparency.
Transparency helps to prevent some of the most common problems in software development.
- It helps to detect misdirection sooner during the development process.
- It helps to build trust.
- It helps to validate the planning.
In order to be transparent is important to enhance the communication across the team and with the stakeholders.
5. – Commitment.
The team has to embrace every decision and take them as their own decisions; it has to take accountability for failures and success, a committed team is likely to meet the different milestones of the project.
To have a committed team is essential to promote the motivation of the different members.
6. – Leadership
A good leader removes impediments, coaches the team, makes sure that all the conversations and meetings are fluent, and is always keeping an eye to make sure that the project is going in the right direction, a project without good leadership is likely to waste many time in meetings and development.
Leadership is spontaneous and is based more on informal facts than formal facts, the leadership doesn’t necessarily have to come from a boss, and don’t need to be taken just by one person, but it can be dangerous if two or more team members try to lead the team in different directions.
7. – Customer focus.
Instead on focusing on providing the best possible solution for a customer, some developers tend to focus in the different technologies/frameworks/architectures or tools which they think may fulfil them, that’s wrong, don’t ever let technical considerations to drive how your software is going to be, your software should be completely driven by what makes your customer happier.
The human factor is the most important element for the successful completion of software projects, hiring the wrong candidate is among the highest costs for the project. Keep in mind the following four mistakes when hiring to make sure you are taking the right decisions.
1.- Only ask specific technical/non technical questions
This is one of the most common mistakes I’ve seen interviewing candidates, there are companies that even rely on a standard multiple choice test to evaluate them. Only asking specific questions is plain wrong for three different reasons.
- If the candidate doesn’t know the answer of a particular question, it doesn’t mean anything, maybe he has forgotten the answer, maybe he has never work in that particular area…
- Typical specific questions are usually googled by everyday programmers, and that’s completely fine, why do you expect your candidate to memorize them?
- Specific questions don’t show at all how good the candidate reading, designing and writting code is, and that’s the purpose of the interview.
I’ve heard many times people arguing that tests are good because they help to make the selection process objective and easy, but that’s like looking for a wife/husband using tests because is objective and easy.
2.- Plainly believe that the candidate is always telling the truth.
Is common for people that has just started interviewing candidates to plainly believe the candidate, keep in mind that there are people who is pretty good at doing interviews and knows how to sound impressive, try always to get the candidate to explain details of the experience and projects he/she claims to have developed and get him to talk in specific terms of his choice rather than explaining them in general, high level topics.
3.- Hire a programmer just because the estimated time for the selection process is over.
You have to fill two positions and the estimated time for the selection process is over, If none of the candidates have fully convinced you, don’t hire anyone, is better to have an empty position than the wrong person.
4.- Not asking the candidate to do some code.
You are hiring a guy to code, don’t forget that, you don’t hire him because he is a convincing speaker, or because he has a PHD, never let him/her go away without testing his/her real coding skills, read this article to get a few ideas on how to check the coding skills of the candidate.
The most repeated sentence in code reviews…
2.- It works in my machine!
We all have used this one when blamed for some error…
– Hi Homer, have you removed the debug code from production?
4.- It will be ready tomorrow.
The problem with this sentence is that we use it again the next day, and the next day, and the next day…
5.- Have you tried turning it off and on again?
The TV series “The It Crowd” have helped to make this one even more popular…
Why do we keep asking why?
7.- Is not a bug, it’s a feature.
– It restarts twice a day?!! Well that makes sure that the temporary files get deleted!
8.- That code is crap.
All code is crap except mine.
9.- My code is compiling…
10.- No, I don’t know how to fix the microwave.
For some reason, non technical people use to think that every thing with buttons can be fixed by a programmer…