Software Maintenance Implications on Cost and Schedule

Abstract The dictionary defines maintenance as, “The work of keeping something in proper order.” However, this definition does not necessarily fit for software. Software maintenance is different from hardware maintenance because software doesn’t physically wear out, but often gets less useful with age. Software is typically delivered with undiscovered flaws. Therefore, software maintenance is: “The process of modifying existing operational software while leaving its primary functions intact.” Maintenance typically exceeds fifty percent of the systems’ life cycle cost . While software maintenance can be treated as a level of effort activity, there are consequences on quality, functionality, reliability, cost and schedule that can be mitigated through the use of parametric estimation techniques.

1. INTRODUCTION One of the greatest challenges facing software engineers is the management of change control. It has been estimated that the cost of change control can be between 40% and 70% of the life cycle costs . Software engineers have hoped that new languages and new process would greatly reduce these numbers; however this has not been the case. Fundamentally this is because software is still delivered with a significant number of defects. Capers Jones estimates that there are about 5 bugs per Function Point created during Development . Watts Humphrey found “… even experienced software engineers normally inject 100 or more defects per KSLOC . Capers Jones says, “A series of studies the defect density of software ranges from 49.5 to 94.5 errors per thousand lines of code .” The purpose of this article is to first review the fundamentals of software maintenance and to present alternative approaches to estimating software maintenance. A key element to note is that development and management decisions made during the development process can significantly affect the developmental cost and the resulting maintenance costs.

2. SOFTWARE MAINTENANCE Maintenance activities include all work carried out post-delivery and should be distinguished from block modifications which represent significant design and development effort and supersede a previously released software package. These maintenance activities can be quite diverse, and it helps to identify exactly what post-delivery activities are to be included in an estimate of maintenance effort. Maintenance activities, once defined, may be evaluated in a quite different light than when called simply “maintenance”. Software maintenance is different from hardware maintenance because software doesn’t physically wear out, but software often gets less useful with age and it may be delivered with undiscovered flaws. In addition to the undiscovered flaws, it is common that some number of known defects pass from the development organization to the maintenance group. Accurate estimation of the effort required to maintain delivered software is aided by the decomposition of the overall effort into the various activities that make up the whole process.

3. APPROACHING THE MAINTENANCE ISSUE Maintenance is a complicated and structured process. In his textbook, Estimating Software Intensive Systems, Richard Stuzke outlines the typical software maintenance process. It is apparent that the process is more than just writing new code.

The following checklist can be used to explore the realism and accuracy of maintenance requirements.

o Which pieces of software will be maintained?

o How long will the system need to be maintained?

o Are you estimating the entire maintenance problem, or just incremental maintenance?

o What level of maintenance is required?

o Is that which is being called maintenance in fact a new development project?

o Who will do the maintenance? Will it be done organically by the original developer? Will there be a separate team? Will there be a separate organization?

o Will maintainers be using the same tools used during development? Are any proprietary tools required for maintenance?

o How much Commercial-Off-The-Shelf (COTS) is there? How tightly coupled are the interfaces?

o Some follow-on development may be disguised as maintenance. This will either inflate maintenance figures, or else cause shortfalls if basic maintenance gets pushed aside. These questions will help you ask whether maintenance is being honestly represented.

o Is the activity really an incremental improvement?

o Are healthy chunks of the original code being rewritten or changed?

o Will additional staff be brought in to perform the upgrade?

o Is the maintenance effort schedule regular and fairly flat, or does it contain staffing humps that look like new development?

4. SANITY CHECKS Although sanity checks should be sought on a year-by-year basis, they should not be attempted for overall development. The reason for this is that maintenance activities can be carried on indefinitely, rendering any life-cycle rules useless. As an example, consider Grady (p. 17):

We spend about 2 to 3 times as much effort maintaining and enhancing software as we spend creating new software.

This and similar observations apply at an organizational level and higher, but not for a specific project. Any development group with a history will be embroiled in the long tail ends of their many delivered projects, still needing indefinite attention. Here are a few quick sanity checks:

o One maintainer can handle about 10,000 lines per year.

o Overall life-cycle effort is typically 40% development and 60% maintenance.

o Maintenance costs on average are one-sixth of yearly development costs.

o Successful systems are usually maintained for 10 to 20 years.

Finally, as in development, the amount of code that is new versus modified makes a difference. The effective size, that is, the equivalent effort if all the work were new code, is still the key input for both development and maintenance cost estimation.

5. FIVE ALTERNATIVE APPROACHES All software estimation techniques must be able to model the theory and the likely real world result. The real world scenario is that over time, the overlay of changes upon changes makes software increasingly difficult to maintain and thus less useful. Maintenance effort estimation techniques range from the simplistic level of effort method, through more thoughtful analysis and development practice modifications, to the use of parametric models in order to use historical data to project future needs.

5.1 Level of Effort As is sometimes the case in the development environment, software maintenance can be modeled as a level of effort activity. Given the repair category activities and the great variance that they show, this approach clearly has deficiencies. In this approach, a level of effort to maintain software is based on size and type.

