Welcome to the Jungle (Redux)

Yesterday we discover that Mowser, the project founded by famous blogger Russell Beattie (and former colleague) was in the deadpool. Russ claimed that he ran out of money and had serious trouble with his finances.
Everyday startups are created and abandoned, but the point in this story is that he could not raise funds to continue with the project. We see almost everyday projects raising a lot of money for nothing, so why an authority in the mobile world cannot pass the first round? Well, honestly I don't know, but from my experience in Amplia, mobile and M2M markets are really really hard. Everybody recognizes the potential but nobody knows what are the killer applications of the mobile business.
Mobile applications are radically different of 'Fixed' applications, and they should have different attributes:

• Mobile applications don't need permanent interaction. You only interact with the application when an event occurs that requires your attention.
• Mobile applications are by the lack of reliability of the wireless networks- error prone. A good mobile application should hide the user of the status of the underlying connection. When the connection comes back, then it should restore the status with the remote services transparently.
• The mobile application must be 'always on'. Again, event driven interactivity.
• Mobile applications must be fasts. The less time the user is interrupted by the mobile device, the better.
• Data traffic shall not be a concern. Help users to know how much will they pay to their operator. The success of RIM comes of the fact that users know in advance how much will they pay for the service.
• If a user is always connected to the network or 'always on', don't make them login again in your service. Use the authentication and authorization services of your operators if possible, or find a smart way to keep the user information linked to his/her device.
  

What kind of applications will win the mobile battlefield? Well, if I knew it probably I would try to raise funds to build it, but I don't know. I guess that services around presence in the network, location, instant messaging, targeted marketing can be the mobile applications of the next decade.
What do you think?

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.

Last week I was talking with a friend of mine about my post Sometimes to interview developers can be funny. We commented how most of the developers do not prepare the interview, and how they come without even visiting the website of the company. So, here goes some basic stuff you should do before attending to an interview. May be it can sound too basic, but believe me if I tell you that some developers do not care about this five topics:

1. Visit the web site of the company and learn what's the main business of the company. It's incredible the amount of people who have not visit the web site of the company. The excuses vary from 'I was in a hurry' to 'I don't have Internet at home (!?)'.
2. Find information about the employees of the company. Use Linkedin, Xing, Facebook... may be you can find a partner or a colleague at the university that can give valuable information about the company. And may be you can be recommended before the interview!
3. Bring an updated CV/resume on paper and give it to the interviewer. Job boards information can be outdated, and you can always point some new cool stuff you are working on that can help you to start the conversation and bring it to your interests.
   
4. Dress code. Try to balance your personal taste and the kind of company you are attending. If the company is traditional, then shoes and a suit, or at least a tie and a jacket will always help. If it's a start up may be you can relax the dress code, but it can be risky. It's always better to overreact the first time. It's obvious that you must wear clean clothes and shoes. It's also obvious that personal hygiene is important when you leave the virtual worlds. It's hard to stay in a room for more than an hour with somebody that stinks, even being a super-ruby-on-rails master or a mega-oracle-dba hero.
5. If you are going to arrive late phone the company and inform of your delay. You can always say you are in a traffic jam, it always works and people will understand. If you decide not to attend to the interview -the job does not interest you anymore- phone them too and tell them whatever you want (the truth almost always works). You don't know what can happen in the future, but if your absence is unexpected they won't call you anymore.
   

What other basic things you would recommend?

There was a time when DBAs dictate how developers should use Their databases. It was early and mid-nineties and Their Word was The Truth. Those poor guys building client-server applications had to bow down before Him/Her and implement the Business Logic inside The Database Manager. Database hardware was expensive, but His/Her Highness could size the system easily because the number of clients connected was predictable. And that's what the IT Manager wanted; predictable figures.

Late nineties came and Web Application started to rule. Suddenly, the number of clients were unpredictable, the behaviour of the applications was radically different and for the first time in years, the DBMS was the bottleneck and The Master of the Data did not realize on time. So He/She asked to the IT Manager for better and bigger hardware.

