Welcome to the Jungle (Redux)

There is a very interesting discussion about how good or bad are code reviews in Martín Pérez's Blog (sorry, in Spanish!). Most of us think that the biggest problem of coding convention is the ego of the developers. But here comes something very difficult to manage, specially when adopting code reviews for the first time: what if some developers reject to follow the coding conventions? How can we enforce developers to follow coding conventions? And finally: is the replacement of the rebel developer by a new developer an option?

Last years have been a wonderful time in Amplía Soluciones S.L., but nothing is forever and I think it's time for a change. I will continue as a partner of the company but I will look for new challenges and adventures out there. You can read my public linkedin profile if you want to know a bit about my skills and experience.

Probably the only common thing among all developers I have worked with is the hate to bug-fixing. No matter if bugs belong to them or not. As a developer and as a manager I have quite contradictory feelings.

As a developer there was nothing more irritating than the hateful Bugzilla emails. When I was working as Technical Lead of a development team in Madrid with a QA team in the West Coast of USA they usually started to work at our 18:00 and we usually left at 19:00 (Madrid is GMT+2 summer time). So we counted the number of bugs per hour submitted in Bugzilla and extrapolated to their 8 working hours to get the number of new bugs in the system. We left the office betting on the number of new bugs for the next day. We felt the QA team was our enemy and the relationship between both teams was difficult. We felt like being in 'Groundhog day' movie! We were listening constantly how bug-fixing is important for the customer, how new features were delayed because stupid bugs and so on...

As a manager I knew that bug-fixing was the most irritating part of development for developers, but you cannot avoid it. Bug fixing is a must. I'm very happy when I found new bugs in our products or projects and I tried to make developers to understand that it's great to find bugs before our customers find them -wrong!-. This is true for managers, if you find bugs in advance then the management team does not need to loose the face with the client due to problems with the quality of the product. But it is not true for developers, and I will try to explain why.

• Good developers are creators. They feel their work as part of them. Most of the programmers are people very motivated because they like what they do. As a creator their work is his/her creation and telling them 'your creation has a defect' it's a bit like saying 'your kid is ugly'. We react like feeling attacked by the management, the customer or QA team.
• Programmers don't work like Managers do. Programmers need to find 'the flow'. We need time to get the focus on the problem, and 'the flow' must be durable. Managers work in 'constantly interrupted' mode. So emails reporting defects every X minutes, phone calls or 'mini-meetings' really disturb. Developers mentally link bugs to interruptions.
• Bug-fixing is normally underestimated in the project plans.They normally include the raw time to fix the defects, but not the time taken due to the 'context change' of the developer: from new feature mode to bug-fixing mode and back to new feature mode. These means that developers link again bug fixing to overtime, because it delays the development of the new features with due date.
• Programmers hate to hear from Management: 'It's great to find bugs before the customer finds them'. Why? Because we are not stupid. We know it. It's great to finds bug before the customer finds them and report to you, Bastard Manager. I will have to fix the bug anyway, no matter if the QA team or the Customer finds them. I have no tangible gain for fixing the bug before the delivery. But the Evil Manager does, he won't have to justify bugs to the customer, he will live better.

The summary is: Developers hate to fix bugs because they feel like being insulted (your kid is ugly), annoyed (emails, phone calls, minimeetings), poorly managed (overtime), cheated (finding bugs in advance is great!).

What can we do -as a Manager- to minimize the impact of bug-fixing in your team?:

• Developers will feel attacked every time a bug is found. Remove all adjectives when referring to bugs. Example: This is a stupid bug, this is a trivial bug... Just use the adjectives to categorize them. Use the terms used by your tools.
• Never ever tell a developer how to fix a bug, except if he/she asks for it. Example: This is just an 'if...then...else'... 'Use a try...catch...'.
  
• Do not allow customers to call or send emails directly to the developers. Customer does not know how to communicate the defects. The defects reported by the customer must be handled by the Managers.
• Set up your bug-fixing reporting tools to send the bugs once everyday or better, once per iteration. Only categorized and approved bugs must reach the developers. Avoid unnecessary stress.
  
