Nature vs. Nurture

14 Mar

It is not too far off if we run the analogy between a life of a human beings maturity process and that of software. Arguably, human lives start from their conceptions. A life goes through the pregnancy, the birth, the nursing of a baby, kindergarten, the twelve grades, college or technical schooling, the entry to the workforce, the prime of being an expert in whatever field, and the re-education naturally as desirable or as needed; each individual is scientifically developed and matured to reach our expected longevity while everyone of us being useful and enjoying our lives.

To a logic mind, it is remarkable how similar between a successful individual life and a successful software product. Let us continue this analogy to illuminate what software is and how to ensure software quality.

A.        The conception

How similar and interesting it is to see our broad range of reasoning used to conceive a life or an idea of creating software!  Without doubt, the forefront reason is the result of our passion and our love. It could also be an accidental or deliberated act strategically or tactically. One strategic software project that immediately jumped to my mind was the one D. L. Parnas wrote in his paper [1]. He voiced his concerns about the health of that project vociferously. Indeed, in the hindsight, one can see that the primary purpose of the project was strategically aligned with the national interests; it was ended with success because of the collapse of USSR. Meanwhile, there were plenty practical software products continued being useful with longevity. An immediate example would be the office automation products/suites. 

B.         The pregnancy

It is rather accurate to think of the software requirement development as the pregnancy stage of a human life. The process should be carried out by a responsible individual who is bringing such a life in the world. Although the stakeholders of a software system seemed much more and much diverse, the final decision for bringing about a particular software product ought to end with one who is responsible for it. Among evidences supporting such analysis can be found in the AIR JAM report [2]. Eventually, the requirement specification induced failure with  its skyrocketing cost as the symptom.

However, not all software projects can be associated with an individual’s responsibility. The requirements of those projects were part of the circumstances discussed by Neil Maiden in “Trust Me, I am an Analyst [3].” In his analysis, trust has been the highest importance. Although it makes some sense, arguably, the responsibility should be emphasized the most; specifically, what is desirable and what is feasible should be differentiated clearly in engineering sense under the responsibility of its software architect(s). 

Being a software development professional and specialized in software requirement engineering, one should not just be able to listen, but one should be able to participate, as those movie actors or investigating reporters, who actually are taking active roles in the subject they play or investigate, learning what are the needs by participating, such as a finical system running by bankers or an air traffic control system scheduling airplanes landing and taking off. Good actors can quickly make sense in the roles they play. Good software engineers can do the same as well.  It is for software engineers to do so because we understand the technologies used to create the software and we can bridge the gap between what are the desirable and what are the feasible.

 

C.         The education

As human beings, whether one is useful and influential or not, one is judged by their knowledge and their capability. Software product is the same in the ways it is built with efficient knowledge structures for problems they can address. The key to the efficient knowledge structures is the subject of studies in software architecture. A good software product with longevity must have excellent software architecture. Just as people in their work places, knowledgeable workers are resulted from their excellent educations, good software products come from good design and development. Architectural analysis is most important in software design. Good architecture is sustainable to software systems with continuously learning and continuously improving. 

D.        Entering workforce

If the commencement at the end of schooling is his entry into the workforce, the same is true for a software release to the real world. The software product then can be tested in the real world and used by its end users or placed on the market ready for use.  Arguably, the most important growth of a software product starts at this stage unlike the following descriptions of the software project management life cycle of the past:

We built what we were told to build, managing it the best we could; and after it was over, we breathed a sigh of relief (or despair) and moved on to the next project [4].

Here, Favaro’s word “over” is not the end of software life cycle management but the project delivery to the operational people and maintenance engineers. It signifies the ending of software development and the beginning of the software maintenance in the traditional software life cycle management sense. This might be applicable 30 years ago, but with modern software, the difference is that software matures through its use. The more its customers use it, the more feedback it can get for improvement. It is very important for college graduates to learn by doing in their work and to accumulate the real world knowledge during their working. The same is true whether a software product is popular or not at its entry point. We should judge how it grows and how its customers react to it. It is often the case that if its design is good it can grow better and serve better. 

Defects in software are inevitable just as the imperfection in teenagers; defects can be fixed while maturing within its life cycle. As a person learns and corrects their bad habits to become better fitting in the society; software defects may be fixed whatever and wherever surfaced while the software is being used.  This is all natural in the software maturing process.

Even though we don’t call a college graduate “version 2,” the graduate becomes a better “version” compared with the “version” at his high school commencement ceremony. He has learned more comprehensive knowledge as well as special knowledge in addition to his being trained for critical thinking through learning the knowledge at college. He is more capable of doing complex tasks and capable of serving the society better.

 Judging software is like judging people, we want to see how one is educated and capable.  In software, defects can be removed not only when it was found while being tested before entering the market, but also when it is found while being used. An HP study has shown that many defects of a software product may never have the chance to be exposed during its service. It depends on how its customers use of it [5]. Both code reviews and extra effort spent for defect removal advocated by experts of software development in the past [6] [7] may or may not be an efficient uses of developers time if the software is a commercial product or a freeware, which is typically developed in an Agile development environment, rather than those mission critical with potentially catastrophic effect [8] if anything goes wrong.

The author has proposed a model of software defects to address software product quality issues [9], which is also part of solutions under the software maturity modeling approach introduced here.

E.         Maturing with lifelong learning

At the prime of one’s professional career, this stage is most productive and motivational in one’s learning driven by unknowns provided that the more one learns, the more one may realize that what one did not know and wants to know.  The similar happens in software products. If a software product is useful, it promotes the needs to make the product even more useful. Improving a software product can be challenging but it is feasible. Demands for software changes can be given in two forms:

1.         A problem addressed by software may change when the environment that defines it has changed;

2.         The solution to the problem addressed by the software is improving.

To implement these changes, architectural changes may be necessary, and the cost of changes may be evaluated.

In describing software aging caused by those preventable changes, Parnas wrote:

Changes made by people who do not understand the original design concept almost always cause the structure of the program to degrade. Under those circumstances, changes will be inconsistent with the original concept; in fact, they will invalidate the original concept. Sometimes the damage is small, but often it is quite severe. After those changes, one must know both the original design rules and the newly introduced exceptions to the rules, to understand the product. After many such changes, the original designers no longer understand the product. Those who made the changes never did [10].

 This description is truly reflecting the reality in many legacy systems, but it does not have to be this way, if the responsibility of design is tied with individuals. A close analogy between software designers and architects of landmark buildings may be appropriate. Individual responsibility should be tied with the fame or the shame of the software systems, especially those important ones.   Many failures in Robert Charette’s survey article [2] can be avoid as the consequence of applying the software maturity model. In fact, tying the responsibility with the architects of the software system could be a two way street. It can be used as licensing approach for evaluating software architects if desirable, not for life but for a particular software system which is listened for the architect to build. This goes nicely with the suggestion made by Maiden saying that requirements analyst should show their previously successful work.

Another close analogy runs with how FAA issues licenses to pilots, where flying hours and the types of airplanes they operate are the primary indications of pilot’s skills. In fact, that is how pilots get rated. 

In her Quality Time column piece in IEEE Software, S.L. Pfleeger introduced Manny Lehman’s notion of programs (programs, Life Cycles and the Laws of Software Evolution, Proc. IEEE, IEEE, Piscataway, NJ Vol. 68, No. 9, Sept. 1980, pp1060-1076) to describe a system in terms of the way it relates to the environment in which it operates. She pointed out: “Unlike programs handled in the abstract, the real world contains uncertainties and concepts we do not understand completely.” In my analysis, the uncertainties are results of our not being able to test how our system is going to behave with certain input. The system behavior in response to untested situations may seem odd to users but it should not be seen as odd to developers when such is happening. She continued: “The more dependent a system is on the real world for its requirements, the more likely it is to change [11].” This is exactly the reason motivated me to write this blog, modeling software maturity as a life cycle management approach. In her article, Pfleeger summarized five laws of program evolution observed by Lehman: continuing change, increasing complexity, fundamental law of program evolution, and conservation of organizational stability (invariant work rate).  The first two of these five are what may be relevant now when we look at them twenty years later.  My detailed analysis to be written in another blog soon.

F.         Retiring

Similar to the story of Compact Disc, when the CDs came along, recording music on cassette was obviously inferior in terms of the sound quality, ease of retrieving, and  its storage capacity. Software products are retired due to its quality as well.  However, the differences between software and hardware change the dynamics in reality. The flexibility in software allows its quality to be improved infinitely, in theory. The same is true in software engineers, as long as one keeps learning. The fact that software engineers are good at learning is natural with being curious and wanting to learn. If computer hardware is to human bodies, then computer software is to human brains. Many religions honor human soul as eternal; it couldn’t be more appropriate analogy with computer software. While hardware is upgraded, the essential in software lives forever.  Arguably, one should never retire a high quality software product. The apparent high cost to “maintain” usually can be exchanged with technology transfers. 

 

[1]        D.L. Parnas. Software Aspects of Strategic Defense Systems, and SDI: A Violation of Professional Responsibility, In Chapters 26 and 27 of Software Fundamentals, Collected Papers by David L. Pamas, Edited by Hoffman and Weiss, Addison-Wesley, 2001 .

[2]        R.N. Charette,”Why software fails”, IEEE Spectrum,Vol.42 No.9, p42-49, Doi:10.1109/MSPEC.2005.1502528.

[3]        N. Maiden, “Trust Me, I’m an Analyst”, Software, IEEE, vol. 27, no. 3, June, 2010, p46-47, doi: 10.1109/MS.2010.22 .

[4]        J. Favaro, “Guest Editor’s Introduction: Renewing the Software Project Management Life Cycle”, Software, IEEE, vol. 27, no. 3, June, 2010, p17-19, doi:  10.1109/MS.2010.9.

[5]        A.P. Wood, “Software reliability from the customer view”, Computer, vol. 36, no. 8, Aug. 2003, p37-42, doi:10.1109/MC.2003.1220580.

[6]        R.L. Glass, Facts and Fallacies of Software Engineering, Addison-Wesley, c2003.

[7]        A.M. Davis, 201 Principles of Software Development, McGrow Hill, Inc, 1995.

[8]        G. Le Lann, “An analysis of the Ariane 5 flight 501 failure-a system engineering perspective”, in Proceedings., International Conference on Engineering of Computer-Based Systems, Mar 24-28, 1997, p339-346, doi: 10.1109/ECBS.1997.581900

[9]        B.H. Wu, “Modeling Defects in Software Systems”, IEEE International Conference on Granular Computing (GrC2011), Kaohsiung, Taiwan, November 8-10, 2011,  p739-744, doi: 10.1109/GRC.2011.6122690.

[10]      D.L. Parnas, Software Aging, In Chapter 29 of Software Fundamentals, Collected Papers by David L. Pamas, Edited by Hoffman and Weiss, Addison-Wesley, 2001.

[11]      S.L. Pfleeger, “The nature of system change”, Software, IEEE, vol. 15, No.3, 1998, p87-90, doi:10.1109/52.676964 .

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: