Software Evolution: Striving for a Better Being

Introduction

What exactly is evolution and how do we address it in the context of software? In the dynamic world we live in evolution is needed in order to survive. It is a part of the natural selection where the strongest most adaptable organisms survive the ever-changing environments. So the process of evolution is simply a changing towards the conditions that surround you in the long term.  So how do we address it in terms of software? Well if you think about it software is not that different than the real world since humans have made it in a way mimicking real world examples. Such examples are general architectural patterns, abstract classes based on real world etc.

The difference between software and real-world is that software in the past decade has evolved at a tremendous speed. Compared to the non-virtual world where change and evolution happens in terms of thousands of years and adaptation happens at a much slower rate in software we are the ones that determine the growth and evolution of the software. Since the virtual environments change fast software needs to evolve and be made in an adaptable manner otherwise it would not survive the changes. This article discusses software evolution, maintenance explains some rules and models and challenges in the context of its survival in this computer age.

What is Software Evolution?

Software Evolution is a discipline in software engineering that is based on the facts that change is inevitable and software needs to evolve continuously in order to “survive” and to remain functional. It is basically an innovative process of developing and improving the software in accordance to the standards “now”. Since the “now” is always changing the idea is that the software needs to change with the “now” thus resulting in an evolutionary manner of software development.

Software evolution’s main idea therefore to keep the software up-to-date and avoid software ageing, code decay and other unwanted problems that come with software. It may involve re-development from scratch and migrating or adapting software, whereas software maintenance addresses smaller issues such as bug fixes, minor enhancements. Software maintenance is the process of preserving and improving an existing system without making big changes to it and Software Evolution is the process of making big changes to the system’s central design in order to make it work in the new conditions that have come to be within the environment.

The Eight Rules of Software Evolution:

 

Manny Lehman, the “Father of Software Evolution”, identified eight rules about software’s evolution and describes things that either slow down or makes change within software faster.

The first rule: “Continuous change”. System must be continuously adapted else it becomes progressively less satisfactory in use. Can be easily understood since we know that the software environments are changing constantly and if the system does not adapt towards changes it becomes less and less functional in such environments (eventually becoming a Legacy system).

The second rule: “Increasing Complexity”. Because the system has evolved its complexity has increased and unless additional work is done to reduce this complexity eventually it will become a highly complex system which would become hard to maintain and adapt.

The third rule “Self-regulation”: Since the system is constantly evolving then this evolution can provide a self-regulating system.

The fourth rule “Conservation of Organizational stability”: The work rate of an evolving system tends to be constant over its operational lifetime or phases of its life-time.

The fifth rule “Conservation and familiarity”: That means that in such evolving and growing systems familiarity of the system needs to be maintained. In general the bigger the system the less people understand about its inner workings. So the developers and even the customers need to keep that in mind for such systems.

The sixth rule “Continuous growth”: That means that more functionality needs to be implemented within such systems in order to keep the customer satisfied. That in itself provides an overhead since the more functionality is implemented the more resources would be needed to maintain this. But nevertheless in order for a system to be evolving it needs to add functionality or change its previous towards new conditions.

The seventh rule “Declining quality”: The quality of software is degrading with time if not changed. In itself this software may be the same but the environments, hardware and so many things are constantly changing so previously working software may not work in the new conditions. Therefore its quality may be said to be declining with time.

The eight rule “Feedback system”: Evolution type systems are multi-level, multi-loop, multi-agent feedback systems. So in order to achieve a significant improvement they need to be treated as such.

Challenge Accepted?

Since Software Evolution has many factors to be considered when implementing it then it is logical that many challenges would arise. The most common ones are preserving and improving software quality, management issues, little theoretical background, lack of evolution tools, study experience of software developers and other external factors.

Improving and preserving software’s quality when upgrading it is one of the most common issues that arise in Software Evolution. In order to maintain its quality then its functionality needs to either improve or remain similar. This is hard to do when changing the system. One solution to dealing with such problems is testing before and after the changes and comparing the functionality of the two. But in such case the issue of whether the tests were correct arises.