5.2 Level of Effort Plus Stuzke proposed that software maintenance starts with basic level of effort (minimum people needed to have a core competency and then that that basic core staff must be modified by assessing three additional factors; configuration management, quality assurance, and project management. His process addressed some of the additional factors affecting software maintenance.

5.3 Maintenance Change Factor Software Cost Estimation with COCOMO II (Boehm 2000) proposes a deceivingly simple, but also quite useful methodology for determining annual maintenance. Maintenance is one of the menu selections in the menu bar. In COCOMO II Maintenance encompasses the process of modifying existing operational software while leaving its primary functions intact. This process excludes:

o Major re-design and re-development (more than 50% new code) of a new software product performing substantially the same functions.

o Design and development of a sizeable (more than 20% of the source instructions comprising the existing product) interfacing software package which requires relatively little redesigning of the existing product.

o Data processing system operations, data entry, and modification of values in the database.

The maintenance calculations are heavily based upon the Maintenance Change Factor (MCF) and the Maintenance Adjustment Factor (MAF). The MCF is similar to the Annual change Traffic in COCOMO81, except that maintenance periods other than a year can be used. The resulting maintenance effort estimation formula is the same as the COCOMO II Post Architecture development model.

As stated previously, three cost drivers for maintenance differ from development. Those cost drivers are software reliability, modern programming practices, and schedule. COCOMO II assumes that increased investment in software reliability and use of modern programming practices during software development has a strong positive effect upon the maintenance stage.

Annual Maintenance Effort = (Annual Change Traffic) * (Original Software Development Effort)

The quantity Original Software Development Effort refers to the total effort (person-months or other unit of measure) expended throughout development, even if a multi-year project.

The multiplier Annual Change Traffic is the proportion of the overall software to be modified during the year. This is relatively easy to obtain from engineering estimates. Developers often maintain change lists, or have a sense of proportional change to be required even before development is complete.

5.4 Managing Software Maintenance Costs by Developmental Techniques and Management Decisions During Development

When it comes to maintenance, “a penny spent is a pound saved.” Better development practices (even if more expensive) can significantly reduce maintenance effort, and reduce overall life cycle cost. The more effort put into development, the less required in maintenance. As an example, the software development cost and schedule can be significantly impacted (reduced) by letting the number of defects delivered grow. This cost and schedule reduction is more than offset by the increase in maintenance cost. The following discussion is an example of how management decision can significantly affect/reduce software maintenance costs.

Lloyd Huff and George Novak of Lockheed Martin Aeronautics in their paper “Lockheed Martin Aeronautics Performance Based Software Sustainment for the F-35 Lightning II” propose a series of development and management decision designed to impact and reduce software maintenance costs. They propose an eight step process to estimate and control software maintenance . Their proposed steps are:

1. Strive for Commonality

2. Apply Industrial Engineering Practices to Software

3. Engage

4. Adopt a Holistic Approach to Sustainment

5. Develop Highly Maintainable Systems and Software

6. Manage the Off-the-Shelf Software

7. Plan for the Unexpected

8. Analyze and Refine the Software Sustainment Business Case (use Parametric software sustainment cost estimates)

5.5 A Parametric Assessment of Software Maintenance

Parametric models like SEER for Software allow maintenance to be modeled in either of two ways:

Estimating maintenance as a part of the total lifecycle cost. Choosing the appropriate Maintenance category parameters will include an estimate of maintenance effort with the development estimate for the individual software program. Several reports and charts show breakdowns of development vs. maintenance effort. This method is best used to evaluate life cycle costs for each individual software program.

Estimating maintenance as a separate activity. Using the appropriate maintenance parameters for the software to be maintained you can model the maintenance effort as a separate activity. This method will allow you to fine tune your maintenance estimate by adjusting parameters. Maintenance size should be the same as development size, but should be entered as all pre-existing code. This method can also be useful in breaking out total project maintenance costs from project development costs.

A good parametric estimate for maintenance includes a wide range of information. Critical information for completing a software maintenance estimate is the size or amount of software that will be maintained, the quality of that software, the quality and availability of the documentation, and the type or amount of maintenance that will be done. Many organizations don’t actually estimate maintenance costs; they simply have a budget for software maintenance. In this case, a parametric model should be used to compute how much maintenance can actually be performed with the given budget.

Estimating and planning for maintenance are critical activities if the software is required to function properly throughout its expected life. Even with a limited budget, a plan can be made to use the resources available in the most efficient, productive manner. Looking at the diagram above, you can see that not only are the multiple inputs that impact the maintenance, but there are several key outputs that provide the information necessary to plan a successful maintenance effort.

6. Conclusion The conclusions of this article are:

o Software maintenance can be modeled using a simplistic method like Level of Effort Staffing, but this technique has significant drawbacks.

o Software maintenance costs can be significantly affected by management decisions during the developmental process.

o Software maintenance can be accurately estimated using parametric processes.

o Software maintenance is best modeled when development and management decisions are coupled with parametric cost estimation techniques.

REFERENCES [1] Software Maintenance Concepts and Practices (second Edition) by Penny Grubb and Armstrong Takang, World Scientific, 2005.

An Overview of Software Patenting

INTRODUCTION

The concept of “intellectual property” in India over the last few years has taken on some epic proportions for a number of reasons. One of the primary reasons, attributable to the growing awareness among the urban Indian population, is of the significance and, more importantly, the commercial benefits in protecting its intellectual property rights both within and outside India. And under traditional principles of intellectual property protection, patent law is to encourage scientific research, new technology and industrial progress. The fundamental principle of patent law is that the patent is granted only for an invention i.e. new and useful the said invention must have novelty and utility. The grant of patent thus becomes of industrial property and also called an intellectual property. And the computer software is a relatively new recipient of patent protection.

The term “Patent” has its origin from the term “Letter Patent”. This expression ‘Letter Patent’ meant open letter and were instruments under the Great Seal of King of England addressed by the Crown to all the subjects at large in which the Crown conferred certain rights and privileges on one or more individuals in the kingdom. It was in the later part of the 19th century new inventions in the field of art, process, method or manner of manufacture, machinery and other substances produced by manufacturers were on increased and the inventors became very much interested that the inventions done by them should not be infringed by any one else by copying them or by adopting the methods used by them. To save the interests of inventors, the then British rulers enacted the Indian Patents and Design Act, 1911.

With respect to patentability of software -related inventions, it is currently one of the most heated areas of debate. Software has become patentable in recent years in most jurisdictions (although with restrictions in certain countries, notably those signatories of the European Patent Convention or EPC) and the number of software patents has risen rapidly.

MEANING OF SOFTWARE PATENTING

The term “software” does not have a precise definition and even the software industries fails to give an specific definition. But it is basically used to describe all of the different types of computer programs. Computer programs are basically divided into “application programs” and “operating system programs”. Application programs are designed to do specific tasks to be executed through the computer and the operating system programs are used to manage the internal functions of the computer to facilitate use of application program.

Though the term ‘Software patent’ does not have a universally accepted definition. One definition suggested by the Foundation for a Free Information Infrastructure is that a software patent is a “patent on any performance of a computer realized by means of a computer program”.

According to Richard Stallman, the co-developer of the GNU-Linux operating system and proponent of Free Software says, “Software patents are patents which cover software ideas, ideas which you would use in developing software.

That is Software patents refer to patents that could be granted on products or processes (including methods) which include or may include software as a significant or at least necessary part of their implementation, i.e. the form in which they are put in practice (or used) to produce the effect they intend to provide.

Early example of a software patent:

On 21st Sep 1962, a British patent application entitled “A Computer Arranged for the Automatic Solution of Linear Programming Problems” was filed. The invention was concerned with efficient memory management for the simplex algorithm, and may be implemented by purely software means. The patent was granted on August 17, 1966 and seems to be one of the first software patents.

CONCEPTUAL DIFFERENCE BETWEEN COPYRIGHT AND PATENT

Software has traditionally been protected under copyright law since code fits quite easily into the description of a literary work. Thus, Software is protected as works of literature under the Berne Convention, and any software written is automatically covered by copyright. This allows the creator to prevent another entity from copying the program and there is generally no need to register code in order for it to be copyrighted. While Software Patenting has recently emerged (if only in the US, Japan and Europe) where, Patents give their owners the right to prevent others from using a claimed invention, even if it was independently developed and there was no copying involved.

Further, it should be noted that patents cover the underlying methodologies embodied in a given piece of software. On the other copyright prevents the direct copying of software, but do not prevent other authors from writing their own embodiments of the underlying methodologies.
The issues involved in conferring patent rights to software are, however, a lot more complex than taking out copyrights on them. Specifically, there are two challenges that one encounters when dealing with software patents. The first is about the instrument of patent itself and whether the manner of protection it confers is suited to the software industry. The second is the nature of software, and whether it should be subject to patenting.

However, issues involved in conferring patent rights to software are a lot more complex than taking out copyrights on them. Specifically, there are two challenges that one encounters when dealing with software patents. The first is about the instrument of patent itself and whether the manner of protection it confers is suited to the software industry. The second is the nature of software and whether it should be subject to patenting.

a) Different Subject Matters