• Don't forget to size your projects with enough time for bug-fixing.
  
• Dedicate one or two days per iteration to 'bug-fixing days'. Stop the development of new features and get the commitment of the team to work hard that couple of days to 'clean the bug list'. If the environment of your organization allows it, bring drinks, food and have some beers afterwards. Give the same relevance to the bug-fixing days than delivery days.
• It's great to find bugs before customer finds them, that's true. But don't use the excuse of the customer anymore, or at least not so often. For programmers customers are irrelevant, they/we are not customer oriented. Change to 'We will find bugs for sure, and every time we find a bug we should congratulate because the QA team is doing an excellent job. If we don't find bugs then we are not doing good QA'.
  

What do you think? What do you recommend to help developers to fix bugs?

I have been testing Mingle, the new tool from Thoughtworks to manage Agile developments. The application really looks promising, and have a lot of new features that I'm discovering, but it's taking me more time than I expected because it's slow, very slow.

The guys from Thoughtworks claim they have built the first JRuby commercial application. Probably true, but the price they have paid is high. The application is slow, and it's slow even on a 2.8Ghz 2Gb Server. I have checked the default configuration and heap size is set by default to 1 gig. Not too bad for an application being use by a single user...

I hope they make some changes to improve the overall performance of the application. It's not very 'Agile'.

I have interviewed a lot of developers, junior and senior staff and it has become like a routine. Technical workers are nice people, rude candidates are rare. Usually their (our) self-esteem make them (us) feel they need to show they (we) are over prepared for the job. The curriculum vitae are bloated with lots of technical buzzwords that most of the people have heard of, but can't barely talk about them.
I have compiled the list of events I can remember interviewing developers because they were funny, very funny:

This man had an impressive cv full of buzzwords, but he only worked in a single project.
Me: So you have been working with J2EE for 4 years, right?
Candidate #1: Right.
Me: What's your favourite IDE?
Candidate #1: What?
Me: What's your favourite IDE. I-D-E. (Since this is an English acronym, I try with a vague Spanish translation: 'Entorno de Desarrollo'.
Candidate #1: Ah, Eclipse.
Me: OK. Which version of Eclipse?
Candidate #1: The one for Java.
Me: Yes, but what version, release, etc...
Candidate #1: I don't know. The architect tells me to use Eclipse...
The guy knew all the buzzwords, but he did not even know what the hell they meant.

This one did not learn the acronyms very well..
Me: So you have been developing web applications with java for two years, right?
Candidate #2: Right.
Me: Are you using JSTL?
Candidate #2: Yes, of course!
Me: Well, some developers feel JSTL does not help a lot...
Candidate #2: I don't think web applications in java can be developed with servlets...
Me: Sorry, I don't understand.
Candidate #2: With JSTL Pages you can embed your HTML code easily. It's very hard to embed the code in Servlets.
JSTL sounds very similar to JSP in Spanish... but only similar.

This one was so pathetic...
Me: So you have been developing web applications for two years, right?
Candidate #3: Right.
Me: Which Application Server?
Candidate #3: Weblogic
Me: Excellent! A good understanding of BEA Weblogic is a plus. Which version of Weblogic?
Candidate #3: Version... 2
Me: ¿ 2 ? BEA Weblogic 2? Are you sure?
Candidate #3: Eeeehhh... Yes, Java Weblogic 2 Enterprise Edition.
Me: ... sorry, I think you don't have good coverage there, I can't here you very well... I will call you again ...
I was not brave enough to continue with the interview without laughing.


This women really had a bad time
Me: Your technical profile is excellent. As you know, spoken English is a must for this position.
Candidate #4: I know.
Me: Can you continue the interview in English?
Candidate #4: OK...
Me: (I looked at my notes for a couple of seconds, and then I heard something bumping on the floor. She was laying there!)
The woman lost consciousness for a few seconds. She told me she did not expect an interview in English. That's what I call a shocking question.

