::Draft::
In this post, I am changing the names of people, the project and companies to keep them anonymous.

This story goes back to the period of 1997 — 1999.

BestReview was a web based application to collaboratively review documents. The project started with about 3 people in March/April, 1997. I joined it as project manager in later 1998, when its team size was about 10 people. By then it had already a code base of 60K lines of Java code.

It was a typical case of totally fresh and immature engineers handling the application design. Its earlier tech-lead had no idea of how to keep database design independent from GUI screens.

By early 1999, we still had a very unstable system. On the top of that, I had frequently the requests from the marketing guy to change GUI. He used to ask for cost estimates to get the new screens.

Being new to the system, I thought it was really big as the code base was about 60k lines of code. Finally I decided to feel for the project’s complexity by freshly re-engineering its design. In about 3 hours, I got my first cut design. Then from the initial cut, I could estimate that the complete design could be 3 weeks of effort for 3 people using FOD. In fact, there was no prior experience using FOD, except for its conception in the period of August to November, 1998.

I approached my senior manager and expressed that there had been some wierd things going on BestReview system. Actually the project should not go that long. Also I mentioned to him that I could demonstrate redoing the same in 6 six weeks if he gives me three engineers. But he replied that he did not have (human) resources for experimentations. It was around April/May, 1999.

By August, 1999, we had the fresh blood, the new graduate engineers who joined the company. These engineers needed to be given a 6 week long mock project before they were to be inducted into the software development projects.

These engineers as resources were unaccountable and you could do anything with them. So I picked 6 of them. In three weeks, I got a thorough re-design of BestReview based on FOD. In another 3 weeks, I had three of them completing the server side code. And the remaining 3 integrating the existing GUI of BestReview with the new server code.

By the end of 6 weeks, we had a running application. Well this needed some more testing as the team was short of time.

In retrospect, I thought, if I assume there were only 6 engineers for about one year who worked on BestReview. Then its about 72 man months effort. That server side code that we freshly developed was 6 man-weeks effort, i.e 1.5 man months effort. You can grossly approximate the effort to be 10 man months effort after rounding it to 2 man months effort, multiplied by 5 times. So if the original effort of BestReview’s server side is estimated to be 30 man months effort, I still have three times productivity.

It will be interesting to know, what was actually causing such productivity gains. Was it due to Good engineers, good practices like FOD, or both together in the new team that I created? Or was it due to a bad job done by earlier engineers? How much is to do with the agile nature of FOD to carry forward the human thinking in natural language swiftly into design?

Ever since that first experience with FOD in 1999, I never required to dabble with sequence diagrams though I have been using Java for enterprise applications. I am not so much particular about the philosohy of OO thinking around objects with behaviors, or objects with encapsulation, polymorphism, dynamic binding, blah, blah. The issue is not about my adherence to a philosophy or religion. Its about making our lives simpler, and easier. From that perspective, I would like to adjust or reposition FOD or FOA in the context of OOP (object oriented programming).

:: Draft ::
In this post, I am deliberately renaming the names of some companies to avoid possible conflicts or litigation.

The story goes back to circa 1999, when True Sense systems, CA, USA wanted to reengineer their remote class room product based on vintage VSAT communications technology. The intent of reengineering was to migrate the product to internet technologies.

So the initial work began with two people, one software architect and a senior engineer in September, 1999. They were in San Jose specifically for this work. They sold a high level solution to True Sense Systems by December, 1999, just before X-mas holidays were to start.

After the return of our two engineers to Bangalore, in January, 2000 we had 12 — 14 engineers doing lower level design, mainly sequence diagrams for several components identified in the solution. That exercise was happily going on till the end of March, 2000.

Then True Sense Systems realized that we wont be able to deliver as per the schedule. So they decided to bring in a third party middleware from MetaCon, in London, UK. That decision we came to know in April, 2000. By the end of April, it was clear to the team that, their technical solution was to change.

The project manager and the software architect went to London in May to evaluate the third party middleware. By the middle of May, after their return, our three smart engineers from the team started working on how the existing solution can be adopted based on the new middleware. They took a month to figure out that they dont have a solution due to a lack of the details in Metacon’s design documents for their component.

It was already the middle of June, for MetaCon’s cusomized middleware to reach us. But they were taking more time. So to engage the team, I started redoing the entire design using FOD. I knew the whole exercise could be not more than a week’s effort if I use FOD. I felt the need to redo it for two main reasons: 1. you just dont know what is happening in those sequence diagrams. 2. the design was spaghetti one.

The smart engineers in the team were weary about my adventure. Certainly the idea of redoing the design was a crazy idea after having spent many many billable hours. Some of them went around expressing their concerns. But there was nothing hampering a project delivery. So nobody could obstruct my plan to redo the design because I was its project manager.

So we started on a Monday, the job of redoing the design. By Friday evening, ie within 5 working days, I had the first cut ready with more than 95% completion. That included the effort of training or mentoring the folks in FOD, and then making them to do the job.

FOD is a purely text based design specification approach without needing to dabble with sequence diagrams. So you are very agile to review and edit the text.