Copyright protection extends to all original literary works (among them, computer programs), dramatic, musical and artistic works, including films. Under copyright, protection is given only to the particular expression of an idea that was adopted and not the idea itself. (For instance, a program to add numbers written in two different computer languages would count as two different expressions of one idea) Effectively, independent rendering of a copyrighted work by a third party would not infringe the copyright.

Generally patents are conferred on any ‘new’ and ‘useful’ art, process, method or manner of manufacture, machines, appliances or other articles or substances produced by manufacture. Worldwide, the attitude towards patentability of software has been skeptical.

b) Who may claim the right to a patent /copyright?

Generally, the author of a literary, artistic, musical or dramatic work automatically becomes the owner of its copyright.

The patent, on the other hand is granted to the first to apply for it, regardless of who the first to invent it was. Patents cost a lot of money. They cost even more paying the lawyers to write the application than they cost to actually apply. It takes typically some years for the application to get considered, even though patent offices do an extremely sloppy job of considering.

c) Rights conferred

Copyright law gives the owner the exclusive right to reproduce the material, issue copies, perform, adapt and translate the work. However, these rights are tempered by the rights of fair use which are available to the public. Under “fair use”, certain uses of copyright material would not be infringing, such as use for academic purposes, news reporting etc. Further, independent recreation of a copyrighted work would not constitute infringement. Thus if the same piece of code were independently developed by two different companies, neither would have a claim against the other.
A patent confers on the owner an absolute monopoly which is the right to prevent others from making, using, offering for sale without his/her consent. In general, patent protection is a far stronger method of protection than copyright because the protection extends to the level of the idea embodied by a software and injuncts ancillary uses of an invention as well. It would weaken copyright in software that is the base of all European software development, because independent creations protected by copyright would be attackable by patents. Many patent applications cover very small and specific algorithms or techniques that are used in a wide variety of programs. Frequently the “inventions” mentioned in a patent application have been independently formulated and are already in use by other programmers when the application is filed.

