Homo Sapiens 2.0

http://news.discovery.com/tech/transistor-cell-membrane-machine.html

Broccoli: the movie

…e ora anche fotografati!

Track your partner

The web tool for tracking your partner’s movements is now available!

The Toll Of The Devil

This is what drivers see at the toll of Agrate (Milan):

A note for non-Italian readers: the word means BILLS.

Coping with the economic crisis

The Great Crisis is impacting both computer industry and software consulting.

What is the best strategy to react to this? Strategic Visions recommends the following:

BOA: beyond SOA

Is the future in SOA? Are software consultants sure that SOA is the best choice for themselves?

The service-oriented architecture (SOA) is by sure the most discussed subject in the last years when talking about systems development and integration. SOA sets the focus on very important concepts like reusability, autonomy, loose coupling and abstraction. All of those things that make your systems easier to maintain, scalable and easy to test. Anything than positive, you should think. But as you know, kind readers, we are more concerned about people, real persons, than abstract concepts. In particular we are concerned more about software consultants than the more abstract software consulting. Are we sure that SOA is the best choice for a software consultant? Which are the SOA’s benefits for the long term?

Looking deeper to the so-declaimed SOA benefits, any top software consultant (I am sure that between our readers there are some) can realize that a sort of deathtrap is well hidden inside the SOA concepts. In fact, it is true that to define and implement a SOA system probably you need a very good software consultant, but what does it happen after? As said, SOA systems are easier to maintain, to scale and to test. This means that, for a given system, there will be always less and less need of a top software consultant, because future extensions of the system can be designed and implemented by does not matter who and customers are no more obliged to call you, THE architect, THE consultant, who created that masterpiece of system. Customers might call any consultant, experienced or junior, skilled or untalented. But you know what? They will call by sure the cheapest one. This means that SOA systems are on the way to create a future of not well paid consultants, with lower and lower salary, with less and less benefits. Company car? Business class? Gorgeous business lunch?  Forget all of them for your future. A customer with a SOA system can avoid calling the best consultant on the market and this will open the door to untalented, unskilled and, especially, underpaid consultants. I know what you are thinking: “who cares, I will work to a new system, where a top consultant like me is necessary”. Sorry, but you are wrong. This model of continuous growth already showed its weakness in the financial market and it is already showing that cannot carry on for a long also in software consulting. Customers invest less and less in new systems and this means that you have continuously to look for new customers all over the world. But globalization it is not helping you, because big companies buy other companies and they re-use already implemented system, reducing the number of potential customers for software consulting. We can affirm, without any reasonable doubt, that the SOA principles are not developing a self-sustaining and robust market for top software consultants.

From this evidence, we think that there good reasons to introduce in the world of system development and integration a new concept: the BOA, i.e. Bordel Oriented Architecture (Bordel is a French word meaning brothel, here used with the meaning of great confusion, mess).

BOA is a set of principles that top software consultants have to follow during phases of system development and integration. In some way, we can say that BOA has the opposite aim of SOA: to create systems difficult to maintain, to scale and to test and that absolutely require the presence of the top software consultants that created them for any kind of intervention. To do that, a BOA software architect has to implement strong coupling between components, no reuse of existing components but creating new ones with very similar behavior and absolutely no abstraction. In few words: customize, customize, customize. A particular attention has to be paid to testability of the systems: it must be extremely difficult to test, with no chance for automated test.

Another important point is the data model. Practically data model should not exist at all, and it is strongly recommended that system data are spread in different databases, based on different technologies. BOA strongly suggests not using standard relational databases, but to create any sort of custom database is possible. If a relational database it’s used, it must be absolutely not normalized, making the management of the database schema only a matter for very talented people.

It must be absolutely avoided the use of a middleware and it must be done an intensive use of native APIs of the different components to exchange data between applications (the use of undocumented API it’s even better).

All those practices will make your system very difficult to maintain and expand but, incidentally, they could have a positive impact on system performance (no database normalization=faster data retrieve; no middleware=less overhead to convert data to a standard message type) and you can use this argument with your customer.

We cannot show here all possible mechanisms that can be used to implement a BOA system, so we will come on this subject again, sure to receive good suggestions from our readers (maybe involuntary).

Swine flu infecting computers