IT Manager: Will it fix the performance problems?
DBA: We don't know, it depends on the number of clients on peak, the number of users in the critical path, the TV ads campaigns with the URL of the company...
IT Manager: So the bottleneck is the database?
DBA: Yes, the Web servers are almost idle...
IT Manager: Idle? My god! Can they do anything to relief the database?
DBA: Well, we can try move some business logic out to the application layer. If those lazy and hairy web developers could write good SQL...

And then a new trend started: move out of the database as much business logic as possible. The web developers started to code the SQL inside the application to relief the database.

The DBAs were upset, because these web developers coded really poor SQL and they don't even know about triggers, functions or views that could reduce the size or complexity of some of the statements. And they had to get involved in development almost like a Quality Assurance Team, rejecting poor SQL or aggressive tasks against the RDBMS. That was really disgusting!

By nature Good Developers are lazy. Writing SQL was like a pain in the ass, and wrapping the results in object models took a lot of time. The laziest of them all started to write little applications to create automatically the SQL and the code to return the results as object models. These little tools became in Object-Relational Mapping libraries. The Technical Leads explained to the IT Managers how they could save time using them, and the IT Manager was happy because he could show to the CFO and CEO that they were doing something to make that lazy web developers productive.

Then the nightmare of DBA started.

The DBA realized that the number of queries to the databases were increasing, and the complexity of the query was lower. A lot of simple queries... What's going on here? Sounds like a new intern writing crappy code...

DBA: Hi, is there a new intern in the team writing crappy SQL?
Development Lead: No, we don't have new people. What is going on?
DBA: Then somebody of your team is writing really poor code. I can see tons of queries as simple as a line of SQL!
Development Lead: Ah yes! That's the new ORM library we are using!
DBA: Well, that library is rubbish. It generates tons of shitty SQL. Ask the reseller to give your money back ;-)
Development Lead: No, it's opensource and free. And I see a lot of advantages using it. I think we should discuss it with the IT Manager.

IT Manager: Why this tool writes crappy SQL?
Development Lead: It does not write poor SQL. It creates simple queries, that's all. We can configure it to create more complex SQL, but sometimes the number of objects explodes and the application run out of memory.
DBAs: Why don't you use the already created Views?
Dev Lead: We cannot map Views to objects.
DBAs: So you are not going to use views anymore?
Dev Lead: If we can avoid them, yes.
DBAs: No views!? How am I going to optimize your complex queries?
Dev Lead: Well, we are not going to write complex SQL anymore. The ORM will do.
DBAs: And what about triggers and stored procedures?
Dev Lead: Out. Triggers and ORM does not match very well because it's hard to keep under control the changes performed in the DBMS. And Stored Procedures sucks, we have Java.
IT Manager: So, if there is no views, triggers and stored procedures, the DBAs can set your focus on keeping the system healthy and optimized, but not coding processes. Right?
DBAs: Errr... that's not exactly right...
IT Manager: And we can also transfer all these development tasks to the development team. Right?
DBAs: Correct, but...
IT Manager: And if the DBMS has no heavy processes inside, we can save some bucks in hardware, isn't?
DBAs: Probably yes, but if I don't track what is going on in the database system the system can die!
IT Manager: Of course! And that's what you are suppossed to do from now on. Help the development team to optimize how the ORM tools and libraries performs before going live.

Then the DBA role changed and became a slave of the ORM tools.

She could not recommend any more how to code the SQL code because it was an automatic process. And she saw how there was no gain in the performance because of the use of these ORM tools, even worse, she saw how the tuning of the database now was radically different due to the different characteristics of the SQL code. He thought that may be these new problems in the performance could make IT Manager to roll back to the old way, but it never happened. Actually, the IT Manager asked if it was necessary to have that very expensive Enterprise licenses if triggers, views and stored procedures were declining. Moreover, the application developers were implementing some smart caching strategies that really reduce the overhead in the database, saving millions to the company in hardware and licenses.

IT Manager: Should we try an opensource database?
DBA: Damn Gaving King...

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?