Management issues that might arise when evolving a system involve allocating proper resources to a task that is hard to evaluate. Determining the need of such a system and explaining it to the upper management. Another issue is whether to evolve a legacy system or develop similar system from scratch etc.

The other challenge is that in school or university when we are given different assignments they are mainly single release and hence most of software developers don’t have experience in maintaining code or implementing an Evolution type system. Whereas in our careers we would mainly be working multi-release software and systems that are much more software evolution oriented than in our assignments and practical.

Software Evolution Models

Some examples of SE models would be the waterfall model that is a 5 step model that has maintenance in the fifth step. The spiral model, that consists of small prototype releases and a linear model of software evolution. It is based on communication with the customers thus achieving the satisfaction of the customer; risk analysis; and customer evaluation of releases. Its biggest advantage is that this model is very applicable in real-world scenarios.

Another method is the staged method is a descriptive method that involves implementing software evolution in the long run. It consists of four stages. First is the initial development where the first version of the system is produced. Second is the active evolution step and this is the step where the system is still in the early stage of development so small and simple changes can be easily implemented and also major re-engineering of the system would not provide such an overhead. Third is the servicing stage, which consists mainly of maintaining an already operational system and this is where knowledge of inner workings of the system may deteriorate. Fourth is the Phase out step which is when the system is no longer operation in the current environmental conditions and is to be replaced by new solutions and making small changes would be too costly to implement.  

Conclusion

Software is one of humanity’s most complex inventions and because of this many issues in maintaining and improving software arise. The need for improvement is obvious though. We as humans always strive for comfort and innovations. We are curious by nature, we strive for improvement and in the long run have always tried to invent things that would make our everyday life easier. It is the same with software evolution. It is the discipline of improving and redesigning in order to achieve better results or similar results but in the current situation.

 

REFERENCES:

[1] Refactoring: Improving the Design of Existing Code , Fowler 1999, ISBN 020148567X, Chapter 2 plus list of soundbites, p. 417.

[2] Software’s Future: Managing Evolution. M. M. Lehman. IEEE Software 15(1):40-44, 1998.

[3] Manifesto for Agile Software Development. Various authors, IEEE Software, November/December 2001.

[4] www.refactoring.com.

[5] Demeyer et al. 2003, preface and Chapter 1.

 

Response Article: Agile Software Development in China

This is a response article to “Agile Software Development in China” [1] by s1314857.

Introduction:

In the original article the author talks about the benefits of using agile software development (ASD) in China. The article is divided into three main parts. The first provides an overview of ASD methods; the second explains some of their main advantages and the third which is the main idea of the article is about their application in China. Despite the fact that the author has made some salient points within his/her article about the benefits of using ASD methods in China I remain unconvinced that it would provide the improvement of quality and efficiency of software development as the author states. [1]

I do not dispute the fact that ASD has many advantages in certain situations but in fact what I am trying to say is that the author has looked at the problem too conveniently by considering it only from the positive side of adapting it in China and has overlooked the disadvantages that might arise. In my opinion when proposing a method(s) both the good and the bad outcomes of it (them) should be taken into account and if not then the proposal is unrealistic and too good to be true. Hence in my response article I will be discussing the author’s three main paragraphs and say their strengths and weaknesses according to my knowledge.

 

Discussion:

What is Agile Software Development?

In this paragraph the author describes the main ideas behind the agile software development methods in general. He/she mentions that these methods design is based on changing requirements and development adaptation. But the author also says that such methods are more applicable for small-scale teams within this description so in his later statements when considering their implementations in large-scale systems he/she should discuss that such methods are at a disadvantage as opposed to a more plan driven approach or non-agile methods that are designed for larger teams. [5] He fails to mention that agile methodology has less documentation as opposed to heavyweight ones and in some situation this would be crucial.