Architect by default
Me: So you are the architect of an enterprise class application for a Telco, right?
Candidate #5: Right.
Me: What app server are you using?
Candidate #5: Tomcat
Me: Which version of Tomcat?
Candidate #5: 1.4
Me: I see... 1.4, and which version of the JVM?
Candidate #5: 5
Me: Right, right... Are you sure?
Candidate #5: Sure.
Me: Why are you using Tomcat 1.4?
Candidate #5: Well... actually... the former architect chose it. I don't know why we use 1.4.
Me: Why are you using JVM 5, then?
Candidate #5: Well... actually... the former architect chose it. I don't know why we use 5.
Me: Look, there is no Tomcat 1.4, and in that Telco you can't use JVM 5. Please be honest.
Candidate #5: Well... actually... the project is a nightmare and all the developers have left the team. I have not found a new job yet, and in order to keep me in the project, I was appointed Lead Architect by the top management. But I'm just looking for a new job and escape from that hell.
Well, he was honest in the end.

And this is what happens when you interview a psycho
Me: So you have been working as HTML and ASP developer, right?
Candidate #666: Right.
Me: Can you tell what are your tasks in your current job.
Candidate #666: What do you mean?
Me: Just tell me what you are doing: what you develop, how, who is involved, technologies... it's just to start the conversation
Candidate #666: Conversation?
Me: Yes, I think you are a bit tense. Please relax. Take your time to explain me your job.
Candidate #666: I'm no tense, but I don't like your questions.
Me: But we have not started yet... Which IDE are you using to develop ASP pages?
Candidate #666: (silence, he starts to sweat)
Me: Are you using a Microsoft IDE...?
Candidate #666: (he starts to breath anxiously)
Me: (Now I tense up...) ...are you using Visual Interdev?
Candidate #666: (he stands up and look at me) I have not came here to be judged, I just came here to be interviewed.
And he left the room while I was shitting my pants.

Being a Project Manager, Architect, Analyst, Developer or anybody involved in the development of software, you have probably suffered the 95 percent syndrome.
Imagine a software development project where things are going reasonably well: things are on schedule, Quality Assurance says things delivered are OK, the customer feel the progress, people are happy because they don't have to work overtime and they architect and developers can apply the Best Practises. You are very close to the end of the development cycle (if you are working with an iterative and incremental methodology) and confident about the result. It's time to review the overall status of the project, and then you check with the development team what is done and what is pending.
Project Manager: 'Requirement X is implemented'
Architect: 'Yes, it has been developed'
Quality Assurance: 'We have tested it and it has some bugs'
PM: 'How many bugs?'
QA: 'About 50'.
PM: '50???'
Architect: 'Yes, but they are trivial.'
PM: 'OK, great. I need an estimation for these bugs'.
Architect: 'OK. We have first to finish the pending tasks.'

And iterating over each requirement, we find out that most of the requirements are not fully implemented. Your feelings of confidence on the schedule are starting to fade away...
PM: 'What about the status of the Integration Environment?'
Architect: 'Well, we are having some trouble putting together all the stuff developed by the team'.
PM: 'What can of problems?'
Architect: 'Stupid things like different naming conventions in the URLs and connection strings, corrupt data in the database, etc...'
PM: 'Who is in charge of fixing this things?'
...<Silence>...
PM: 'I know, everybody is busy finishing their tasks... But somebody must work in the Integration environment'.
Architect: 'I can do it...'
PM: 'No, I need you to work with the developers to fix the bugs.'
Architect: 'Me fixing bugs?'
PM: 'Yes, what's wrong?'
Architect: 'Nothing... I will work in the bugs'.
PM: 'I know nobody wants to fix bugs. OK. Can developer X work on the Integration stuff?
Architect: 'He has pending tasks'.
PM: 'I know... We can assign his pending tasks to developer Y.'
Architect: 'But the context change can kill his productivity. Can we contract another developer?'
PM: 'No, budget is very tight and the a contractor will need to be in context anyway?'.

So now your feelings of confidence have fully faded away. Now it's time to calculate the delays and reschedule the project. Things are not going so well, so you decided to meet more often to track the status of the project. After a couple of Status Meetings, you realise that the bugs are being fixed, but new bugs arise. The integration environment does not work properly yet, and now the Business Analysts come with requirement changes from the client. Meanwhile, the client is getting nervous because he cannot see the progress like he saw in the beginning of the project. Developers are now working overtime to fix bugs and complete pending tasks and some of them are starting to complain about your poor management skills in the coffee breaks.