Yesterday a Texas farmer reported the first case of computer infected by swine flu.
One of his pigs, Porkytron, is a well known nerd among the Java Pig User Group of Houston. Porkytron spent most of his time playing on-line video-games, which is his favourite hobby (in the picture on the right: Porkytron playing Mafia Wars on Facebook). When his veterinarian diagnosed the swine flu, it was too late for his computer, which ran Windows Home Edition and was not updated with a recent anti-virus list. Apparently, the swine flu virus has quickly propagated to all computers of Porkytron’s Facebook friends. Now the risk is that the virus passes from the computers to the users through the keyboards. According to some rumours, there is the name of Gianpaolo Tarantini among Porkytron’s friends list, and this is bringing panic to some well known Italian escorts.
In the meanwhile, the Houston Department of Health and Human Service published some recommendations to reduce the infection among computer users:

• make sure your computer runs at least an anti-virus program, with an up-to-date anti-virus list
• clean your keyboard with alcohol
• wash your hands frequently
• avoid to chat with pigs, when possible

Clown Computing Initiative

Our scope is that to help our readers to better understand the key concepts of Clown Computing.  Clown Computing is defined as an IT technology able to provide services in an hilarious and unpredictable way. Clown computing is strongly based on the synergy of different communication technologies (mobile phone,   internet chat, etc…) flavored with a bit of personal psychological approach. The better way to introduce the Clown computing key concepts it’s to describe the solution of a common problem for mobile user: printing to a printer. Top consultants are traveling a lot and often they are working in huge buildings unknown to them. Sometimes they need to print a document on a printer whose they don’t know the location inside the building. What they know is often a useless name like “Digital Printer” or an IP address, but nothing that can help them to locate the printer inside the building. There are lot of cases where top consultants were never able to find the printed documents, even after several printing trials to different printers. Clown Computing is able to solve cases like that. What you need is to apply a CCULP (Clown Computing Unknown Location Printing) technique. To use this technique you need, apart a computer and an unknown location printer, of course, also the following tools:

• A mobile phone
• A Clown Nose 

Before to print the document to the unknown printer, you have to insert in the first page of your document the following form:

The insertion of this form it’s fundamental to make the CCULP working. You have to put your mobile phone number instead of the text marked “<put your mobile phone number>” and print the document to the unknown printer. After a certain amount of unpredictable time (uncertainty is part of Clown Computing technology) you will receive a call by somebody that found your printed document, claiming for the one million dollars. You have just to ask this person where the printer is located, ask him to take the document and go there (believe me, he will explain you with very detailed directions how to get there). Remember to bring with you the clown nose, that is a very important component of the CCULP. When you arrive at the printer, verify that the person that called you is there and only at that moment, put the clown nose on your nose and say:”Little joke! There is no million to win. Now, please can you give me the document?”. It’s very important that you wear the clown nose while saying that. In some cases, the person refuses to give the document and in other few cases he/she shreds it in small pieces. It is demonstrated that wearing the clown nose it reduces this cases by 90%, making the CCULP a quite reliable technique. By the way, it is not possible to guarantee a 100% success, but uncertainty is part of Clown Computing technology, as already said.

Several researchers are studying how to reduce the uncertainty in Clown Computing technology and are obtaining quite good results.  Always considering the Clown Computing Unknown Location Printing  technique, they improved considerably its reliability  modifying the sequencing of the execution steps. They observed that asking to have the document before saying to the person that is a joke, reduce the unsuccessful cases by 98.5%, a sensitive improvement. In this case it seems that wearing the clown nose does not have a lot of impact in getting the document (you already got it) but can reduce the cases of injuries  that  can be caused by ireful persons.

Other researchers are working on how to improve the performance of the CCULP.  One of those researchers modified the mechanism of getting the document from a Go-To-There in a Bring-To-Me mechanism. In this case, when the top consultant that printed the document receives the call of the person that claims for the one million dollars, he has not to ask for directions to get to the unknown printer, but he has to ask the person to bring him the document in the place where the top consultant is. Because the building is unknown to the top consultant,  the person bringing the document will take less time to reach him than the top consultant to find the unknown printer, resulting in a sensitive improvement of the performance. By the way, in this case it seems that the Clown Nose wearing is not so effective in reducing the negative cases (document not delivered or shredded), indeed the  performance improvement being counterbalanced by an increasing in the delivery uncertainty.

Phenomenology of Requirements: project manager’s approach

