Insomnia

Software projects have a reputation for costing too much and generating very unpredictable results. In this age of cost-consciousness, the trend that I am seeing in my customers is to try to avoid that problem altogether trying to strike fixed-price arrangements with a contractor. From a business point of view, this just seems to make sense. To ensure that they get what they pay form, they will use contracts and a big specification document as a yardstick by which to measure the achievement of the objectives.

This is far from someone just asking a contractor:"How much is it to build me a software to track my sales?" but it reminds me of a movie called bedazzled. In that movie, a guy strikes a deal with the devil and gets a certain number of wishes. In the first wish, he wants to be rich. The wish is granted but he is now a Columbian drug lord with people trying to kill him. As the movie runs its course, the guy gets much more precise in his wishes but he consistently forgets a details and never gets what he wants.

Of course, in the movie, the devil tries to find the flaw on purpose and takes advantage of it (what do you expect... She is the devil). Assuming the contractor you choose is not trying to build something you don't want on purpose, the system described in the specifications might not be the system that you really want or need.

This being said, I will sometimes find myself on the contractor end of such a project. The customer realizes (often after discussing various alternatives with me) that the system that was described in the specification doesn't solve their particular problem. Because the budget is fixed, I find myself with few alternatives. I could finish building the original system and have an unsatisfied customer. I could agree to a change in the original plan. The problem there is that any change will have an impact on cost. That increase in cost will have to be spent either in actual dollars or by removing some functionality. This will no doubt be interpreted as a failure of the contractor to provide accurate estimates. I'm not sure what is worst.

I wonder about the feasibility of micro-engagements where the contractor and the customer would negotiate an arrangement on a feature-by-feature basis. Some sort of Extreme-Contracting where the contracts would be short enough (4-8 weeks) that the content of the deliverable would be unambiguous. If the requirements changes mid-stream... The work lost has already been accounted for and approved. I think that this is a model when the risk of going into a software project is more clearly spelled-out and is shared more equally between the contractor and the customer.

Labels: work

• 0 Comments

Slashdot | Dell Moves Call Center Back to US

The reason why it is worth reading is not that it is so enlightening or funny but because it seems to accurately illustrate the general frustration experienced by a lot of people in the North American IT industry. As a services company, my employer has had to deal with this kind of competition more and more. Most of the points that are put forward in this discussion have been put on the table to try and understand/solve this problem.

• 0 Comments

Look here for the article (free surscription needed... this is where mailinator is really useful)

Immediately, some people at the office got offended and said that the journalist must have misquoted me because I said that the whole .Net tools were "inflexible".

With regards to my comments. It is obvious that the 1/2 hour conversation I had with the journalist did not make it all into the article but she managed to preserve the main idea.

The part that might have lost its emphasis in the transcription is that the concept of flexibility lost that I mention comes from usage of all the wizard-based development and not from the language or platform itself. Even if Microsoft has gotten really good at making wizard based development tools, if you want your solution to be usable in more than its original context, you often have to step outside the wizard and this is usually where you step out of the "path of least cost" afforded by those tools.

I'm a big fan of using the right tool for the job. If a perl script or a VB application will do the job, I won't create a J2EE web app.

• 0 Comments