The shortage of Telecommunications Engineers and Computer Engineers is becoming a serious problem for the Spanish economy. Today we can read in the news we will need to import 30000 foreign graduates for our market in the next five years. The option is obvious: bring people from India and China.
I don't know if these politicians know anything about the IT and Telecommunications Global Market. How the hell are we going to attract foreign skilled workers? With paella, siesta and sangria?
The salary of a Java developer ranges from 18000€ to 35000€ in Madrid. Barcelona and the rest of Spain salaries are lower. So if you follow the salaries in UK or USA it's crystal clear that Spain won't be the first options. Most of the IT crowd in Spain can't barely speak English so the fact is that international workplaces in Spain are just a few compared to USA or the EU.
Hence if you want to work in Spain, you will have to accept a low salary and speak fluent Spanish. It does not sound very attractive, even having paella every weekend and Sangria in the evening...

And no, nobody has siesta in Spain in the workplaces and we don't dress like bullfighters when we visit our customers (You cannot imagine how many people have asked me if we have siesta in our workplaces in Spain...).

Today in several RSS feeds I have found the same news: Google has a new patent for mobile micropayments. Micropayments using a cell phone is not new at all. I have seen some projects in Europe, specially the Spanish Mobipay. It's a mature technology, but it's not very successful. There are several reasons but it's not clear why mobile micropayments are not growing. In my opinion:

• The fee is charged directly to the customer. If you buy a Coke in a vending machine and you pay 1€ with a coin, you have to pay 1.10€ with mobile micropayments. So the micropayment is the last option.
• For more expensive goods Credit Cards or Cash are preferred. Why? Again because the Credit Card fee is charged to the seller, not to the customer.
  
• With mobile micropayments your credit is given by the Mobile Operator. The Mobile Operator needs to cover the risk, and this is an overhead compared to the credit card model (everybody knows how a Credit Card works, isn't?)
  

Google could be successful if they follow the Paypal model (just like they do in Checkout) and they are Mobile-Operator agnostic.

Jonathan Schwartz says in SD-Asia: "...consumer cell phones on the Java software platform will drive demand for Sun servers...". "The marketplace is going to be defined by the consuming public as much as by the traditional IT decision-maker".

Can anybody explain to me how does Sun think this is happening? How end-consumers can drive the adoption of a transparent server-side technology? End-consumer sees server side services as a commodity, they don't care about the technology running the service if the service is good, reliable and cheap.

How can give me a clue?

Evans data on his semi-annual Web Services Development Survey conducted in June says that companies planning the deployment of SOA with a Java platform has increased slightly, but the companies deploying on .NET have declined by almost 20%. .NET is still ahead with a 31% and Java in second place with 28%. 25% will support both.
It seems the reason is the increase of the activity of the Open Source world, specially Eclipse, around SOA.
Read the press release here.

Surprise, Surprise! You can read in Jonathan Schwartz's Weblog that they will change the NASDAQ symbol of SUN Microsystems SUNW to JAVA!!!!
The arguments are: '... the number of people who know Java swamps the number of people who know Sun...SUNW represents the past, and its not without a nostalgic nod that we've decided to look ahead...Most know Java, few know Sun...Java means limitless opportunity - for our software, systems, storage, service and microelectronics businesses. And for the open source communities we shepherd.'

The day Steve Jobs said 'Java’s not worth building in. Nobody uses Java anymore. It’s this big heavyweight ball and chain' . Being a Java Zealot as I am, I should find easily a fist full of arguments, but may be he is right.

I have been working in the embedded and mobile world for almost four years in Amplia, and I can tell you that Java is far from being the best option for mobile and embedded development. Even for complex mobile applications I think it's not even an option. There is not a decent implementation of the J2SE for ARM microprocessors, on Linux or Windows CE. There are some implementations out there, but believe me, they are far from the quality standards that Java developers expect. Sun Microsystems realized long time ago that building a J2SE for ARM and embedded OS was hard and expensive and they gave up, abandoning the project.

Of course J2ME it's there. But J2ME was designed for devices with a lot of limitations in term of resources. Devices like mobile phones and embedded hardware. But not for PDAs and the new Smartphones with big screens. Try to build an application with a rich UI with J2ME. It's a nightmare compared to CF.NET for example. J2ME has been very successful for games and simple apps for mobile phones which can gain access to the hardware layer, but nothing else.

But Steve Jobs was not talking about the heavyweight ball and chain of Java because his big memory footprint, slow start up and all that techie stuffs. It's a ball and chain because means a marriage with Sun Microsystems. Steve Jobs would love to have a J2ME virtual machine for the iPhone... if it was for free. But it's not. All devices running J2ME must pay a fee to Sun, no matter if they use it or not. And that's a lot of money. For example, the IBM J9 J2ME implementation for ARM costs $6 per license. Why should Apple pay for it? They have the OS for free -a Symbian license costs between $2.5 and $5-, they have the browser for free -I don't know the license costs of Opera-. So probably Apple can save around $15 per device just using their own dog food. So they said:
1) is it possible to build web applications with HTML and Javascript on Safari? Yes, we just need to allow developers to test easily on Safari. Voila! Safari for Windows!
2) Can we migrate Flash to the iPhone? Yes, and it is easier to port it than a full J2ME stack. Games, Video Streaming and Rich UI apps can be done in Flash too.
3) How many applications today need offline behaviour? Not too much, but less than a few years ago with a rise in the trend. And the device have been designed to be 'always on and connected' to the GSM network and WiFi. The 'offline' behaviour is not so important.