The next part of the authors’ explanation of ASD is actually taken out from [5] and is an ongoing debate, which he fails to mention and he only talks about the beneficial side of this debate. He/she does not talk about the criticism that the main values of ASD, that he cites in his article and the idea of the items on the left being more important that the items on the right. In [8] it is mentioned that this concept is being used by hackers to write code irresponsibly and is used as an excuse for not writing good documentation or following a plan. In my opinion this might give raise to many problems in large-scale systems, such as lack of documentation or the lack of following a plan might result in ASD being detrimental to the whole system. As in [8] hackers interpretation of “responding to change over following a plan” is roughly “Great! Now I have a reason to avoid planning and to just code up whatever comes next.”

Another good thing the author might have mentioned would have been to discuss or at least mention different agile methods and each one’s advantage or disadvantage in different situations. In my opinion that would have been beneficial if the reader was trying to understand how such methodologies would be applicable in different scenarios.

Why do we use Agile Software Development?

 In this paragraph the author discusses the advantages of ASD over the waterfall method. He/she gives salient observations about the situations in which an agile method is better to be implemented (The case of ever-changing requirements for example). So the idea of the paragraph – to convince us to use ASD – is justified with good examples. But nevertheless the author is talking about hypothetical situations. If we were to discuss another hypothetical situation of a critical system (software for a nuclear reactor, medical systems etc.) where all the requirements are strict and there is a need for good documentation then a heavy-weight approach would be more applicable.

The author also states five advantages of ASD [1]. All of them are well supported by the situations given. In the second advantage (Quality) the author discusses a specific agile method – extreme programming (XP) – but XP is aimed at software-only projects and large projects tend to be multidisciplinary so implementing it might be problematic [2]. The fifth advantage that the author mentions (efficient self-organized team) is more a demand than an advantage. It is true that such methodology enhances team communication but if none is apparent before its implementation or if the individuals lack suck skills then the methodology would not work. And these cases are not captured by the author.

Agile Software Development in China

In this section the author discusses how agile software development is present in China nowadays and how it has proven to be of more interest recently. He/she also states that such methodologies are still in an early adopter stage and the author gives his three main reasons for why this is so.

In the first reason the author talks about small-scale companies in China and how they do not implement standard development methods but instead the process depends on personal style of the leader. He states that this has no management cost and offers more freedom for team members but I do not see it this way. First I cannot see how a process depending on a team leader provides freedom for the team members since the leader might impose a method for everyone and in such case they have not got the freedom the author is talking about. Also if the manager is competent and makes perfect design decision then there would not be any management costs but if his/her decisions are not good then the overhead of such development method would be quite costly.

Anyway the author considers these things as advantages and mentions disadvantages such that the code produced in such environments is of an unstable quality. He states that it is thought to generate a cohesive and self-organized team so if that is the case in such companies wouldn’t that be a hurdle toward implementing an agile method since the author stated that that is one of the requirements in order for it to work. [1] The other points about the already existing chaotic methods and their disadvantages are otherwise good and in such small-scale companies ASD would provide higher efficiency and quality of product. That is if the software involves changing requirements and factors otherwise a heavyweight approach would be beneficial too and the author does not mention that explicitly.

The second reason for implementing ASD in China the author talks about resources being the bottleneck of development companies and suggests the usage of ASD in order utilize the existing resources properly. But in my opinion this is not a reason to choose to apply an agile methodology. If the author has stated that most of the software in such environments needs to be adaptable because of unstable requirements, then yes I would agree with the benefits of implementing agile development but since he/she did not specify the situation in such manner then why not consider heavyweight methodologies?

The third reason the author gives is that the principles of agile software development would be easily accepted in China because of their culture. Since I am not that familiar with the culture there I cannot disagree on that and I consider that to be true. Nevertheless there are different agile methodologies such as XP, Scrum, Crystal and each of them have different principles and with some differences between them so to which is the author referring to? He/she also states that since the most popular coding style in China is the cowboy one and this is his/her reason to why ASD would be easy to develop and implement since they are more similar than “other professional coding styles”. What the author fails to grasp is that ASD is not necessarily a coding style but it can be a management style (Scrum) or a hybrid. So this would have been a good point if the author said a specific agile methodology that is similar to “cowboy coding”. Not to mention the fact that it still appears that the author is talking about small-scale systems.

 

