Planet SCM

In the article Writing a book is like developing software, Roy Osherove compares writing a book with writing software. Now let's assume that we would write books like we develop software.

Most books are written by a single author. Take for instance The Lord of the Rings by J.R.R. Tolkien. Suppose we would take up the assignment to write a sequel of this bestseller, but develop it like a software product. Suppose some of the requirements are

• It must appear on the market in English, Spanish and Russian simultaneously
• It must appear before Christmas 2007
• It must equal or exceed the success of the current books

Given the short timeframe and the limited available of talented and experienced writers (scarce resources), we decide to write the book in as multisite project. We set up and English team in the America, a Spanish team in Europe and a Russian team in Asia. Given the global distribution, we can work round the clock.
To reduce intercontinental communication across timezones, we will assign different parts of the book to each team. Each team will write in its native language to assure the highest quality of writing. When one team finishes a part (or a preliminary version of it), it will be sent to the other teams for verification and translation.

The verification process will compare the story with the requirements. Which requirements? How do you make "exceed a previous success" SMART, if you cannot sell the book before finishing it? This is a job for marketing. They have to verify if the book will sell good enough.

We were talking about assigning parts to different teams. Which parts? If we divide the book into chapters, we can assign a chapter to a team. Which chapters will we have if we don't have the story yet? But the story is to-be-developed by the team. To divide into chapters we need the overall plot, in abstract form. But, who is responsible for the overall plot?

Okay, division into chapters seems to be a bad idea. Let's divide into characters (persons in the story), and assign different characters to each team. May be the cultural background of each team may even be an advantage for writing and for the overall result. But how can you write a story of characters in separate teams, if there is not plot that connects those characters? Characters need to interact in the story. Furthermore, different teams will be writing simultaneously on the same part of the story. So we need to integrate parallel updates, and we need to review the different story elements before integrating them.

Another issue is that during the story, we build up a history. If for example two characters meet in the beginning of the book and become friends, they cannot be complete strangers and enemies lateron.

Sigh! We need a story architecture that defines the development of characters and the development of time (history) across the whole book. It also defines the characteristics of the characters, the landscapes they visit, timing constraints (e.g. you cannot be at two different places in the same timeframe).

And we need configuration management to assure that the correct versions are reviewed, verified and translated. Especially translation is a dangerous one: if you translate an old Spanish section to Russian, the English and Spanish teams will not discover it because they cannot read Russian, except the people who translate from Russian. But why would a Spanish translator be bothered with reading a section that was originally in Spanish? So, CM must assure correct version and status handling.

I can go on and on, but probably you have lost faith that a book written this way will (1) be ready before Christmas 2007 and (2) exceed the success of The Lord of Rings. Yet, many companies develop their (software) products in multisite projects, with teams in America (US, Canada), Europe (UK, France, Germany, the Netherlands), Asia (India, China, Singapore), and without proper configuration management - except branched version storage and multisite replication.

Is multisite book-writing a good idea? And multisite software development?

In the August edition of the Rational Edge, Laurance Balmelli gives an introduction to the basic purpose and value of Systems Modeling Language (SysML), a proposed extention to the Unified Model Language (UML). An interesting article where he uses a simple system (Rain Sensing Wiper in a car) to explain some basic concepts about requirements modeling with SysML.

Reading through it I noticed that although it is a simple system to regard, it still requires a decent model to describe it. I was wondering how this would be for complex, real-time systems like cars, airplanes, shpace shuttles or medical imaging equipment. Those systems are so extensive and so complicated, that the requirements model will probably at least as difficult to comprehend as the system that is being modeled. But the purpose of the model is to make the system's functionality (and non-functional aspects) easier to understand that just using your (expert) vision based on years of experience with developing those kind of things.

If modeling the monster is about as difficult as comprehending the system without the model, then why bother? In practice, you do often see that modelling is only used to get an initial vision of functionality and architecture because no one has enough experience to build an intuition. But after several years of developing release after release, the models start to get out-of-sync with the implementation and the documentation. I see it all the time that first models are neglected and the modelling tools are degraded to drawing tools.

Does this means that the modeling languages (like SysML) serve no purpose for those large and complex systems? I think they do partially. As long as these modeling languages (even when they are visual languages) are general and very abstract, engineers with a lot of experience and with a specific and concrete mental picture of the system will probably outperform the modeling language. But once those modeling language are more dedicated to the application area, either by design or by heuristics that allow the language to adapt to the application area, I think those languages may become a more practical tool for extreme complex systems. It's a matter of being able to trust the models to be more reliable than the mental pictures of the engineers.

Update 14/4/2007:
Added labels.