We already talked about the developer’s approach towards software requirements and 2 major theories came out: the negative approach, i.e. rejection of requirements, and the positive one, i.e. improvement of the requirements. But does not matter which of those theories is valid, the fact is that the developer looks at the requirements with a philosophical approach and, with some extent, with a bit of romanticism. That’s not absolutely the case for other points of view. A software consultant acting as project manager has a less passionate approach towards requirements. He/she simply consider them as a technical tool to reduce cost and maximize profit. In particular, the project manager uses requirements to produce the minimum effort, allowing cost saving and profit maximization for his/her company and avoiding strong headaches for him/her. To pursue this target, the consultant applies several strategies, but some of those could have severe drawbacks. One of the most common strategies it is to maintain the requirement as vague as possible. In this way the consultant thinks that with any kind of application he/she can fulfill the requirement; of course he/she will use the easiest to develop application and the less costly (in this case a re-use of what already done for other projects it is strongly recommended). This strategy has a big drawback. In fact, we have not to forget that another important actor is playing with the requirements: the customer. He/she has exactly the opposite aim of the consultant: he/she wants to obtain the maximum from the requirements, maximizing cost and effort for the consultant (this is true for fixed price projects, where the price is fixed in advance and any variation is on charge of the consulting company). In this case, the vague requirement approach could come back to the consultant as a sort of boomerang, because the vagueness of the requirement can be equally used by the customer to ask for anything he/she wants, easily demonstrating that the application is not implementing the requirement as interpreted by him/her.

Another consultant’s strategy consists in writing a very detailed description of the requirements, just to avoid the drawback previously described: a very detailed requirement does not offer room for customer’s interpretation, so the consultant will deliver only what was promised, nothing more, possibly avoiding extra cost. About headaches, there is no guarantee that they will be avoided. In fact, in these cases you must be sure that you can really implement what was so precisely described. This approach is sometimes used by customers too. They think that using detailed requirements it is a guarantee that they will have what they are asking. Several scientists think that this approach reveal a weakness in the customer, that thinks not to be able to obtain from the consultant what asked, while very tough customer do not waste time to detail requirements because they are certain to obtain what they want from the consultant using very vague requirements.

There is no experimental evidence of which of those approaches is the most fruitful. It has to be evaluated case by case, based on the project nature, the consultant experience and the customer aggressiveness.  In several cases it happens that both consultant and customer adopt the same strategy, even if their objectives are opposite and this is again another evidence of the different perception of the same concept.

Nevertheless, any strategy is chosen by the consultant and the customer, it is designated to fail, because there is always to take in consideration the developer’s approach, that could never produce an application fulfilling the requirements. In some special cases can happen that the customer obtains what he/she desires, but the necessary condition for this to happen it is that this desire has not been expressed in any requirement.

OIM: The issue in Bilbao

While OIM is under construction, the customer has to survive with the current situation and we have to find a quick fix for some of the hottest issue. The first task is to understand why the on call support team from Manchester (UK) is not so effective and to propose a solution. Since this seems a company organizational issue, also our strategic business partner Accenture is involved.

We have investigated in detail how the team works. It is clear that the team guys strictly follow best practices for English football fans and on Saturday afternoon they go to Old Trafford after drinking some good pints on beer. Before and during the match they continue to drink and when they are requested to fly to Bilbao because there is an urgent support issue, they drink during the trip on helicopter. The policy if that  the helicopter cannot take off if at least 10 pints of bier for each team member are on it.

Unfortunately there is lack of communication and the security guards working during the week end in Bilbao facility are not notified that the support team may ask to enter on Saturday. So the guards see 40 English drunk guys singing Manchester supporter songs, marching all together and pushing to enter into facility. As a side effect on the beer drinking, some of them p** in the small garden in front of the reception, by killing the beloved petunias of the wife of the local top manager. The security guards phone their boss for asking what to do and we are able to report some parts of the discussion they have on the phone

Guard: cuarenta chicos Inglés … camisedas rojas … borrachos … todos borrachos

Boss: ??

Guard: quieren entrar

Boss: … Perros

Guard: Perros?

Boss: Perros …. PERROS!

So the guards follow their boss order and incite their ferocious dogs against the support team guys, who break away followed and chased by the dogs pack.

OK, Pamplona is known because of the race of the bulls in the town streets during the Fiesta of San Firmino, Bilbao is getting famous not only for Guggenhiem Museum, but also for the weekly Saturday race of the dogs chasing drunk English with red Manchester United shirts. People in Bilbao and many tourists coming also for abroad Spain follow the race, which is broadcasted to China and North America by satellite sport channels. There is a big bet business related to the race and experts note that betters on dogs win most of the times. It is a tough job to work in Manchester support team, the turn over is quite high.

So we have to fix that too.