Conclusion:

The author of the article has given good points for implementing agile software development in China but I as a reader remain unconvinced by his article alone. He/she does not consider the negative sides of implementing such methodology and overall does not appear to be discussing it for large-scale or critical projects (where agile methods are at a disadvantage). Since all methods are controversial [7] and none can be considered to be applicable in all situations the thing that the author lacks most is that he/she has not mentioned when such methods are good to be used and where their implementation would be detrimental. That in my opinion provides an unrealistic view of the benefits of implementation of agile software development and hence is a reason why I remain overall unconvinced by the author’s article [1].

REFERENCES:

[1] Agile Software Development in China. s1314857,  February 14, 2014.

[2] Extreme Programming from a CMM Perspective. M. C. Paulk. IEEE Software, November/December 2001.

[3] Manifesto for Agile Software Development. Various authors, IEEE Software, November/December 2001.

[4] Recovery, Redemption, and Extreme Programming. P. Schuh. IEEE Software, November/December 2001.

[5] Get ready for agile methods, with care. B. Boehm. IEEE Computer 35(1):64-69, 2002.

[6] Management Challenges to Implementing Agile Processes in Traditional Development Organizations. B. Boehm, R. Turner. IEEE Software September/October 2005.

[7] Software Development Methodologies Lecture

[8] S. Rakitin, “Manifesto Elicits Cynicism,” Computer, Dec. 2001, p. 4.

A World Full Of Patterns

Introduction:

We live in a world that is full of patterns. And what is a pattern anyway? In general a pattern can be described as an arrangement of repeated or corresponding parts. If we are talking about a design pattern is software, then it is a reusable solution to a commonly occurring problem [1], a template of some sorts. So why do people try to find patterns anyway? How are they useful? In the most general case we strive to find patterns in order to get rid of the chaos that surrounds us or maybe when we see a pattern it helps us understand the inner workings of the universe. Who knows? Who cares why we are looking for them? The thing is that patterns are generally a good way of understanding how things are constructed. If you think about it we are an example of nature’s patterns too. Every person is different yes but nevertheless our specie have key features, such as limbs; organs etc..,that categorizes us as being human. And the main reason why we want to see patterns is that once you see that they are not random and when something is not random and there is some repetition within it, some sort of pattern that keeps reoccurring, you understand it better and maybe you can use that understanding in recreating it or using it as a basis for creating something even better.

In this article I will not talk about patterns in that general sense though. Instead I will try to explain their importance in the context of software projects and how they can be helpful for a successful project.

Algorithmic Patterns:

First I will talk about algorithmic patterns. We all have come across an algorithm or two in our time either programming an algorithm or implementing it in a real-world scenario. It is basically a step by step execution of simpler tasks that achieve a harder goal in the end. If the algorithm is well known to your colleagues then there would not be any need of explaining it to them in details and one of the most time consuming tasks when working in a team is to explaining why and how your code works. If it is algorithm known by most then this section of the project can be understood and maintained by others. And in a large-scale system the more people understand how everything works the better.

Programming Patterns:

It has been a long time since the first computers has been invented and since then so many things that were previously done by hand are now automatic. And why would it not be? The whole idea of technologies is to make our lives easier. The more we come across the same problem the more familiar we are with its solution (if we have found it). So the whole idea is if you find something that is recurring more than twice why not implement it a single time as a function/algorithm and then use that when you come across it again and avoid solving it all over again. In small and large-scale systems alike by avoiding repetition the outcome is that the system that has been developed becomes easier to understand hence easier to be maintained, extended and managed.

Patterns in programming can be the whole approach of reaching the solution of a problem. These are design patterns that are basically a way several programmers can communicate on a similar language. Since everybody has its own way of doing things it is often hard to write code in the same style. This is due to different backgrounds or way of thinking in general.  In large-scale systems since the work can’t be done by a single person and most parts are connected to each other there is the issue of being able to connect them properly. This requires a lot of communication and effort. One way of reducing the amount of effort is to implement the different parts of the system in a way that is easier to understand by most people involved. One way to do that is to use design patterns that are well known by the different teams. In other words design patterns become some sort of a shared vocabulary. Such patterns can either be developed or agreed upon by all of the connected teams or be so famous that everybody would know how to use them. In both cases by using design patterns the documentation of the system and the communication between different teams and team members become much easier.

