Architecture - an art / some tips. Review on Tips on Programming

Introduction:

Architecting is an art. When I started off my IT / software career at Siemens(a project at SAIL / Bhilai), in the late 90's, I used to work on robust industrial grade systems, meant to work 24X7, at steel mills. There was enormous pressure to build a quality software, with reliability and performance as the mantras. These requirements make the foundations for a sound software system, which the end user can put to good use.

*On C:

*While developing programs in C, I could notice the evolution of a natural call graph based on specific functionalities, that would evolve as a result of splitting calls to smaller functions. Sometime, I would discover that to resolve a recurring programming problem, there was a specific solution pattern. All of them were undocumented resources, which I was using on a near daily basis.

Developing an efficient software system on C is a tough one. The big challenge to me seems to be the efficiency of algorithms, and datastructures. But opportunities of doing a good job, executing a well thought out architecture, are enormous, here.

*On CPP:

*However, when I took to object oriented programming, I discovered a plethora of great existing artifacts that provided documented solutions to recurring problem domains. I could think of numerous ways of solving problems, evolving my own idioms(honestly, I am still a learner, like many others), like shunning excessive usage of STL, in view of performance. GRASP(General Responsibility Assignment Software Patterns) is another area which I focus on while keeping my designs simple, yet effective.

Thanks to Mr. Craig Larmann for the super book on UML application. GRASP is an excellent example of how we may have attempted to improve our designs in the past, without having a documented solution in place. Such work by these great men simply make our lives simple. But the initial thought must come from within us. It is an art form that must be nurtured, practised and allowed to grow.

Resources:

To use a pattern, Catalogues must be surfed to see if solutions to the problem are documented, already. Else, catalog your own patterns, and publish them on sites like the code project, with simple prototypes, to be able to invite criticism.

Some of the well known texts to help you build on your interests, other than Craig Larmann's, are POSA by Buschmann, et.al., Software Architectures in practise by Len Bass, et.al., C+ NP V1, 2 by Douglas Schmidt(excellent treatment of some of the realtime network problems - usage of reactor / proactor / ACE). I really like Larmann and Schmidt's work, for the rich set of information provided. I have also found the book on Program Design in C by Tondo et.al., to be an excellent guide.

Conclusion:

In both the above topics, a designer cannot forget the responsibilities he / she has towards an invisible stakeholder, the operating system. A poorly designed system can make the OS react sharply. There are no margins for errors.

Architecting has many similarities with the real world. We have to dream more, think futuristic, and evaluate the work of great men like Larman and Lakos, yet bear in mind the smaller facts of a more practical world, that use wheels where you cannot do without them. If you try to put a rocket engine in lieu of wheels, the system may not work.

A simple idiom: make your work clear and in bold - ADD COMMENTS

//// my style of placing comments on c+ codes(you may use 3 or 5 /)