Claude Montpetit -- Montpetit.net -- en

A refreshing and encouraging view on offshore outsourcing. I could have picked many paragraphs as excerpt. I liked this part:

How can these figures [i.e. IBM outsources 3000 jobs but adds 4500 jobs in the US] fit with the widespread perception that IT jobs have left the United States? Too often, comparisons are made to 2000, an unusual year for the technology sector because Y2K fears and the height of the dot-com bubble had pushed employment figures to an artificially high level. When 1999 is used as the starting point, it becomes clear that offshore outsourcing has not caused a collapse in IT hiring. Between 1999 and 2003, the number of jobs in business and financial operations increased by 14 percent. Employment in computer and mathematical positions increased by 6 percent.

It is also worth remembering that many predictions come from management consultants who are eager to push the latest business fad. Many of these consulting firms are themselves reaping commissions from outsourcing contracts. Much of the perceived boom in outsourcing stems from companies' eagerness to latch onto the latest management trends; like Dell and Lehman, many will partially reverse course once the hidden costs of offshore outsourcing become apparent.

The essay where I took the excerpt in my previous post lead me to other articles and books related to the subject of innovation and profitability. First, from Breakthrough ideas for 2004 (pdf format), idea #5 caught my attention: The law of conservation of attractive profits.

The author, Clayton M. Christensen, briefly describes this law as follow:

• Products are most profitable when they're still not "good enough" to satisfy customers. This is because to make them performance competitive, engineers must use interdependent, proprietary architectures. Use of such architectures makes product differentiation straightforward, because each company pieces parts together in a unique way.
• Once a product's performance is good enough, companies must change the way they compete. [...] To compete in this way, companies are forced to employ modular architectures for products. Modularity causes the product to become undifferentiable and commoditized.
• [Profits] move elsewhere in the value chain, often to subsystems from which the modular product is assembled. [...] Hence, the subsystems become decommoditized and attractively profitable.

[...]

Because the hypothesis suggests that the location in the value chain where attractive profits can be earned shifts in a predictable way over time, companies that outsource activities that are not today's core competencies may well miss the boat. This "law" might help managers foresee which activities in the value chain will generate the most attractive profits in the future so that they can develop or acquire competencies where the most money will be.

From David Stutz:

New platform efforts that set out to be highly modular or deeply object-oriented from day one are doomed to fail, because they are recognized as being vulnerable to cloning by potential ecosystem members and are consequently not adopted because of their lack of business potential. Truly useful standards always come after the fact, and often without a formal standardization process. Successful platforms ossify, leaving standardized patterns of information in their wake.

Excerpt:

J'avais installé linux Mandrake 9.1 il y a quelques mois en mode double amorçage (dual boot) sur mon système XP édition familiale. Mon système XP occupait la première partition et Linux les 2 suivantes. J'ai choisi d'éliminer Linux Mandrake... more

From the latest post on the BileBlog:

So come on people, if your job is boring, please accept that and try to find fulfilment elsewhere. Do not write a framework or seek the approval of other tossers in your field. Find some other, more private, way of coping. There are plenty of ways to find fulfilment that do not involve using the latest 'cool' library.

Ok, so I have to admit it: I have been reading the BileBlog in secret for some time now. But his latest post deserves that I get out of the closet. It is on a subject I wanted to talk about and despite his writing style, I kind of agree with him on this subject.

If I go back to the days I joined Corel on the CorelDraw suite team, developers were enjoying their work: invent new ways to draw on a computer. The domain was the theory of 2D graphics. The cool thing was to see a complex shape take form on the screen using a mouse and clicking here and there. Developers were excited to work on this product because what was being built was cool. During these years, building a common reusable set of components was not important. Implementing a fast rendering engine was important. Figure out how users could draw curves with a mouse was important.

Today, software is in every domain. From accounting to robots that take photos on Mars. Take the robots for example: what do you think NASA developers cared about when building the software that drives the 2 computerized photographers up there? Using the latest technology? Building a framework so it is easier to build other robots for other planets, other surfaces? I doubt it. I believe their head was filled with the images of their pet strolling on the red sand.

Now, take a developer working on the implementation of an application in a domain that is of no interest to him, a domain where everything is known in advance. The technology used to build the application becomes the center of interest. Then, the temptation is high to figure out ways to introduce a new 'cool' technology, or even better, to create a framework that will be appreciated and used by other developers.

My point: as a developer, if I want to (1) be useful to my employer/client and (2) enjoy my work, I must understand the domain of the application I am building and enjoy it enough to become creative with it.

This is an excerpt of a post from Ken Schwaber, one of the authors of Agile Management with Scrum on the Scrum mailing list:

In my experience, if you reward people for something, they will do it. If you tell them you want esimates to more closely approximate actuals, they will do it. Will more product be built, or a better product be built? No, but we'll feel like things are more under control, which of course they aren't.

Nicely said; being better at estimates means you are better at estimates, not that you are more productive. This is an important statement. Of course, being good at estimates is important for a business where estimations are critical: In a fixed-price context, being bad with estimates is a bad thing; In a stand-alone product development context, marketing department promising feature delivery based on bad estimates is also a bad thing. But the important thing here is that productivity of the development team does not depend on the quality of estimates.

At first, I felt as if the last part of Ken's excerpt was not true. But if we assume we have a development process that is fully efficient, the estimate does not affect the control we have on this process: the development progresses efficiently despite a bad estimate.

So given these facts, and given only the two following options, which one is better: a bad development process with good estimations or a good development process with bad estimations? Of course, both process and estimation equally good is the best but stillI have my own answer.

Update: In the context above, a bad development process is one that results in a customer getting something he did not ask for, or not getting anything at all. Therefore, the 2 options could also be presented as follow: Is it better to deliver in the estimated time a product that does not meet the expectations of the client, or deliver a product that meets the expectations of the client at a time that exceeds the original estimation?

In 1998, when I was working at Macadamian, we started the development of a system of components used to produce complex collaborative web-based applications. Generic Item components were at the core of this system. Items could be assigned any type of fields (title, description, creation date, etc.) Items could be related to other items through Relation components (writtenBy, submittedBy, complements, etc.) Metadata (components as well) could optionally be defined to describe what items should be made of. Metadata, Relations and Items being components, they could be instantiated at runtime to construct a complete persistent data structure without any knowledge of the underlying data storage.

What made this product (trademarked Syndeo) powerful and unique was the addition of hooks. Hooks are components that can be attached at runtime to Items. Hooks are behaviours and they can be stacked onto items. For example, we used hooks to add workflow in the system so that new items inserted in certain places would be forwarded to a moderator. Security, and logging were also good hook targets.

We started this project after having done a lot of Windows API programming so the idea of Hooks was in fact inspired from MS Windows hooks. There are many technologies that offer features and concepts that are similar to hooks: database triggers, Java portable interceptors, and another one I found very recently: JAspect, an AOP (Aspect Oriented Programming) framework.

While very powerful, hooks, interceptors, or aspects, whichever you prefer, can sometimes cause problem during development. Their dynamic nature makes them harder to debug as opposed to behaviours that are statically encoded in the class' code. What you see is not what you get. Unexpected behaviours can occur if you loose control on the proliferation of interceptors or hooks. But used wisely, they are powerful. I did not try AspectJ yet but I will keep this in mind when I need to implement something across a system, something like error-handling, contract enforcement, distribution concerns, feature variations, context-sensitive behaviour, persistence, testing (from the FAQ).