Freedom For Ideas

Sharing ideas, concepts and thoughts, mainly about Information Technology – and consulting

Archive for September, 2008

Adaptable vs Adapted

Posted by Yannick Martel on September 25, 2008

Is it adapted? Would you like to adapt it?

Is it adapted? Would you like to adapt it?

As IT practitioners, we all want to produce solutions adapted to the needs of our clients. And usually we want our solutions to be fully adapted to a bit more than what we understand of the needs of our clients. We want to cover more in case we have missed something. We want to prepare for the future. This is why we make such long analysis, produce documents with complex business rules and go through long and tedious review and validation processes. This is also why we work hard at designing generic, elegant, general solutions. In the interest of the future. And that’s the right way to do, isn’t it?

No, Sir, it is not. As Auguste Detoeuf was saying in the 30’s in “Propos d’O.L. Barenton, confiseur”:

Contrairement à une opinion répandue, on fait quelquefois trop grand. Il faut faire juste, mais en ménageant tout pour agrandir le moment venu.
On se borne l’avenir en faisant trop large, aussi bien qu’en faisant trop étroit.

Or, translated in English:

Contrary to widespread belief, we sometimes build too large. We must build just right, while keeping open to enlarge when the time comes.
You can restrict the future by making too large, as well as too narrow.

In fact, when we we build “too large”, we develop mechanisms and answers for questions which have not been asked. When they arise, our solutions have to evolve because the answers we believe were right are not anymore. When other questions are asked, the complexity we have unnecessarily added is an obstacle to providing new, unanticipated answers. Thus by trying to be over-adapted, we prevent our solutions to be adaptable, which is really what our clients needs – really.

We should instead apply Gall’s law:

A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

Our job in IT is to build complex systems. We should build a complex system by first building a simple system, satisfying simple needs. Then we can augment and satisfy more sophisticated requirements, while making sure that:

  • the system is still working;
  • the system is still adaptable.

These two points are difficult, and require effort every day, but only then you will be able to help your clients – and keep being able to do so.

This is the paradox: by being adaptable, we can succeed at always being adapted (although it is not guaranteed, and we can still fail). By aiming at being fully adapted today, we are guaranteed to fail at being adaptable, and thus to fail at being adapted tomorrow.

Advertisements

Posted in Agile, IT, Methodologies | Tagged: , , | 1 Comment »

Agile Adoption Patterns, 1, 2, 3

Posted by Yannick Martel on September 16, 2008

A sleeping volcano in Auvergne (France)

This looks like a plateau, but is in fact a volcano. Beware!

Let me confess it: I am not an expert in Agile. I have yet read only the first three chapters of Agile Adoption Patterns, from Amr Elssamadisy, and I already want to share with you how much it has inspired me. Especially in relationship with a specific project we at OCTO Technology are helping to get Agile. I will go on reading the remaining 43 chapters and may later review them here.

Agile is nowadays quite fashionable, and this very success generates its own problems. Amr mentions that the very first teams adopting Agile “methods” obtained 500% improvements in productivity, but that as Agile is becoming more pervasive and adopted by a wider audience we see more teams getting instead only 50% improvements, or failing to obtain any improvement at all. Indeed I now realize that the project I have in mind has probably reached this 50% plateau. Amr’s intention is to help us overcome this difficulty and implement an Agile adoption strategy to go much beyond.

For this, Amr’s gives me two keys. The first key is learning. Learning is the bottleneck in software development, the limiting factor in your effort to develop efficiently useful and dependable software. Learning might be about the functional domain, your user’s preferences, technologies, software development processes, whatever. Thus many of the Agile practices help people examine frequently what they have done and get an opportunity to learn and improve: short cycles, retrospectives, test-driven specifications, etc.

My “plateau” team is not today using some of the most important learning-oriented practises, such as refactoring and retrospective. The emphasis is more on velocity, not on learning. IMHO, this explains the plateau: once you have adopted some basic practices, you don’t improve anymore if you are not willing to experience frequently the slight unease of realizing you could have done better and turn it into the next incremental enhancement.

The second key is personal responsibility. The best Agile teams are self-directed, self-improving and responsible. Collective responsibility can only be based on the individual responsibiliy of team members. Many Agile practices help people in the team evolve towards more individual responsibility. Just as an individual cannot be ordered to be responsible, a team cannot be declared self-directed, but you can help it.

My “plateau” team is not today self-directed. It is composed of individuals moving in a hierarchical environment, which does not encourage personal responsibility. Agile adoption has not been positioned as a change in culture, only as “just another software development methodology”. I think we have not worked enough to empower the team, maybe because we did not fully appreciate the effects of the cultural gap.

The third chapter is about business values. What are your most important goals? What are your reasons for improving your software development process? Amr suggests some candidates, and invite to look for the right motivation for your team. If we know why, we have better chance to improve, and in the right place.

My best idea right now is to talk to the various members of the team and project sponsors, and try to understand what is the motive for getting the team Agile. Time to market? Yes, we would all like to get a release a few months sooner. Cost? Yes, of course, as everybody. But isn’t there any other reason, more specific to their situation? Then, I hope we will be able to get them motivated and empowered to overcome the plateau.

Posted in Agile, Books, IT, Methodologies | Tagged: , , , | 1 Comment »

Self-Service Oriented Architecture

Posted by Yannick Martel on September 3, 2008

How easy are they to use? Do you need any documentation?

How easy are they to use? Do you need any documentation?

For the benefit of those who have lived in a cave for the past four years, I can announce that Service Oriented Architecture, or SOA, has been a major trend lately. I won’t debate whether it is past history or not, whether it has failed or not – it is generally admitted that SOA is there, and not anymore at the bleeding edge. An old-new idea, SOA put a major emphasis on the availability of services. Now, services are made to be consumed, and frequently to be consumed many more times than produced.

Then let us take the global viewpoint, including consumers and producers. If services are made to be produced once, consumed many, then it sounds reasonable to strive for a low-effort consumption, even if it makes things a bit harder for the producer. The producer should position himself as a service shop, delivering services to client and willing to make their life happy and easy. It is the same as in business: if a transaction is pleasantly and effectively concluded, your client is more tempted to come back to you next time and to recommend you to his buddies.

The trouble is that it can be costly to deliver good service to your consumers, and to support them adequately, if you keep your services as they are. This is where I want to introduce the concept of Self-Service Oriented Architecture. This motto emerged from the session at the Université du SI of my coworker at OCTO Technology Ignacio Lizzaralde. Basically, as a producer, you should design your services and provide surrounding infrastructure to make your consumers as self-sufficient as desirable. This means for instance:
– providing simple and clear APIs and resources
– having your APIs and resources exposed on simple to use technologies
– having your services self-documented
– provide documentation with examples
– provide tests environments
– allow your consumers to download client libraries, mockups, help files
– provide a mailing list and a forum to listen to your consumers and have them interact and share experience

I hope you get the idea. This approach is valid whether you are providing services to outside of your company or they are for inside consumption. It is a powerful guideline for designing, implementing and for supporting services.

Generally, service providers are more inclined to deliver good services to the outside, where there is competition. But clearly there is also competition inside a company – competition between different sources for the same data and processes. By making your consumers more efficient at using your services, you are beating internal competition, promoting your efforts while making your company as a whole better. Thus Self-Service Oriented Architecture, or SSOA. Why a new acronym? I want to help fix the concept, as I hope to do with my clients. It can be debated whether SOA as a trend brings anything new to help IT to bring more value to the business. I am convinced that SSOA can.

Posted in Architecture Style, IT, SOA | Tagged: , , , , | Leave a Comment »