d) Duration of protection

The TRIPS agreement mandates a period of at least 20 years for a product patent and 15 years in the case of a process patent.

For Copyright, the agreement prescribes a minimum period of the lifetime of the author plus seventy years.

JURISDICTIONS OF SOFTWARE PATENTING

Substantive law regarding the patentability of software and computer-implemented inventions, and case law interpreting the legal provisions, are different under different jurisdictions.

Software patents under multilateral treaties:

o Software patents under TRIPs Agreement

o Software patents under the European Patent Convention

o Computer programs and the Patent Cooperation Treaty

Software patenting under TRIPs Agreement

The WTO’s Agreement on Trade-Related Aspects of Intellectual Property Rights (TRIPs), particularly Article 27, are subject to debate on the international legal framework for the patentability of software, and on whether software and computer-implemented inventions should be considered as a field of technology.

According to Art. 27 of TRIPS Agreement, patents shall be available for any inventions, whether products or processes, in all fields of technology, provided that they are new, involve an inventive step and are capable of industrial application. (…) patents shall be available and patent rights enjoyable without discrimination as to the place of invention, the field of technology and whether products are imported or locally produced.”

However, there have been no dispute settlement procedures regarding software patents. Its relevance for patentability in the computer-implemented business methods, and software information technology remains uncertain, since the TRIPs agreement is subject to interpretation.

Software patents under the European Patent Convention

Within European Union member states, the EPO and other national patent offices have issued many patents for inventions involving software since the European Patent Convention (EPC) came into force in the late 1970s. Article 52 EPC excludes “programs for computers” from patentability (Art. 52(2)) to the extent that a patent application relates to a computer program “as such” (Art. 52(3)). This has been interpreted to mean that any invention which makes a non-obvious “technical contribution” or solves a “technical problem” in a non-obvious way is patentable even if a computer program is used in the invention.

Computer-implemented inventions which only solve a business problem using a computer, rather than a technical problem, are considered unpatentable as lacking an inventive step. Nevertheless, the fact that an invention is useful in business does not mean it is not patentable if it also solves a technical problem.

Computer programs and the Patent Cooperation Treaty

The Patent Cooperation Treaty (PCT) is an international patent law treaty, which provides a unified procedure for filing patent applications to protect inventions. A patent application filed under the PCT is called an international application or PCT application. Under the PCT, the international search and the preliminary examination are conducted by International Searching Authorities (ISA) and International Preliminary Examining Authority (IPEA).

CURRENT TREND

However, before we start hailing the advent of a new era and equating the patenting of software in India it would be well worth our while to take a pause and examine the realities of software patenting. We could do this by looking at examples of countries in which software patenting has already become the order of the day, such as in the US and Japan .

United States

The United States Patent and Trademark Office (USPTO) has traditionally not considered software to be patentable because by statute patents can only be granted to “processes, machines, articles of manufacture, and compositions of matter”. i.e. In particular, patents cannot be granted to “scientific truths” or “mathematical expressions” of them. The USPTO maintained the position that software was in effect a mathematical algorithm, and therefore not patentable, into the 1980s. This position of the USPTO was challenged with a landmark 1981 Supreme Court case, Diamond v. Diehr. The case involved a device that used computer software to ensure the correct timing when heating, or curing, rubber. Although the software was the integral part of the device, it also had other functions that related to real world manipulation. The court then ruled that as a device to mold rubber, it was a patentable object. The court essentially ruled that while algorithms themselves could not be patented, devices that utilized them could.

But in 1982 the U.S. Congress created a new court i.e the Federal Circuit to hear patent cases. This court allowed patentability of software, to be treated uniformly throughout the US. Due to a few landmark cases in this court, by the early 1990s the patentability of software was well established.

Moreover, Several successful litigations show that software patents are now enforceable in the US. That is the reason, Patenting software has become widespread in the US. As of 2004, approximately 145,000 patents had issued in the 22 classes of patents covering computer implemented inventions.

Japan

Software is directly patentable in Japan. In various litigations in Japan, software patents have been successfully enforced. In 2005, for example, Matsushita won a court order barring Justsystem from infringing Matsuhita’s Japanese patent 2,803,236 covering word processing software.

Indian Position

With respect to computer software, in Patents (Amendment) Act, 2002, the scope of non-patentable subject matter in the Act was amended to include the following: “a mathematical method or a business method or a computer programme per se or algorithms”.

However, the recent amendment changes (Ordinance, 2004), which amends the Patents Act, 1970, has been promulgated after receiving assent from the President of India and has came into effect from 1st Jan., 2005. Apart from change in pharmaceuticals and agro chemicals, one of the seminal amendments this Ordinance seeks to bring is to permit the patenting of embedded software.
Hence, the amendment means that while a mathematical or a business method or an algorithm cannot be patented, a computer programme which has a technical application in any industry or which can be incorporated in hardware can be patented. Since any commercial software has some industry application and all applications can be construed as technical applications, obviously it opens all software patenting.

