In 2001 Vladimir L Pavlov organized the following experiment:

A team of students was assigned a task of designing a software system within a single day with one very challenging restriction perimeter. UML was the only language allowed for communication while working on the project. Any verbal or written communication involving natural languages (English, French, etc.) was forbidden. The question was: would students be able to achieve their goal without using regular language, using only UML.

This constraint was intended to make the students go through a "condensed" version of communication problems typical for software development, gaining the experience of applying UML to successfully overcome these problems. For students the event was presented as an experiment, aimed at determining whether UML is a "real" language, sufficient for a full range of project communications.

The experiment was an astounding success. As an experiment, it demonstrated that students always developed clear and concise, high quality models, that were constructed without usage of any "regular" language, using only pantomime and UML for communication. As a training, it helped students recognize the real value of UML and gain deep experience in modeling. It was repeated dozens of times in both academic and industrial environments and always generated outstanding feedback.

Once during a design session there were accidentally two independent teams working on the same task. The communication means of the first team was restricted to UML as described above, while the other team was allowed to communicate verbally using a natural language. It turned out that the first, more restricted team, succeeded in performing the task with greater efficiency than the other team. The UML diagrams created by the first team were more sound, readable, elaborated, and elegant. It strongly suggested there was a lot more "uncharted territory" in applications for UML than it was previously assumed.

Subsequently, Vladimir L. Pavlov conducted a number of additional experiments intended to reveal whether the "silent" modeling sessions are more productive than the traditional ones. The participants of these experiments were experienced software architects and designers. In all these experiments, silent teams were at least as efficient as the others. However, in most cases the silent teams clearly outperformed the traditional ones. Our interpretation is the crucial reasons for such an increase in performance are the following:

	The restriction on using a natural language stimulates creativity of the designers as well as forces them to stay focused on their job;
	Work in speechless mode forces designers to explicitly uncover all underlying assumptions at the very early stages of the design process;
	UML is no longer considered as a superfluous burden irrelevant to real-life needs (as a "write-only" language) - instead, designers begin to demonstrate genuine concern about the quality and readability of their models.

The impressive successes of these experiments motivated many of the participants to return to their companies and begin implementation of Speechless Modeling into their engineering processes. Some of these companies made Speechless Modeling a regular part of their SDLCs, some others conduct Speechless sessions on an ad-hock basis. But all of them provide constantly positive feedback. You can find what they say about their experience at our Testimonials page.

Vladimir's article about speechless modeling has been included in the ACM's Top-10 list of the most popular articles on Computer Science.

Following the continued successes of these experiments, Vladimir conducted new experiments with the specific intention to compare UML to natural languages. The premise for these posed a reasonably simple, but intriguing engineering question: If a team of experienced translators takes a text in English and translates it into Russian, and then another team takes resulting Russian text and translates it back to English, the original and restored versions of English texts will be very close. Of course, the exact number of words and sentences in these two texts will differ, but semantically the texts will be almost equivalent. What will be the result, if we conduct the same experiment, but the first team will "translate" from English to UML, and the second will "translate" back from UML to English?

Such experiments were organized, and they confirmed again that for technical information UML has sufficient power of expression required to maintain the model's content. Texts obtained after the backward translation from UML were semantically equivalent to the original. Later the experiments evolved into new events, where the backward translations (from UML to English) were specifically compared to the original English documents to "test" the quality of the UML models, and then models were improved based on the results of this testing. The experiments suggested the entire software development cycle existed as a series of translations from more abstract languages to less abstract (i.g. from English to UML, from UML to C++, from C++ to executable, etc.)

Why not then extend the backward testing to the other translations created throughout the development cycle? In subsequent experiments this backward translation verification has been unquestionably demonstrated as a reliable method to help guarantee deliverables of each development step do not lose, or have misinterpreted, anything that was produced at the previous step. Architects and software developers who have participated in Vladimir's experiments started to practice the backward translation verification method in their companies providing fantastic feedback. You can see what they say about their experience at our Testimonials page.

Today many software companies claim that UML modeling is misused, and UML itself is treated as a "write-only" language that is perceived as a bureaucratic liability. For large projects this is an especially critical concern, because the most important decisions are made at the beginning of the project - when UML is used for analysis and design. The quality of the design is usually tested much later, so correction of modeling mistakes is expensive.

We eliminate these problems. Based on the results of Vladimir's experiments, INTSPEI has developed a unique framework that enables software engineers to significantly change their development processes and start using UML modeling with extreme efficiency and quality.

Engineers who use our framework (called INTSPEI P-Modeling Framework) turn UML analysis and design into a valuable and inspiring part of the development process. The formal paperwork, which slowed down your projects, evolves into creative process asset that increases the productivity and shortens the development cycle.

The INTSPEI P-Modeling Framework also helps you to dramatically reduce delays between bug insertions and bug fixes. It leads to decreasing of the total number of bugs since inserted bugs are less likely to produce new ones. That means a total reduction of costs for fixing all defects and the decreasing of bug propagation. The total project length is decreased up to 35%.

INTSPEI offers on-site trainings to teach software engineers to use INTSPEI P-Modeling Framework. Our SDLC Fine-Tuning service will help you identify bottlenecks in your process and adopt INTSPEI techniques to eliminate them. Finally, INTSPEI Train-The-Trainer events will enable key staff to deliver these services themselves.

All our services are offered based on a "Satisfaction Guarantee" money-back policy.

Click here to request a free quote or learn more about all INTSPEI Services