Software Design Principles

A concern (as in worry) is a basic driving factor to find a solution. Resourcefulness (budget, network etc.) plays a good role while selecting a solution as it involves decision making process of reusing or acquiring (skills, help) or buying (things, services). While the solution addresses the basic concern the resourcefulness may increase the solution’s applicability in resolving related concerns in a limited sense.

For example, while resolving a concern of local travel, solutions like using public transport, buying or sharing a vehicle may be considered. Based on the budget the solution may change the definition of “local transport” (extending the applicability to resolve other concerns like holiday travel) but certainly it will not become “real long distance travel” or “international travel” (limited expansion of applicability).

With this background, Reusing (translates into avoiding duplication), Separation of Concerns and Budgeting the solution (that translates into not to over design) become the basic software design principles.

The other factors like “Focused (Single) Responsibility”, “Interoperability” (so others using a solution have to know least about the internals) are attributes of a good design.

Developing and Writing Use Cases

What could be a better way to start “Developing and Writing Use Cases” training session than to identify the participants as “Actors” and asking them to set their “Objectives/Goals” from the training session! Prof. V. K. Garg must have walked this path so many times. It was an excellent way to emphasize the fact how the IT consulting should be “User” centric than “System” centric. He established the context through the set of objectives/goals defined by the actors. Examples of how only 10% of the functionality provided by American cars was used 90% of the time and how this analysis helped Japanese car builders to reduce the cost and still satisfy the users was very helpful to highlight the user centricity. The same is true with the most widely used word processing software!

Most of the times, IT people “gather” requirements and build solutions. Generally such a development happens around system/technology centric which can be termed as inside out architecture/design. The user centric system development shall be a value proposition which is termed as outside-in architecture/design. It is very important to identify the end user of the system. A system built considering the viewpoint of the wrong end user focus shall be of no use.

Prof. Garg’s case study of a pharmaceutical company was very adequate to explain the point. After going through the historical data, a pharmaceutical company discovered that accounts department was not able to produce travel related expenses of the medical representatives (MR). After series of interviews with accounts department, the company arrived at the conclusion about lack of data related to their medical representative’s (MR) visits. The authenticity of the data was also in question. It was then discovered that in most cases MRs fill logs at the month end to somehow meet the requirements. Series of interviews with MRs highlighted the nature of the field job, more time spent on the field than the office and lack of connectivity on the field. After lot of analysis it was decided to have a connected system to capture the MR logs. These logs would contain date, time, location, doctor’s name, travel expenses etc. To avoid the delay in recording the data, it was also decided to give hand held devices to the MRs. It took some time for the company to implement the system. Out of curiosity and some force, MRs got hooked to the system. They could show off their hand held devices to the doctors and others. (One of the hidden agenda of the company to advertise their tech-savyness got satisfied!). Soon this system was seen as a burden by MRs and the response started fading. It almost went back to the original problem when the company decided to reinvestigate. This time they interviewed MRs and discovered that there is no sense of “ownership” or “belonging” amongst MRs towards this system. This system was seen as “spy” on MR. Further investigation revealed that it does not provide any helpful information to the MR. Few MRs reported that along with the logging the system should have details about a new products. Based on the notes of the last visit to a doctor, the system could prompt about relevant product information. There could be added flavors as doctor’s date of birth. After implementing the relevant requests, MR started using the system effectively which satisfied them as well as accounts people.

The story shows that incorrect objective taking a prime importance severs no purpose. It highlights the fact that main goals should be separated from the sub goals. In the above scenario the main goal should have been to empower the MRs, instead the initial implementation had system centric goal of capture the logs.

Prf. Garg then walked us through the intricacies of use case development starting with glossary, steps to build scenarios till the documentation. The actual case study carried out in the second half and the preparation of the documentation for the same was very helpful.

Towards the end of the training Prof. Garg touched very sensitive topic about estimation. He cleared the myth around using UCP, FP and other techniques by highlighting the fact that all these techniques give only the size of the project and not the time estimation. Every company should derive their Project Development Rate (PDR) for various technologies based on the historical data of the actual project execution time. Many companies’ CMM level 5 status was revoked because they had not derived PDR. He highlighted that almost 95% of the companies are using FP because of the availability of ISBSG data. It should be noted that many end users have started to size their projects on their own (like the tenders in the engineering world) which forces the bidders to sharpen their PDR to win the case.

Do I care about GoF Design Patterns?

The fact that event driven system is getting used without much understanding about the message loop, shows the maturity of Chain of Responsibility.

The UI has matured so much that the widgets/controls are getting used with effective event handlers without the knowledge of Command pattern.

The dream of creating our own language, diving into ‘systems programming’ was buried down under the sea of easy opportunities in the application programming. The situation has moved us far away from thinking about the how a statement (line of code) gets evaluated forcing us not to think about the Interpreter pattern.

Some of us may recollect the struggle of creating a generalized class to read objects from a linked list when there were no ready to use classes. Now, [IEnumerable] has matured so much that the Iterator pattern has been taken for granted.

The containers such as Main Window, Panels, Group Boxes etc. are vital parts of the UI design but the application designer may not be aware that these controls are nothing but the Mediators.

In early days of Windows programming serializing an object a big task. MFC made it slightly easier but still it was 10 lines of code. 10 lines of code! Now that may sound too much, with .NET type of frameworks providing [Serialiazable] attribute. The implementers may not be aware that they are implementing Memento.

Struts, Swing, ASP.NET, WPF is widely used with the full knowledge of MVC/MVP/MVVM but not necessarily aware about the Observer pattern.

Most of the grids provide sorting facility independent of the data type shielding the fact that somewhere inside it is the Strategy pattern.

Privilege of writing our own State (pattern) machine has also been taken away by ready to use Workflow Engines such as Workflow Foundation, Enhydra Shark.

With the fact that Silverlight 3.0 Start up kit preview 2 provides RESTful Singleton Service project template, are these the last few days of having our own Singleton class?

DataGrid allows creation of template columns where different controls can be placed. The creation of column depends on kind of controls that have been placed at the design time. Is it using something like Builder pattern? But what was the last situation where we had to create a really complex object by hiding the creation process?

Many applications provide functionality of creating a document from another base document. We can implement such functionality at the database level or using MemberwiseClone of C# or Cloneable of Java. Is it not Prototype pattern?

Extract only that portion of the data from the database which is required for processing and for the user display i.e. don’t use Select *. This principle sounds like Flyweight pattern.

The XML navigation, DOM navigation, Tree navigation is very popular and may be a creation of Composite Pattern.

Do we prefer sub-classing over the Decorator pattern?

Silverlight 2.0 provided moderately better way of integrating a web service and generating proxy classes. But with Silverlight 3.0 RIA services style of programming, will the next generation programmer know about Proxy pattern?

In case of porting project with reusability in mind we will require Adapter. Façade is also getting used .

So what are we left with? May be couple of Creational and Structural patterns?