In any case, any company seeking to file a patent application for software under the Ordinance should ensure that its invention firstly, follows the three basic tests:

o Inventive Steps

o Novelty

o Usefulness

Therefore, it is important that the software sought to be protected is not merely a new version or an improvement over an existing code.

Further, in accordance with the specific requirements of the Ordinance with regard to patentability of software, the software should necessarily have a technical application to the industry or be intrinsic to or “embedded” in hardware. This is to prevent against any future litigation or claims of infringements being raised, which is a distinct probability even after a patent has been granted.

CONCLUSION

India for its part seems to have adopted the more conservative approach of the European patenting norms for software. But the Ordinance definitely has its use and relevance in today’s India, particularly for our growing domestic semi- conductor industry. This, along with judicial tempering might definitely ensure a judicious use of patent protection while allowing the industry to grow through innovations and inventions, thereby, mitigating the risks of trivial patents chocking the life out of real innovations and inventions. This is the reason a patent should always be treated as a “double edged sword”, to be wielded with caution and sensitivity.

Current Management Opportunities and Challenges in the Software Industry

During the past 30 years the world went through a very dynamic technological transformation. In retrospective, it can be stated without exaggeration that the emergence of electronic devices and the Internet have greatly impacted daily life as well as managerial practice to an unforeseen extent. The computerization of multiple business processes and the creation of large scale databases, among many other radical technological advances, have lead to enormous cost savings and quality improvements over the years. The interconnection of financial markets through electronic means and the worldwide adoption of the Internet have greatly reduced transaction and communication costs and brought nations and cultures closer to one another than ever imaginable. Computers are now fundamental tools in almost all businesses around the world and their application and adaptation to specific business problems in the form of software development is a practice that many companies perform on their own. In the past, such computerization and automation efforts were very costly and therefore only practiced by large corporations. Over the years, however, the software industry emerged to offer off-the-shelf solutions and services to smaller companies. Today, having survived the massive dotcom crash of the year 2000, software development businesses established themselves as strong players in the technology industry.

The emergence of numerous computer standards and technologies has created many challenges and opportunities. One of the main opportunities provided by the software sector is relatively low entry barrier. Since the software business is not capital intensive, successful market entry largely depends on know-how and specific industry domain knowledge. Entrepreneurs with the right skills can relatively easily compete with large corporations and thereby pose a considerable threat to other, much larger organizations. Companies, on the other hand, need to find ways to reduce turnover and protect their intellectual property; hence, the strong knowledge dependence combined with the relatively short lifespan of computer technologies makes knowledge workers very important to the organization. Knowledge workers in this industry therefore enjoy stronger bargaining power and require a different management style and work environment than in other sectors, especially those industries that have higher market entry capital requirements. This relatively strong position of software personnel challenges human resource strategies in organizations and it also raises concerns about the protection of intellectual property.

The relatively young industry is blessed with sheer endless new opportunities, such as the ability of companies to cooperate with other organizations around the globe without interruption and incur practically no communication costs. In addition, no import tariffs exist making the transfer of software across borders very efficient; however, the industry with its craft-like professions suffers from lack of standards and quality problems. The successful management of such dynamic organizations challenges today’s managers as well as contemporary management science because traditional management styles, such as Weberian bureaucracies, seem to be unable to cope with unstable environments.

Challenges in the Software Industry

Many studies indicate that present-day software development practices are highly inefficient and wasteful (Flitman, 2003). On average, projects are only 62% efficient, which translates to a waste of 37 %. The typical software development project has the following distribution of work effort: 12% planning, 10% specification, 42% quality control, 17% implementation, and 19% software building (2003). There are many possible interpretations of the nature of this distribution of resources. First, the extraordinarily high share of 42% for quality control purposes can indicate a lack of standards and standardized work practices. This large waste of effort may also be the result of inefficient planning and specification processes. Because the share of 19% for software building is a function of software complexity, hardware, and tools used, there is a chance to reduce it by carefully managing and standardizing internal work processes. The disappointing share of only 17% for implementation, however, should be alarming to business owners, since implementation activities are the main activity that results in revenue. The relatively low productivity level reported by Flitman (2003) seems to be also reflected in the fact that the average U.S. programmer produces approximately 7,700 lines of code per year, which translates to just 33 per workday (Slavova, 2000). Considering that a large software project, such as Microsoft Word, is reported by Microsoft to require 2 to 3 million lines of code, it becomes obvious how costly such projects can become and that productivity and quality management are major concerns to today’s software businesses. The challenge for contemporary software managers is to find the root of the productivity problem and a remedy in the form of a management practice.

A plethora of recent studies addresses software development productivity and quality concerns. Elliott, Dawson, and Edwards (2007) conclude that there is a lack of quality skills in current organizations. Furthermore, the researchers put partial blame on prevailing organizational cultures, which can lead to counterproductive work habits. Of the main problems identified, project documentation was found to be lacking because documents are deficient in detail and not updated frequent enough. Quality control in the form of software testing is not practiced as often and there seems to be a lack of quality assurance processes to ensure that software is built with quality in mind from the beginning. Organizational culture was found to be deficient in companies were workers tend to avoid confrontation and therefore avoid product tests altogether (2007).