So what have happened here?

1. May be things were not going so well and you did not realise of it.
2. May be these problems are part of software development and you cannot avoid it.
   

I think this is part of the Software Development Game. The 95 percent syndrome comes as result of our education as Software Engineers. At the university they told us that everything has a solution, that there is only a way to build software. Wrong. They did not tell us that the biggest problem of software development is uncertain. Software Engineering has a very big problem as a Science: It has been created by Mathematicians and not by Engineers. For a Mathematician, uncertain is Hell. So they avoided uncertainty. I still can remember how Software Development was seen as a mathematical function,


Where x where the requirements, and Y was the software build. Terrible mistake. The waterfall model was defeated and iterative-incremental models came. And things were better. Now we had the following polynomial representation of software development.

Where each monomial can be an iteration. The good thing of this approach is that it assumes is not possible to build software as an image of the requirements, but it's possible to build software that can get closer and closer to the requirements. Why? let's put both formula together:


The only way to get P(x) = F(x) is when n is infinite. This means that we need infinite iterations to build Software that covers 100% the requirements.

Going back with the mere mortals, it's not strange to have a beautifully crafted Project Plan and a Gantt chart with a workload assigned for each tasks. We can create easily a chart like this:


The Project Manager thinks that the tangent of the function can vary, and with the changes he can control the delays from the schedule, and recalculate the schedule. But he is wrong. He is wrong because he is assuming a function like the one above, a function that assumes that the workload to build a requirement is the same at the beginning of the project and at the end.

The truth is that the function that describes the progress of a development is like this:


And this chart says a lot of things:

1. The workload to build a requirement is dependant of when is being developed. There are a lot of factors (integration tasks, QA team performance, requirement changes...).
   
2. Requirements being developed at the end of the cycle are more "expensive" than requirements at the beginning. The requirement can be simple in itself, but now it's part of a very complex situation.
3. It's almost unavoidable to leave requirements out of the iteration. If you want to keep the schedule, you will have to move requirements to the next iteration.
4. And 5% of the project can cost like 95% of the project. This is the 95 percent syndrome.

What can we do to manage the 95 percent syndrome? I'm afraid this is part of the Software Development game and we can't avoid it. So we will have to live with it. How? My personal recipes:

1. Ask the client to classify the requirements by priority before starting the iteration.
2. Ask the architect to classify the requirements by complexity before starting the iteration.
3. Build highest priority and complexity first.
4. Schedule several 'bug fixing days' in between the iteration. Stop the development progress and work on the bugs these days.
5. Keep in mind that Integration tasks depends directly on the amount of elements to integrate and it's not a linear function. Probably it can a be logarithmic.
6. Keep a buffer in the Project Plan, and do not say a word to anybody.
7. Do not accept changes in the current iteration. If you don't have any choice, then reschedule the project as if you were punishing the client.
   
8. Explain to the client on every meeting that most of the times some requirements are moved to the next iteration. Since most important requirements are built first in the iteration, only low priority requirements are moved.
   
9. Do not reschedule the iteration eternally. Try to close it, even with less of the 95% of the requirements.

These are my thoughts about this special syndrome, but I would like to hear from you. Please post your tips and recipes.

Today I have discover Preezo, another web 2.0 presentations tool that looks like a killer for Microsof Powerpoint.
The interface is mixture between Writely (sorry, Google Docs) and Microsoft Powerpoint. It's surprisingly fast (faster than Google Docs) and you can build simple presentations very fast. If you are familiar with MS powerpoint then you can build a presentation easily.
The application allows to send by email the presentation, publish on the web and broadcast to the net and it's also possible to embed it inside a HTML page just like any other web 2.0 widget.
The site looks professional, and I have not found any bug. This is a surprise because the company is owned by a single person. Seems it's still possible a stand alone developer to develop professional software.

I have read this post: 'Architects: If you can't code, don't apply for senior dev jobs' and I can't wait to share something happened to me not so long time ago.

