Traditional Design Patterns

Q1: Would you think the existing and traditional design patterns are a magical wand?

Q2: Would you think the Skill and Experience generate the magic wands?

[1] Skill and Experience: The Magical Wands! [1, 2]

[1] Skill and Experience: The Magical Wands!

Professor Dr. M.E. Fayad, SJSU, AITG, AEEH PRESS, i-SOLE, INCs

Skill is the unified force of experience, intellect and passion in their operation.

John Ruskin [3]

Traditional Software Patterns include all the existing patterns, like the gang of four [4], Siemens Group [5], and the others [6, 7]. Experience is more of a subjective topic, rather than an objective property. As of now, there are neither well defined metrics, by which experience can be quantitatively measured, nor does it always make sense to define specific metrics. However, when this experience plays a crucial role within a specific domain, it becomes necessary to identify a set of standard qualifications that govern this experience. For example, in medicine, surgeons are selected for a particular surgical procedure, based on their past surgical record. A pilot experience can also be quantified as being issued a license, based on the total number of hours previously flown.

In the patterns community, experience is highly critical, and all the more so for writing patterns, since it relates itself directly to the important task of documenting the developer past experience. But it is very hard to quantify experience with clear and well-set metrics, because software development experience involves more than just simply measuring the number of the projects previously developed. Developers can produce workable software systems, without necessarily employing the best of practices.

The inaccurate use of the word experience can result in many potential and unforeseen problems that would seriously undermine the benefits of reusing patterns in software development.

Some of these major problems are:

It Hinders Pattern Improvement: The word experience tends to make pattern writers immune from undue criticism. When challenged on the validity and veracity of the pattern, the writer can claim that he/she has successfully used the pattern on developing many projects. However, simply using a pattern may not ensure that the project was correctly designed and developed. More often, developers tend to overestimate their own abilities, while designing and crating a pattern, which ultimately leads to inferior pattern structures. Meaningful pattern improvement is possible, only when the pattern writer accepts the undeniable fact of need for gaining years of experience of understanding the advanced concepts of patterns and their usage, in developing reusable, stable and authentic patterns.

It Produces Low Quality Patterns: Without a clear definition of experience, it is not uncommon to read patterns from novice and inexperienced developers, who lack the required knowledge and skill to develop high quality solutions. Even though various patterns are readily available, it is still the sole responsibility of the developer to choose the right pattern for the new system. Usage of low-quality patterns will only further complicate the choice of the right pattern.

It Discourages Validation and Verification Techniques: A pattern that has been used in creating successful projects is not necessarily a good pattern. On the flipside, a pattern that has been used in failed projects is not necessary a bad pattern. Clearly, a pattern’s limited usage is an inaccurate measure for validation or certification. The only way to claim that a pattern is working properly and correctly, is by multiple experiences gained by using the pattern. To date, no serious attempts have been made to develop a theoretical foundation for validating and verifying software patterns. This is probably due to.

It is not obvious how to measure software development experience appropriately: Note that physicians must successfully complete undergraduate school, medical school, internship, residency, and specialist training, all of which are supervised by more experienced physicians that are working under extensive sets of operating protocols, in order to begin to operate independently on their own. Pilots must have logged in a certain number of hours in flying their aircraft and must have multiple levels of training to operate different types of commercial or military aircraft. They must also operate under explicit governmental and organizational rules and regulations. Both pilots and doctors must continue to upgrade their training and experience, to keep and retain their licenses. So, while there is no objective method to assess the quality of their experience, there is some definite assurance that they have met generally agreed upon minimum standards.

Nothing similar exists for software developers: There are no minimum standards of experience or skill that are generally accepted. The SEI PSP, TSP, etc., and the IEEE Computer Society’s certification do not strike me as being adequate or skilled. Most university programs never require supervised and administered training (and I don’t think Senior Project classes count.) As far as I know, patterns do not automatically undergo any sort of peer review, by people who are acknowledged to have enough experience to judge the quality of patterns and their relevance. Conversely, it can also be safely assumed that there is a dearth of high quality, seasoned and experienced peer reviewers, who can objectively analyze patterns that are presented for criticism and opinions.

If you want to specify a minimum standard for pattern writers, how about the following points:

  • Formal and established training in software system development (BSCS, certificate programs, or similar)

  • At least a minimum software development experience of seven years including knowing how to model and architect in multiple real-time projects.

  • At least two years of using patterns in real-time projects.

  • Peer review of previously published patterns.

Discipline-specific patterns will require more verified and mature experience in the discipline.
Note that experience with failed software projects could be as valuable (if not more) than those experiences with successful projects if the failure experience is critically analyzed.

References

[1] M.E. Fayad. Stable Design Patterns (SDPs) (BASE)” Aeeh Press, Inc, San Jose, CA. December 2024

[2] M. E. Fayad. “Stable Design Patterns for Software and Systems” Boca Raton, FL: Auerbach Publications, Taylor & Francis Catalog #: K24656, September 2017. ISBN-13: 978-1-4987-0330-7

[3] John Ruskin (8 February 1819 – 20 January 1900) was an English writer, philosopher, art historian, art critic and polymath of the Victorian era. http://izquotes.com/quote/160272

[4] E. Gamma et al. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-

Wesley Professional Computing Series, Addison-Wesley, New York, 1995.

[5] F. Buschmann et al. Pattern-Oriented Software Architecture, A System of Patterns, John Wiley &

Sons Ltd, Chichester, 1996.

[6] M. Fowler. Analysis Patterns: Reusable Object Models, Addison-Wesley, 1997.

[7] E. Freeman, B. Bates, and S. Kathy. Headfirst Design Patterns: A Brain-Friendly Guide, O’Reilly Media, p. 694, Final Release Date: October 200.