Since knowledge workers are the main drive in software organizations, creating a fruitful and efficient organizational culture constitutes a main challenge to today’s managers. The relationship between organizational culture and quality and productivity in software businesses was recently investigated by Mathew (2007). Software organizations tend to be people-centered and their dependency on knowledge workers is also reflected by the enormous spending remuneration and benefits of more than 50% of revenue. As the industry matures and grows further, the challenge to organizations is that larger number of employees need to be managed which brings culture to the focus of management. Mathew (2007) found that the most important influence on productivity was achieved by creating an environment of mutual trust. Higher levels of trust lead to greater employee autonomy and empowerment, which strengthened the existing management view that trust and organizational effectiveness are highly related. Those companies with higher trust and empowerment levels benefitted from more intensive employee involvement and thereby achieved better quality products (2007).

Product quality, however, depends on other factors as well that reach beyond the discussion of work processes. Relatively high employee turnover was found to have a detrimental effect on product quality and organizational culture (Hamid & Tarek, 1992). Constant turnover and succession increase project completion costs, cause considerable delays, and expose organization to higher risks because their development processes can be severely disrupted. While human resources strategies should help find ways to retain key personnel in the company, organizations need to nevertheless be prepared for turnovers and minimize their risks. One of the greatest risks for people-centered, knowledge worker organizations is the loss of knowledge when employees leave.

Knowledge management has evolved into a relatively new discipline in the last two decades but is mostly practiced by large, global organizations only (Mehta, 2008). As corporations realized the importance of knowledge management activities to mitigate the risk of know-how loss within their organizations, they started employing chief knowledge officers and crews with the goal of collecting and organizing information. By building custom knowledge management platforms, companies can benefit from increased transfer, storage, and availability of critical business information. Such activities can help companies innovate and build knowledge capital over time (2008). The challenge remains, however, to set up such systems and to elicit employee support for knowledge management systems. In addition, these systems leave another critical question open. What happens when top performers take all the knowledge with them when they leave?

Another crucial variable affecting software product and service quality is top management involvement. Projects in the software industry commonly fail due to one or a combination of the following three major causes: poor project planning, a weak business case, and lack of top management support and involvement (Zwikael, 2008). Software projects are similar to projects in other industries by focusing on timely project completion, budget, and compliance to specifications, the industry requires specific support processes from top management to facilitate projects. These processes are summarized in Table 1. Key support processes, such as the appropriate assignment of project managers and the existence of project success measurement, indicate that successful companies demonstrate a higher level of project progress control than others; however, Zwikael acknowledges that top managers rarely focus on these key processes and instead prefer to deal with those processes that are easier for them to work on personally.

Table 1

The ten most critical top management support processes in the software sector (Zwikael, 2008). Those processes marked with an asterisk (*) were found to be the most important.

Support Process

Appropriate project manager assignment *

Refreshing project procedures

Involvement of the project manager during initiation stage

Communication between the project manager and the organization *

Existence of project success measurement *

Supportive project organizational structure

Existence of interactive interdepartmental project groups *

Organizational projects resource planning

Project management office involvement

Use of standard project management software *

Opportunities in the Software Industry

The advent of low cost communication via the Internet and the diversification of the software industry into many different branches brought a multitude of new market opportunities. Some of the main opportunities are rooted in the low costs of communication, while others originated from the possibility of geographic diversification and international collaboration.

One major opportunity which especially larger organizations seek to seize is geographic diversification in the form of globally distributed software development. Kotlarsky, Oshri, van Hillegersberg, and Kumar (2007) have researched this source of opportunities that is mainly practiced by multinational companies; however, an increasing number of small companies is also reported to be benefitting from dispersed software development across national boundaries. The study revealed that software companies can achieve significantly higher levels of productivity by creating reusable software components and reducing task interdependencies. By reducing interdependence, the produced modules are more likely to become useful in future projects on their own; furthermore, this reduction of intertwined computer code also has a positive effect on project teams. Teams in companies that globally distribute their developments benefit from increased autonomy and reduced communication requirements. The authors point out, however, that the prerequisites to distributing software development are not only good project planning but also the standardization of tools and development procedures. Without such prearrangements it may become almost impossible to manage and consolidate the various distributed team activities (2007). Especially for teams working across countries away from one another, it may pay off to deploy video or other Internet-based conferencing technologies and exploit huge savings potentials. But are these means of communication effective?

In the last decade a new form of organization has emerged that has taken the most advantage of the Internet. Virtual organizations exist entirely in cyberspace and their team members communicate mostly, if not exclusively, via the Internet using webcams and messaging software. The challenge for managers in virtual organizations is to exploit the new technology but also to find ways to motivate and direct the workforce and work processes. A study by Andres (2002) compared virtual software development teams with face-to-face teams and identified several challenges and opportunities for virtual managers. Managing work from a different time zone can be problematic due to the lack of physical presence. Communication will need to be asynchronous or can only occur at work hours that overlap in both time zones. Virtual teams facilitate this process by using email and voice/text messaging but more importantly by reducing the interdependency of tasks. Andres (2002) suggested that these types of communication have lower “social presence” meaning that humans have a need and ability to feel the presence of others in the group. The problem with many computerized communication channels is that visual clues, utterances, body language clues and clues from the person’s voice are missing. When placed on a social presence continuum, the various communication types rank as follows from the lowest to the highest: email, phone, video conferencing, and face-to-face meetings. Andres’ comparison between development teams using video-conferencing versus face-to-face meetings revealed that the latter group was far more efficient and productive, even though the video-conferencing team benefitted from reduced travel costs and time.