I was interviewed for a position of Chief of Development in a start up. I passed two interviews with Human Resources and I only had left a face to face interview with the CEO of the company. He was(is) a very well known IT professional with an impressive technical background, but he moved to the dark side: management. Seems he got fists full of dollars from stock ops in the late nine tees from a company located in Mordor (sorry, Redmon).
The face to face interview was strange: first, he asked me random technical questions but never looked at my face, he continued looking at the screen of his laptop... 'This is not a good start', I was thinking... Then he looked at me, took some sheets of paper that handed to me and said,

-'Well, now it's time for the written coding test!'.
What? A written coding test for a management position? I was astonished, and he realized of it. - 'Is there any problem with the coding test?', he asked me.
- 'No, just a bit bizarre, this is a management position, right?'
- 'Yes, but there are a lot of development managers out that have never developed a single line of code, and my managers MUST know to develop', and at the same time he handed me the papers.
- 'I agree, but obviously nowadays as a programmer I cannot score very well compared to a senior developer'.
- 'I know, you will be compared to other managers'. And then he gave me another sheet of paper with a question about threading. I identified it as one of the threading problems to apply for Google.
- 'The problem says to write the solution in C', I said, 'I can't code C directly without googling, can I write it in Java?'.
- 'No, I need it in C'. And continued looking at the screen of this laptop for several minutes.

I tried to write the solution and I must admit that I was not so blocked in my life. Even when I was a student at the university never ever I had that feeling. When my adrenaline faded way of my veins my mind became clearer and I could code the solution, pretty much the right one.

I gave the solution to the CEO and asked me how I felt. 'Bad' I said. 'I guess I'm not interested in this position anymore'.
- 'Why?', he looked surprised.
- 'If you want a Development Manager to test their knowledge about coding, you should explain that in advance'.
We shook our hands and then I left the building. One day later I called the Human Resources responsible of the recruitment and I told her I was not interested in the recruitment process any more.

- 'Why?', she was very surprised.
- 'It's quite unusual to ask a Manager to perform a written coding test without notice, I felt like falling into a trap, I did not feel comfortable'.
- 'But you did right, that's the CEO told me!', she sounded even more confused.
- 'No, I did not react very well; I was shocked and I almost lost my nerves. I could barely control my temper'.
- 'I'm sorry for that; my CEO is quite unusual and I think you could make a good team with him. Please, if you think it twice, let me know and call me back asap'.

I thought it twice, three, four and N times and never called back. I think it's important to know from the early beginning what are your roles and duties. I believe that Managers have to manage, developers have to develop and only under very special circumstances managers have to go deep into the code. Even in small companies and start ups it's important to understand this. Otherwise we can find some bizarre situations, like CEO submitting changes to CVS after an attack of 'I will teach these lazy programmers how real men code!', or Marketing VP changing CSSs or HTML files directly in the FTP server of the corporate website 'because IT guys need days to do it!', or CFO creating email accounts for his girlfriend, friends and family in the corporate MS Exchange Server (what does 'run out of space on server disk' means?). Yes, all of them are true.

