When software developers gather, wherever they gather, one of the common subjects of discussion is productivity of software development. Why is this? It is not because there are many answers, but because there are more questions than answers. What does this term, "productivity" of software development really mean?
For some, productivity is "the ability to create a quality software product in a limited period with limited resources." (Arthur, 1983) This idea of constrained production is repeated by many authors. According to Arthur, "productivity, quality, and software measurement are intimately connected." (Arthur, 1983)
This interconnection between quality, time, and product, all delivered within a constrained budget is a reality we face. The problem we face is one of making the best out of what we have; being as productive as possible within the constraints imposed. Furthermore, these constraints are not stable across development efforts and environments.
In order to better understand the problem, in this paper I will first break down the different constraints by category, analyzing each constraint individually with respect to programmer productivity. Different measurement techniques, with their implications and problems will be presented. In conclusion I will present a model which will allow us to perceive the problem of managing programmer productivity in a new light.
In order to fully understand and manage programmer productivity, it must be realized that there are controllable constraints on the programmer from five distinct categories: Financial Constraints, Time Constraints, Software Specifications, Programming Methodology, and Corporate Environment.
Of course, the programmer is the one who is productive or unproductive. The exclusion of the programmer from these categories is due to the fact that programming style and ability is not something that goes with any one specific project, but rather is something which is learned over time, and must be dealt with as a separate issue. Programming style is very dependent on the programming environment, and the requirements this places on the programmer.
We must also note that there are uncontrollable (or slightly controllable) factors which will be discussed as a part of the whole issue of productivity of software development. We will discuss these issues also, pointing out how they affect productivity and what, if anything, can be done to manage the situation they create.
It must be noted that some constraints are constant across time, from the inception of the project to its end, while others can vary over time. Clearly there is some overlap between these categories, and some assignment of constraints into a category may be arbitrary. We cannot, given the time and space limitations, be exhaustive in each category, but merely indicative.
FINANCIAL CONSTRAINTS
Financial constraints are not necessarily only the money allocated to the development of the specific project. Many financial decisions made before, during, and after the development process significantly affect productivity of software development. Development is only the beginning, and we must look at the entire life of the software, including future maintenance and enhancements.
The Dollar Amount which is allocated to a specific project may enhance or detract from programmer productivity for that project. It is known that individuals who feel underpaid, in whatever profession, have a tendency to be looking for other employment. This cannot be conducive to enhanced productivity. On the other hand, when a low-paid programmer sees the possibility of promotion depending on good performance, he or she may put forth extra effort to be productive.
It is also clear that more Experienced Programmers tend to be more productive than less experienced programmers, yet they are also significantly more expensive. In certain cases it is better to pay more for better quality, while in other cases the extra cost for experience is not justified by the productivity gained. Other constraints may dictate a decision on this matter.
Another financial constraint is the Availability of Computer Resources. In a study by Thadani it was found that a decrease in response time from 2.2 seconds to .8 seconds increased programmer interaction by 60 percent, programmer output increased by 58 percent, and the code quality improved by more than a factor of two. (Thadani, 1984)
Finally, the availability of different Programming Tools and Resources can increase productivity. A development environment in which funds are available for things such as training, pre-developed libraries, seminars, etc. is more productive than one which is constrained to work without these tools. Programmer training should be an integral part of all software development efforts.
TIME CONSTRAINTS
Most software development projects are set up to be developed within a specific time framework. Not only must the budget be met, but also the project must be Finished on Time.
In general we must realize that a project is normally undertaken to meet specific needs. These needs can be either to satisfy a software development contract or to fulfill the business needs of the developing organization. Any delay can be costly in uncollected payments or lost productivity in other areas of the organization.
It must be noted that in order to meet time constraints it is not always possible or helpful to add programmers to the software development project, even when funds are available. If additional programmers are added in the expectation of reducing the development time proportionately, we may be disappointed. Time and people are truly interchangeable only when two conditions are met: (1) the task can be easily partitioned among all workers without changing overall effort, and (2) there is no communication or interface requirements between workers. (Mendelson, 1990) On the other hand, a project which is projected over too long a timeframe is not conducive to programmer productivity.
SOFTWARE SPECIFICATIONS
Much has been said about the effects of systems analysis and design on the development process. It is clear that a better analysis before the programming certainly helps the process. When major adjustments and/or adaptations must be done before completion of the development cycle, the effort necessary generally increases significantly, and therefore the cost and the time increase also.
Computer-Aided Software Engineering (CASE) tools can today be used to enhance the quality and speed of the systems analysis and software specification process. With CASE it is generally possible to have a more accurate representation and understanding of the software requirements before beginning the actual software development process.
Sometimes a system to be developed must be portable, that is, able to be transferred across different hardware and software platforms. When Portability is a requirement, many times the developer is restricted to specific methodologies and languages, with certain tools suddenly unavailable. This requirement generally decreases productivity significantly.
Within software specifications we also speak of Efficiency, generally measured in terms of response time or execution speed. This time or speed is dependent on the equipment configuration used. Efficiency will never increase productivity, and may be significantly detrimental to it.
One last specification which may decrease productivity is the required Flexibility. Flexibility is the ability of the system to be quickly and easily reconfigured, such as the case of a general ledger system, which needs to be able to be adapted to differing charts of accounts. Flexible systems will take more effort to develop than rigid systems. The question is: how much more effort? Sure, added flexibility is nice, but is it worth the extra work?
PROGRAMMING METHODOLOGY
Programming methodology is one aspect which has evolved significantly since programming's beginning. It is probably the single most important single factor in programmer productivity. Different facets of programming methodology influence productivity significantly.
Programming language is consequential in that different languages exhibit different functionality for the same number of instructions. At the same time, it has been noted that the number of source instructions written per unit of time is approximately the same across different languages. (Dreger, 1989) This difference is especially significant between language generations. It should also be noted that it is much easier to find an error in the fewer source instructions that a higher level language has. On the other hand, it should be noted that higher language generations (4th vs. 3rd.) generally require more hardware resources for equal performance than lower level languages. This means that additional computing equipment may be necessary, incurring additional costs.
Structured Programming is a technique which has been developed over time as a tool for enhanced programmer productivity. Structured programming means programming in a way which eliminates jumps by restricting modules to a single input and output sequence. The productivity gains achieved through this technique have been thoroughly documented. While significant gains are possible, they are not always attained, due to lack of understanding of the technique on the part of the programmer. Also, it has been noted that modular programs are generally more resource intensive, and harder to develop the first time. It does, however, allow for code reuse and subsequent increased productivity.
Recent advances in object-oriented programming, such as the arrival of object-oriented programming environments, have been said to increase productivity significantly. The object-oriented paradigm requires that the system developer have a good understanding of how object-orientation operates. Lack of understanding may lead to less productivity than a technique such as modular programming. There is as yet no large body of knowledge, but all factors seem to point to productivity increases of 200% to 500% (Korson, 1992)
Program generators and Computer-Aided Software Engineering (CASE) are two areas which have been mentioned as giving additional productivity gains. These tools have been demonstrated to increase programmer output over time, but there is a significant learning curve (Kauffman, 1991). It is not necessarily true that beginning to work with a CASE tool or program generator will immediately increase productivity. Because of the general application nature of both CASE tools and program generators, applications developed with these tools tend to have additional overhead not associated with direct coding.
If Prototyping is used, the main advantage is that a less than ideal design is more likely to be detected before the completion of the project. By repeatedly having a mode working for the user, user satisfaction and program correctness are maximized. On the other hand, since changes are made regularly, these changes do take time and effort, and will decrease the net productivity of the programmer.
Maintainability and Upgradeability are factors which many have considered important to productivity, since productivity should be measured not only for the development effort, but for the life cycle of the software. Developing applications which are more maintainable and upgradeable is more difficult than developing an application on which only error correction will be performed. Additional time is needed for comments and formatting in order to allow for ease of reading and modification (if and when necessary).
Defect detection and removal accounts for a significant portion of the total effort in any software development process. The methodology used for detecting and removing defects (incorrect code or incorrect logic) has been demonstrated to make significant difference in the effort expended to achieve the desired results. The programming language chosen affects this directly.
CORPORATE ENVIRONMENT
There are many factors of the corporate environment which affect programming productivity. Some of these are easy to define and manage, while other are more difficult to deal with.
The Organizational Structure, for example, affects programming productivity. It has been noted by Brooks that "the principle that no man can serve two masters dictates that the authority structure be tree-like" (Brooks, 1975). When matrix structures are used, and each programmer (developer) has more than one superior, problems with chain of command can cause significant delays due to conflicting requirements.
Geographic location of individuals involved in the development process is also a significant factor. Whenever communication is necessary between persons, it is better that this communication be as easy as possible. We must note that geographic distance does not only refer to large distances, such as across the country, but also to distances even within a corporate headquarters building. With today's technology the distance factor is becoming less and less important. The advent of electronic messaging and conferencing is making even Tele-commuting a possibility for some developers.
Internal Politics many times take their toll on productivity. Sometimes the effect is direct, as the programmer expends time and effort towards some political goal. Many times, however, the cost to productivity is indirect, with a programmer "sabotaging" the development process by different means such as delays, "errors", "sick time", etc.
UNCONTROLLABLE OR LESS THAN CONTROLLABLE CONSTRAINTS
There are many constraints imposed on a project which the project manager has little or no control over. These constraints are not necessarily to be managed, but merely to be accounted for in the development process.
Organization Size is one factor which cannot be changed whatsoever by the project manager or the programmer. This factor can be an advantage or a disadvantage. When change is desired, larger organization size is generally a negative factor, while when additional resources are needed, it is possible for a larger organization to make these resources available.
The Physical Facilities allotted to the MIS (or EDP) department are generally made available as a block, regardless of the projects to be done. It is up to the MIS manager to determine the space given to each project. However, generally space is allocated not on the basis of projects, but on an individual basis. It is clear that a more comfortable (ergonomic) environment generally enhances productivity. This is not something that changes generally from one project to the next.
Legal constraints affecting copyright, look-and-feel, and patents must be taken into account. Program Size must also be taken into account, with the Complexity that is demanded.
The Newness of the Concept is another important factor. When a "new" payroll system is to be developed, the developer is commonly aware of the basic concepts of it. On the other hand, a project relating to some esoteric, unknown (to the developer) field, is much more difficult to conceptualize, and will naturally demand an extra effort to complete.
One last factor which must be taken into account is Team Morale. While a team manager may have a certain degree of control over morale, it should be noted that many times a manager is given a team to work with, and does not have the choice of a team for that specific project. Interpersonal rivalries, with their side-effects can be detrimental to productivity. On the other hand, a team which works well together, and has many years of experience, will have noticeably greater productivity.
MEASUREMENT TECHNIQUES
In today's business environment, there are three basic measurement techniques for programmer productivity: (1) Lines of Code (LOC), (2) Function Points (FPs), and (3) Object Points (OPs). We will also discuss the measurement of project complexity.
LINES OF CODE
Lines of Code is the oldest metric available. It has been developed since the mid 1970's, but is not very precise. Clearly, a statement such as MyVar=YourVar+1 is a line of code. But what about other statements, such as DECLARE, BEGIN, DEFINE, and comments? Each of these statements is necessary. Are we to count or ignore them? If we ignore comments, and module structure lines, are we going to find programmers putting in the time to insert these as required, or will they just skip them, saying "they don't count, anyway"? Also, what about general purpose modules to be inserted into a library of routines? It is more difficult to write these routines, but how is one to determine how much more difficult? Just because a given programmer reuses more of his or her code, should he or she be penalized in the evaluation even though the functionality obtained was greater that that of someone who produced more lines of code? What of the programmer who must write assembly code, while his or her colleagues write in a 4th generation language?
Clearly, the LOC metric in its most basic form is very easy to measure. The question a manager needs to ask is: is it what I really want? In certain cases it may be what is desired, in others clearly not. Whatever the case, LOC metrics are not necessarily as easy to implement as the term implies.
FUNCTION POINTS
Function Points were first described by Albrecht (Albrecht, 1979), and have since been accepted by much of the software development community. The basic idea is that LOC are not measured, but rather the functionality of the developed program. This clearly removes the numeric advantage or disadvantage of the programming language. Some languages take longer to achieve the same functionality, but run faster and are more portable. Function Points still do not address the problems of internal documentation (DECLAREs, COMMENTs, etc.) in the software itself.
OBJECT POINTS
Object Points theory, recently presented by Kauffman (Kauffman, 1991), is very similar to function points in that LOC metrics are totally ignored. Also, it counts functionality, not in the traditional sense, but in number of objects, adjusted for difficulty and environment. This methodology is not currently widespread, but if object-oriented programming becomes more popular, may become more pervasive.
PROJECT COMPLEXITY
Measuring Project Complexity is one of the hardest things to do. This is an attempt to measure complexity across all constraints. In the intermediate COCOMO model, developed by Barry Boehm (Boehm, 1981), we find fifteen factors which affect complexity.
Previously in this paper we have identified many factors which influence programmer productivity, which could be used to determine the complexity of the software development process.
The question remains, can complexity be effectively be measured as one factor, which can then be used to modify the ex ante effort estimation, or do we need to develop a better methodology?
It is my belief that managing the productivity of software development
should be looked at as an optimization problem, with six dimensions:
Financial Constraints, Time Constraints, Software Specifications,
Programming Methodology, Corporate Environment, and Uncontrollable
Elements. A summary of the different constraints is presented
in Table 1.
| Financial Constraints | Budget
Salaries Availability of Computer Resources Availability of Programming Tools and Resources |
| Time Constraints | Time to Completion
Cost of Delay Limited Programmers |
| Software Specifications | CASE
Portability Efficiency Flexibility |
| Programming Methodology | Programming Language
Structured Programming Object-Oriented Programming Program Generators Prototyping Maintainability and Upgradeability Commenting and Formatting Defect Detection and Removal Techniques |
| Corporate Environment | Organizational Structure
Geographic Location Internal Politics |
| Uncontrollable Environment | Organizational Size
Physical Facilities Legal Constraints Program Size Program Complexity Newness of Program Concept Team Morale |
In order for this model to be effective, these constraints must
be understood and evaluated. In most instances some factors may
not be relevant, and some factors seem to be mutually exclusive,
such as structured vs. object-oriented programming. This should
not stop us from analyzing the situation, and defining which elements
relate to the software development process to be undertaken. Even
though these constraints are not necessarily easy to quantify,
I believe that a software project manager who takes them into
account will be able to significantly improve programmer productivity.