The study conducted in 2002, however, has several shortcomings. First, it is already seven years old and Internet costs have dropped and speeds have improved significantly since then. Considering the improvements in video quality and availability and computer speeds, this form of communication became more feasible recently. In addition, today’s managers are just now starting to learn how to use these means of communication efficiently. For example, even though email technology has been around for two decades now, many managers still find that emails can create a lot of ambiguity. The challenge to future generations of managers will be to change their writing style to match the limitations of email and other text messaging technologies. Another important factor to consider is that written communication may be stored indefinitely and have legal consequences; hence, more often than not, managers may intentionally prefer to avoid such communication channels for political or legal reasons. The study by Andres (2002), however, resulted in a negative view of video conferencing probably because the technology was not yet matured and the team members were not yet comfortable with it.

For video conferencing to work well, all participants need to be knowledgeable of the peculiar characteristics of that technology and adjust their communication style and speech accordingly. Regardless of meeting type, another important factor is preparation. What could be researched in conjunction with Andres’ study in the future is the degree of preparation of the group. Do team members invest enough time in preparing questions and answers for their teammates before coming to the meeting? Video conferences may require more preparation than face-to-face meetings in some circumstances.

Another opportunity for software businesses and challenge for managers worldwide is outsourcing. In the year 2007, $70 billion were spent globally for outsourced software development (Scott, 2007). Given the extreme shortage of IT skills in the U.S. and Europe, many companies take advantage of globalization by choosing international suppliers for their software development tasks. Outsourcing, however, requires elaborate coordination between the organization and its many supplier groups. The idea is that in total, coordination costs and problems are less costly than in-house development; however, this goal is not always achieved. While outsourcing, when it is deployed and coordinated correctly, can result in 24 hour development worldwide and thereby provide continuous services to the organization around the clock, it may result in the loss of intellectual property. While mechanic parts are patentable in most countries that support intellectual property rights, software is not patentable in most countries outside North America.

In addition to the challenge of managing outsourcing, software organizations exploit technologies in various ways to save costs, for example by offering remote access, telecommuting, and service-oriented architectures (SOA) (Scott, 2007). Remote access and telecommuting has increased six-fold between 1997 and 2005 and resulted in $300 million annual savings due to a reduction of office space (2007). SOA is a similar concept and involves a software rental for customers. Instead of buying, installing, and maintaining software and servers, customers can rent a service online and reduce the total cost of ownership because these activities are no longer required on the customer side. Gradually the virtualization of the software business opens new horizons and provides further opportunities but it also presents managers with endless challenges.

Some of the strengths and weaknesses of offshore and virtual team development were studied by Slavova (2000). In the year 2000, India and Ireland were the largest offshore software development locations. Offshore companies can offer up to 60% cost reduction, a faster completion of development tasks by distributing them around the globe, and specific domain knowledge which they acquired over the years providing similar services to other customers. The integration of work from external sources, however, constitutes a major hurdle. Furthermore, language and cultural issues can cause serious communication problems that put the project at risk, especially when misunderstandings cause misinterpretations of project specification documents. Slavova (2000) found that the most common remedy and strategy avoiding problems with offshore suppliers is to visit them frequently face-to-face; however, this tactic results in higher travel costs and disruptions of the managers’ workflows and hence may offset the benefits gained for outsourcing altogether. Managers in the software business need therefore to balance the risks and opportunity potentials before engaging in outsourcing because for many companies this strategy failed to pay off in the end.

A huge opportunity that emerged in the last decade is online innovation. The collective innovation effort of many individuals and companies is generally known as open-source on the Internet and it has lead to many advances in the computer technology, such as the free Linux operating system. At first businesses felt threatened by this wave of developments on the market because the businesses perceived that open-source solutions were in competition with their products. In many cases this was and still is in fact true; however, a couple of companies, including IBM, are exploiting this new way of innovation for their own and for a common benefit (Vujovic & Ulhøi, 2008). Because software companies operate in an increasingly instable environment, they struggle to create continuously new and better products. By exposing the computer code to the public on the Internet, companies can benefit from ideas submitted by the public, especially other companies. Furthermore, companies benefit from free bug finding and testing by external users but one of the primary reasons for “going open-source” is the quick adoption and spread of the company’s technology at a relatively little or no cost. The spread of IBM’s open-source technology, for example, is also free marketing for the company. But how can companies make money by offering something for free?

The closed innovation model (the traditional model of providing software without revealing the software code) can be combined with open-source, so the company can charge for the product. In other cases, the company can reveal the technological platform on the Internet for free and then sell specialized tools which utilize the new platform. The big money savers are obviously the shared development, testing, and maintenance costs since many interested parties work on the same project.