Architectural Patterns:

These are patterns that occur at higher level than design patterns and are basically the way a large system can be organized either by being divided into smaller chunks or be made in an adaptive way. There are many examples of such patterns such as Layered Abstractions, Pipes and Filters, Blackboard, Model-View-Controller, Presentation-Abstraction-Control, Mircokernel, SOA, etc. I will not go into detail explaining every one of them. However I will mention the advantages and disadvantages of implementing such architectural patterns in a large-scale system. The decision a software architect or even an architect makes at the beginning about how the whole system/building would be structured has a huge impact on the project. Every single choice has consequences and every structure that is chosen has advantages and disadvantages. The key is to choose the best that fits the need. By using an already existing pattern as a foundation to your project can help you see issues that you have not considered. Since most of these patterns’ issues are known if you implement one of them you would know what to expect and if the disadvantages do not matter in your case then the architecture fits good to your problem. Of course the idea is to implement an architecture that is tailored to your specific problem but if there are similar solutions and similar architectures why not use them? There is no need to reinvent the wheel. In most cases it is much easier to extend an already existing architecture and modify it according to your needs than start from scratch. Another advantage is that when using an architectural pattern then documentation would be a lot easier since the pattern already has documentation. And since most people leave documentation for a later stage some of the choices made might be forgotten [9] thus leading to incomplete documentation. It is well known that documentation in large-scale systems is very important. It can be used as a manual to a user, or a way of communication between different teams within the project. It does not matter the purpose of it the thing that matters is that it is more useful to be complete than incomplete with some key things omitted. So one way to tackle the problem of documentation is to use an existing architectural pattern and thus reduce the chance of omitting to document some decision. The disadvantages from architectural patterns differ for each and as long as these architectures can be tailored to reduce them they are worth being used as a base to your architecture.

Conclusion:

Patterns exist everywhere in the real-world and in software alike. They provide a common ground which can be used for communication between different people or can be used to gain better understanding of different problems. Either way they provide great aid in developing, maintaining and managing large-scale projects that involve a the need of communication, documentation and overall good management.

 

Bibliography:

[1] Wikipedia entry on Design Patterns

[2] Avoiding Repetition M. Fowler. IEEE Software, 18(1), 2001.

[3] Is This a Pattern? T. Winn, P. Calder. IEEE Software, 19(1):59-66, January/February, 2002.

[4] Past, Present, and Future Trends in Software Patterns. F. Buschmann, K. Henney, D.C. Schmidt. IEEE Software, 24(4):31-37, July, 2007.

[5] Design Patterns: Abstraction and Reuse of Object-Oriented Design. Erich Gamma, Richard Helm, Ralph E. Johnson, and John M. Vlissides. 1993. In Proceedings of the 7th European Conference on Object-Oriented Programming (ECOOP ’93), Oscar Nierstrasz (Ed.). Springer-Verlag, London, UK, UK, 406-431.

[6] The Growing Divide in the Patterns World. D. Manolescu, W. Kozaczynski, A. Miller, J. Hogg. IEEE Software, 24(4):61-67, July 2007.

[7] The pros and cons of adopting and applying design patterns in the real world. M.P. Cline. Communications of the ACM, 39(10):47-49, October, 1996.

[8] Design Patterns: Elements of Reusable Object-Oriented Software Gamma, Helm, Johnson, and Vlissides 1995, Addison-Wesley, ISBN 020163361X.

[9] Using Patterns to Capture Architectural Decisions. N.B. Harrison, P. Avgeriou, U. Zdun. IEEE Software, July/August 2007.

[10] Using Architectural Patterns and Blueprints for Service-Oriented Architecture. M. Stal. IEEE Software, March/April 2006.