We returned on Monday, the sixth working day, to resume the work. So told the team to think about any kind of wild cases as examples to find faults in the new design. We decided that there would be no more discussions on the design on that day. I told the team that they could go home to relax and then to think about the problems in the design, and come back next day to report them.

After smart thinking for almost two days, the team assembled on the next day, Tuesday evening. Only one guy pointed to some strange requirement which went outside the scope of the requirements. Otherwise, what we closed on Friday evening remained in tact without any changes.

So we got the new design in 7 working days. Soon after a few days, two of those weary-smart engineers turned up at my office and said that they thought working on a big project was all about doing a design for a few months. But never could imagine that they could finish a job in a week with such precision that FOD offers.

They were happy. That was it.

Next, selling this new solution to the customer was another interesting story. But it was not difficult. I showed the problem that the old design had. And then showed the remedy. By the time he understood the remedy, the customer was excited, and said, the solution was radical /revolutonary. Also he got one of his engineers immediately flown to Bangalore from San Jose to verify the new design.

I can say that, I had the advantage of closed requirements to finish the job so quickly. Right. But FOD’s main virtue is in retaining the logical thinking that we can articualte in NL, even in the design. That is the explanation for its success.

:: Draft ::
Yes. EnglishToUML has a feature to generate FOD code. But I have not made it to the public. If people are enjoyinh FOA, I will be happy to share FOD along with EnglishToUML.

Later we can provide FOD for j2ee, hibernate, ruby on rails, or whatever.

I love to release it to teachers who want to explore teaching it to their students.

The best case in your hand is EnglishToUML. Its data related code is based on FOAD. Its about 3500 lines of pure and core Java code. Three of us developed it in 4 months. After that I never touched that part for almost two years.

I have really an intersting experience to share about FOD when I was working for a customer. Also another when I was reengineering a product. Look for other posts:

• True Sense Systems experience with FOD
• BestLook experience with FOD

My gut feeling is you can be 2 to 3 times more effective than those who dabble with sequence diagrams when it comes to design.

:: Draft ::

If you are able to specify a business logic or procedure in plain English, you can easily push it into imperative programs without a need to sequence diagrams.

IN fact, my successes with FOD over the last 8 to 9 years, always leave me a question: why the hell the sequence diagrams are blindly forced onto the world for understanding a computation process.

In other words, you want to have a very agile way by which your natural language oriented thinking, and also your logical thinking pushed into imperative programming, FOD is the best choice.

:: Draft ::
A word about imperative programming. This is all about using conventional programming languages like C, C++, Java, C#, etc. Essentially you have for, and while instructions helpiing you to crunch or munch your data.

Through personal discussions, I had learnt that the first attempts to bring FOD into imperative programming were due to Dr. Jiri Soukup of Codefarms. I am not any well informed scholar, but did spend my money buying those 30 or more books related to software design.

Dr. Soukup’s story goes back to circa 1981 in his days at Bell labs. He had problems with spaghetti C programs, with pointers going in cycles of whirl-winds possibly. It was then, he did concieve explicit data structures for relations. In other words, he invented libraries for relation objects. That is all about the crux of his Data Object Library, in its C++ reincarnation.

Later I joined the party in 1997, with a background of a hierarchical approach to software design, based on a formal method, called RAISE (rigoros approach to software engineerng), but not so much known in comparison to its sisters or brothers such as Z, VDM, larch, etc.

I packaged Jiri’s relation objects into RAISE as rigorous specifications. Finally that looked like fact oriented design by contracts. But that has been my new lingo ever since I discovered simplified fact oriented analysis in June, 2003. But before that my lingo is Relation driven design. Roughly at that time, I did publish a paper on Relation Driven Design in Journal of Object Technology.

:: Draft ::
SQL is a declarative language. Its queries are all about processing facts only. So the underneath design philosophy is of FOD.

The good thing about understanding logical atomism is we can get disciplined or trained to recognize elementary facts of a problem domain. This is a way to improve comprehension of the topic. Also a way to to bring focus to study of a problem domain.

When I learnt logical atomism from Wittgenstein’s Tractatus logico philosophicus, I became aware of the relations between natural language, thought, and their relation to reality. Also the role of logic as a part of natural language. As a result, I have a better understanding of what it means to develop information systems

:: Draft ::
Very few software engineers know about it since very few software engineering books discuss about it. I only found some mentioning of it in Dr. Terry Halpin’s book on Information modeling. Otherwise, to the best of my ignorance, no other authors exist, except two other authors. I will come to them later.

Dr. Halpin mentioned that a computation can be seen as manipulating atomic facts. That was in the context of a data model representing concrete atomic facts. So a query, a process or a method is all about changing the concrete atomic facts.

RDBMS thrives because of its underneath loyalty and respect for relations. These relations are abstractions of elementary facts, which are at the root of all our meaningful thoughts that can be expressed and communicated in natural language.

This is one thing that I like the most and am happy about.

RDBMS and its SQL is all about manipulating, and querying facts.