The knowledge-sharing model of open-source is nothing new, however. The philosophy and the benefits of open innovation models have been already realized in the third quarter of the nineteenth century. Back then, open innovation was practiced in the UK iron and

US steel industry. The cooperation of many industry players ended the domination of proprietary technologies for which costly royalties were due (Vujovic & Ulhøi, 2008). Given the dynamic environment of the IT industry and the short lifespan of computer technologies, the adoption of open innovation models gained much more popularity. By analyzing the largest open-source players in the market, Vujovic and Ulhøi put together a list of supportive strategies, which is shown in Table 2. Several of these strategies are quite relevant from a top management perspective as well, such as deploying open-source to block a competitor and using the open model as a gateway for greater market share.

Table 2

Strategies for adopting the open-source approach (Vujovic & Ulhøi, 2008).

Business Strategy

Obtaining higher market share

Obtaining market power

Better adoption of a product and thereby establishing standards

Shifting competitive advantage to another architectural layer

Making the product more ubiquitous

Delivering faster time-to-market

Spurring innovation

Complementing a revenue core stream

Blocking a competitor

Conclusion

Reviewing the rather recent emergence of the IT industry and the software industry in particular, several parallels can be drawn to management history. While Taylor’s scientific management was a highlight in the evolution of management science (Wren, 2005), the software industry seems to be lagging behind such great advancement. Due to its high level of complexity, the software development discipline is still plagued with quality problems stemming from a lack of standardization. Similar to Taylor’s efforts, managers need to analyze software development processes and develop industry-wide standards and measures. Once such measures and procedures exist, this will help make software projects much more predictable.

Much of today’s software industry practices would have been a déjà vu for Taylor, if he was still alive. In addition, the anomie and social disorganization concerns during the social person era apply today more dramatically than in the past. Mayo described in the 1940s how managers overemphasized on technical problems in the hope of raising efficiency ignoring the human social element (p. 296). The same situation is now evident to a larger degree in the computer industry. The rapid technological advances have created many opportunities and changed the work environment drastically. At the same time, however, management was unable to prepare for these dramatic shifts technology would bring to the workplace. At best, managers are simply reacting to technological advances because the consequences are mostly unpredictable given the complexity of human nature. For example, email brought several benefits such as low cost and simple asynchronous communication; however, many email messages are misunderstood because they are not written appropriately. Moreover, IT knowledge workers are struggling to keep up with the vast number of messages received per day as they constitute a severe disruption of the daily workflow.

As knowledge workers are becoming more and more essential to an organization’s survival and as organizations in this industry mature and require greater headcounts, the span of control is becoming an issue for managers to handle correctly. As discussed in Wren (2005), as the team size increases, the number of interrelations to be managed rises astronomically (p. 353). Managing larger teams poses a great problem because the sheer number of interrelations makes it also more difficult to develop trust within the team. Motivating large groups of knowledge workers can hence be tricky, especially because creative tasks can require a large degree of collaboration. Work design is hence a major hurdle for future managers to overcome. Much emphasis has been on hygiene factors and not on motivators of the workforce. Flexible hours, telecommuting, empowerment, and increased responsibility may help in the short-term but for the long-term management will need to find new strategies for retaining knowledge workers.

Product quality remains a big issue. Deming’s ideas are good but quality assurance in the software world is difficult to implement due to the lack of standards and measures. The open-source innovation model may provide some relief in this respect because the greater involvement of external developers can help improve overall quality. On the other hand, however, open-source projects are hard to manage for the same reason. Since open-source projects are self-directed and not owned by anyone in particular, those projects sometimes suffer from uncontrolled, tumorlike growth.

Several of Deming’s deadly sins (Wren, 2005, p. 463) apply directly to the software industry. Most products are made from scratch rather than from components and there is little standardization in software organizations. Since software developers have a tendency to see their job as a craft they defy standards and procedures. In addition, the rather complex environment with its dynamic requirements and the push for meeting deadlines make it easy for practitioners to lose sight of quality improvements through the preparation of organizational standards. High turnover and individual performance measures continue to be industry practice, even though many scientists, such as Deming, have argued for long that such measures are counterproductive.

Future managers need to find ways to compensate for the high turnover, if they cannot find a way to avoid it. The division of labor might work well for the company but it is not well perceived by the workforce which tends to require constant challenge. Top performers disfavor mundane tasks and prefer to walk away with all their knowledge. IBM has successfully deployed job enlargement for some time to combat this phenomenon (Wren, 2005, p.332). Unfortunately, this strategy might not work for every company and it can only be used within certain boundaries of the organization. Given the developments of the last two decades, managers will need to confront the discipline of knowledge worker management and find a workable solution for their organization.

The integration of management science with the advances in psychology and sociology may provide a route towards the solution of the knowledge worker management problem. It is crucial for managers to have an accurate understanding of the motivational drives for this particular group of the workforce. These employees enjoy higher income, greater flexibility and freedom, and greater bargain power. This puts them in a gray zone between the traditional, lower skilled employee and an owner in the company because knowledge workers create intellectual capital in the company. Because most of this capital is lost and remains with the employees when they decide to leave the organization, turnover can be much more damaging than with traditional workers. Managers can therefore not simply apply conventional strategies to this dissimilar group of employees; rather, they need to seek for more creative incentives for motivating and retaining knowledge workers.