And they decided not to include Java because gave nothing to the business model behind iPhone.

But Mr. Jobs forgot something:
1) Mobile devices (and iPhone too) needs to have access to the hardware to control the low level resources like Bluetooth, GPRS modem, SMS messaging, Wifi connection, Serial ports. A web application cannot access the hardware layer.
2) May be the offline behaviour is not so important, but wireless networks are not as reliable as fixed networks. Offline behaviour from the browser is not mature at all.

So Mr. Jobs and the iPhone needs a piece of software to complete his Masterplan. They need an Embedded Application Server. What? Are you crazy? An application server? In a device? I will explain myself. When we think of an application server, we imagine a J2EE implementation with a plethora of functionality. But this app server is different. Here goes a list of what I think it should implement:
- A small web server to deliver content to the local Safari web browser.
- A scripting language to write server side code. Of course this dynamic content should only be served to the local Safari web browser.
- Massive Multithreading is not a must (it's all local).
- A permanent storage in the device for offline operation.
- Management of the low level resources of the device.
- Some kind of queuing system for asynchronous operations between the device and the remote elements.
- A synchronization service between local storage and remote storage.

This embedded application server should implement a scripting language. Why scripting? Because the logic to implement in a device must be simple by definition. The really complex stuff is the management of the hardware layer, and that's should be implemented in C/C++ and be very restrictive regarding the access of applications to this layer.

There are already some solutions out there in the embedded world but most of them focus on the Synchronization service when the really hard stuff is to control the hardware layer.

Since the successful IPO of VMWare, it seems everybody is talking about them. Today we can read in Bloomberg that they are competing with Google for the best programmers. VMWare is paying $120.000-$130.000 plus stock ops to talented developers. Compared to the spanish salaries that's really a huge amount of money. They have right now 500 open positions in Palo Alto offices.

The Skype affair finally was over, but the price has been huge. While the markets are recovering from the drops of last week, eBay does not follow the trends of the markets. The image and reputation of Skype are now below zero. Just keep in mind that Skype is the one of the biggest (or the biggest) Telecommunications company in the world per number of registered users. Business and pay per use users will think twice before contracting them in the short term.

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.

I have not been able to use Skype for more than 24 hours, just like the rest of the world. It seems that the problem is serious. It has been reported that it's an issue with a new version of the application. But it's not so clear. Such a long outage must come from (and I'm speculating):

1) A failure in the data migration from the early version of the application and a bad (or nonexistent) rollback process.
2) Massive failure in the storage and problems with the recovery process (I have seen this problem a lot of times).
3) Skype has been hijacked by malicious hackers. I don't believe it.


Whatever it is, it's costing eBay one billion dollars. That's more than $11000 per second. Let's see if they can fix the problem before the markets open.

Update 17/08/2006 13:16 GMT+2: It seems that an exploit that causes a denial of service was published by an anonymous user in SecurityLab.ru.

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...