Reading this blog about what he thinks a Natural Born Programmer is came to my mind a discussion about what is an excellent programmer and a natural born programmer.
The example given (detect if a number is odd or even) should be enough to differentiate between a natural born programmers and the rest.
But he is wrong.
This is the kind of solutions that people trained in Maths, Engineering or Physics can give, because they are smart people. And that's what a development manager should expect from a person with high level education.
A natural born programmer can or cannot provide this solution, but he will provide ONE or SEVERAL valid. But he/she will deliver it quick and working if thinks it's a challenge. But this kind of challenge does not motivate to a natural born programmer. The natural born programmer development is compulsive; once you give him/her a challenging target, he does not stop until he/she get it done. If you compare the productivity of the natural born programmer with other 'races' of programmers, you will find high peaks of productivity when he/she deals with something he/she likes. And deep valleys of productivity when he/she deals with repetitive tasks. Other programmers productivity does not vary so much.
What's the reason for this behaviour? Natural born programmers are like artists, they only motivate with their new creature. If you never ask an artist to paint the walls of your garage, don't ask a natural born programmer to fix stupid bugs or implement silly requirements. Ask him/her to create something he/she can feel proud of. Other programmers are professionals, they will do what you ask them to do if the tasks does not collide with their professionalism (if you ask them to serve the coffee in the morning, probably they won't do...).
Natural born programmers are rara avis, and they rarely fit in big Corporations, like other programmers do. The best place for them is small companies, start ups and not very long freelance-like contracts.
Natural born programmers have a gift: they can CREATE software faster and better than the rest of the humans. But normally they have some lacks when dealing with other colleagues, customers or just the rest of the world. A Human Resources VP of a very important Telco told me that normally brilliant technicians are Cyclothymic (seems to be a very well known pattern) but it's not clear if it's something to do with his/her nature or his/her environment.
I have known dozens (more than a hundred for sure) of programmers, but I have only known 2 or 3 natural born developers. And I wonder myself if I would contract them again...

I recently discovered the site gobignetwork.com . It talks about how to run a startup company, how to raise funds, and more interesting information. It's very US-centric, sometimes not valuable for a Spanish company (spain is different) like us.
I found in his blog a post that explains very well What your startup company boss wants from you. This guy sounds like the perfect mother****ing boss, but he is right :-(

Today an online Spanish newspaper congrats Isabel Aguilera (Google Spanish CEO) for not screwing up the purchase of DoubleClick by Google. Besides the sarcasm of the headlines, the newspaper says that the time of Isabel Aguilera in Google is running out, and she could leave the company very soon.
It's not a surprise that she will leave the company (the surprise is she has not been fired yet). Reading the profile and curricula of this women, I wonder myself if Google contracted the wrong headhunter.

When I read the slashdot post about internal emails from Microsoft, I did not realize of the content of this email until it was posted in javalobby.

The content is scary. The mail thread comes from 1997, so after reading this emails, you can interpret the history of Java, .NET and Microsoft-Sun trial upon a several clear facts:

• Microsoft did not ever want to suport Java.
  
• Microsoft does not care about cross-platform.
• Microsoft wanted to 'steal Java', so they liked Java.
• Microsoft commitment with open standards is 'a politically charged topic'.
• Microsoft did want to screw Sun.

Well, I have been working 13 years in the Technology Market, and when I hear expressions like 'screw somebody/someone', I know there is something very wrong with that person. And if that person is an engineer, then it is a bad engineer. A good engineer is always thinking on how to improve things, how to solve problems. NEVER on how to 'screw' something. If this email is the 'Microsoft way', then I understand why they are losing all good engineers in favour of Google.

But what I have never, ever heard is the expression 'let's steal the technology to this guys'. Not even to business (evil...) people. I have words to explain my feelings about these kind of people, but I cannot use it in my blog. The pride of this expression is enormous and really scares me.

Everybody knows what happened after 1997: Microsoft put all their strengths to defeat Java... cloning Java. They created .NET, a rip off of Java to compete with Sun's technology. Meanwhile, they forced Sun to take legal actions against them. Why? Because legal actions usually exhaust corporations. Microsoft knew they had more (financial) muscle, and that's always a big advantage. Microsoft started to push some standards, and they even supported some cross-platform initiatives (Mono).

After last agreement with Novell, Microsoft put the cards on the table: Microsoft failed to defeat Java, .NET is complete failure -only Vb6 programmers are the only developers that have migrated-, and their hated cross-platform CAN work. It's not surprise that Microsoft and Novell signed and agreement to avoid legal actions because patent infringement. Microsoft have catch Novell by its testicles, and who knows, may be SAMBA is not the only reason why they will not tighten them: may be it's mono.

Call me paranoid if you want...

Excellent talk about how to Deal with the toxic engineer.

Things are very different here in the eastern side of the Atlantic Ocean: you cannot fire an employee because you want to, you only can fire an employee as the very last resort . Firing an employee in Spain usually is a pain in the ass for the company. The company must have things clear to take this decision.

So if you have the very bad luck to contract a Toxic Engineer for your team, may be you cannot fire him, and you have to pay him until he leaves the company. Usually too late to save other employees for being intoxicated too.