Increasing software productivitv

Y

P roductivity should be measured in terms of real effects on high- level management goals of a

business or an institution. Any attempt to measure productivity by other, more indirect, measures such as ‘volume of work produced’ should be recognized as less useful although these have a place when they provide some insight and control over the pro- ductivity question in early stages or at a low cost of measurement.

Productivity should ultimately be measured by the net effect of a solution on results. This means that the cost of developing and operating the solution must be accounted for in both the short and long term. This also implies tha; all side effects of the solution be fully accounted for.

Productivity planning must be car- ried out at a high management level in order to guarantee the relevance of the solutions to management objectives. The productivity goals are multi- dimensional and complex, but they can be written down, agreed upon, and expressed in clear measurable forms.

The tools for improving software people productivity are many. They can be implemented immediately to an interesting degree, and then streng-

Abstract: Productivity is more than just producing more software. It should be measured as the net effect of a solution on results, by evaluating not only the product but its effect on users. Productivity of management and professionals can be improved by changingmethods. Greater control should be exercised over a project before programming commences.

Keyworals: data processing, management techniques, systems analysis.

Tom Gilb is a management consultant.

thened by a long-term evolutionary series of changes and improvements, each of which is based on continual management monitoring of productiv- ity results up to that point.

Most of the really important pro- ductivity improvement techniques are managerial and not technical in na- ture, concludes Horst Remus of IBM in a recent paper’. I would agree with this assertion.

Results, not products

Software producers deliver their pro- ductivity to their ultimate client through the intermediary of ‘soft- ware’. It is not the software itself which is productive. The interesting results are made by people who make use of the software.

Software is often narrowly inter- preted as logic or algorithms for a com- puter to interpret. In my view, ‘soft- ware’ encompasses all ‘nonhardware’ areas such as:

0 logicware (computer program logic) l dataware (computer readable files

and databases) l peopleware (plans and methods for

organizing people to make use of the system)

l reader-ware (written documents for people’s use and instruction in learning and using the system)

I realize that this broad definition of ‘software’ is not conventional, and may cause some controversy. But it is quite clear from practical experience

by TOM GILB

that the people now producing soft- ware have some responsibility in all these areas.

It is also clear that the narrow view of the task, that logicware is the prim- ary thing, leads directly to poor solu- tions for the system user, and thus to failure to give real productivity to that user.

It may be difficult for software craftspeople to think in terms of the final results of the product. So in soft- ware building we need:

infotects (high-level system architects for information systems) software engineers (who are more specialized than infotects in design- ing dataware, logicware and other software aspects)

further need is for a business analyst, who would make a more well- reasoned case for using computers, or for solving problems by alternative means.

A US bank had begun a project with 12 programmers to convert a service bureau application to the bank’s own computer. The project would have lasted two or three years, they esti- mated. The solution to this problem was actually made by using one hour to renew the contract with the service bureau at the old prices for another five years.

The real problem was to control operational cost of the application, but because of the lack of a business analyst function, the wrong solution (rebuilding the software) was selected

Productivity must include the idea of producing software which has a long useful and economic life in the widest practical user

community

16 0011J584x/83/070016-05$03.00 0 1983 Butterworth &Co (Publishers) Ltd. data processing

by default. The pr~uctjv~ty differ- ence here was 30 work years saved for one hour of contract renewal effort! Yet the original question asked of me was ‘How can we improve productiv- ity of our pr~r~mers for this pro- ject?

Evaluating the product

Software products can be evaluated at two mairi levels. The most ~m~rtant level is the result for the user level.

There are, however, many product characteristics which will contribute to user results. And, at certain stages of software production it is quite valid to specify exactly what those product characteristics are, and to measure whether we are getting them or not.

These different effects of a product can be distinguished by using the con- cepts of

* ~~g~-~e~e~ cbaracterjstjcs (those which are nearer the interests of the final user>

l l~~-~e~e~ characteristics (those which are needed to give the high- level characteristics, and those which are of concern to the software producer, but not usuafly directly to the software consumer)

Software characteristics have two main categories:

* functions (what the software will do for users)

l attributes (how well the functions will be done for the user).

Arr~~~~~~ themselves fall into two main categories

l qualities (‘good things” like reliabii- ity, user-friendliness and security)

l resources (costs of building, maintenance and operation of the system, in terms of money, time, people-work and physical resources like office space and computers)

All attributes Gre measurable although they are usually seen as more difficult to measure than functions. Yet the attributes are, if any~~g~ more critic- al to software success than function.

~0125 no 7 September 1983

They must be controlled at all stages of design, constructjn~ and operation. Otherwise the software product will disintegrate and become too costly and impractical to survive in the real world.

Pr~uct~v~~ must indude the idea of producing software which has a fang useful and economic life in the widest practical user community. To do that requires attribute control, yet the greatest emphasis thus far in software development methods has been in functional characteristic control. The failure of any software can invariably be traced to a failure in one or more of its attributes.

Evaluating the effect of the soft- ware on the users

Some basic suggestions regarding measuring software effects on the soft- ware user would be: * The users themselves should be the

final judge of success, not the pru- ducers. Software systems need to be judged on a continuous basis, throughout their lifetime; not just with the first user, the first month, Software systems should have for- mally defined acceptance test criteria for all critical qualities, ap- plicable at all times.

The intention is ta measure the true user-productivity of the software pro- duct, in all important areas, through- out its lifetime.

Users sound judge s~~~~re One of the healthiest user measure- ment situations I have seen was im- plemented in the Iargest Australian in- dustrial corporation BHP from 1972.

The users seemed to hold total pow- er over the DP software producers. After nine years of unp~~tab~e and u~res~nsive DP development in the corporation, top management stepped in and introduced a user-controli~d pro~tab~~ty measure of the value of any programmed application.

The result was that the ‘academics’ fled, and the survivors became drama-

tically more responsive to users’ needs. The basic mechanism was a con- tinuous application-lifetime budgeting and accounting system which com- pared a user-set application ‘value’ (in real savings or productivity increases) to the real current costs of running the app~~cat~on~

Projecrs which fell below a mini- mum set level of profitability were first given time to improve the ratio, but if this was impossible, they were quickly thrown out entirely.

The net result in the first year was that in spite of a feared and budgeted loss of several hundred thousands of dollars, the actual result was a clear profit for the surviving DP applica- tions of several hundred thousand dof- lars.

Nobody in BHP was worried about producing lines of code, The entire surviving data processing staff (600 people) had only two ques~ons in their minds about all projects, at all times:

* how can we keep the costs down as low as possible?

* how can we make the application so usefuf in terms of user cost saving and user productivity (more steel plant productive capacity, for ex- ample) that the user management will give our application a high dol- lar rating, to keep it alive? Even though the user estimated value would be partly charged to that us- er’s profit centre budget.

~o~ti~~u~ ~o~~to~~g The BHP pro~tabili~ measurement system mentioned above was a con- tinuous, monthly, quarterly and year- ly evaluation process.

There is every reason to make this principle a general rule for software measurement, because

system Costs change in time maintenance action might degrade performance and quality in time the user environment is changing and what was of value last month might be of far less value today m~gement personalities chafes and with it the style, and thus the

17

value of particular applications

We must have a mechanism, as sensi- tive as our financial accounting proce- dures, for getting early warning of the decay of an application value. We must avoid using our resources (people, machines, management time) waste- fully on unprofitable or dying systems, when we could be applying them to profitable and future-oriented sys- tems. We must have a means of detect- ing the moment when applications are becoming less productive for our com- pany, so that we can either tune them to the realities of our environment, or kill them so as to free resources for more productive work.

Formal acceptance test procedure for software applications All critical criteria for ensuring the survival of the software system should be formally identified, agreed upon, architectured into the system, and be easily measurable at any time.

This does require some work, like any form of management control. But that is no excuse for avoiding this type of formal control. We are not speaking of a luxury. We are speaking of mak- ing investments profitable, and of en- suring that software systems which en- sure company profitability or useful- ness are really doing their jobs at all times. We are speaking about a man- agement minimum for survival.

The ‘technologists’ are not going to do this. Management must decide on this course of action (formal measure- ment of all critical software criteria). Management must initiate the state- ment of such requirements, manage- ment must give clear signals in their language about the interesting criteria to measure, and management must make a final (signed) approval of the critical criteria for any system. There is no need to use technical jargon here. That is reserved for the more detailed technical criteria needed to support the management requirements.

A page or more with about a dozen critical measures of software success, approved by management, will keep

18

the software producers pointed in the relevant direction. My experience is that such a clear measurable statement of management goals is today a rare item anywhere internationally. Most critical goals are simply not stated in measurable form with a clear quan- tified level of ambition. It is more com- mon to see goals of the type ‘greater productivity’, rather than ‘minimum 5% plant productivity improvement per year from next year’.

At a more technical level our soft- ware systems need to be designed with formal attention to the following basic survival parameters:

maintainability (with attention to the design of the 10 major sub- phases of this from problem recognition to recovery) portability (which if not designed into the software product, threatens its existence and causes unneces- sarily high conversion costs) user-friendliness (which for most large-scale traditional systems is at one tenth the productive levels it should be possible to achieve - re- sulting in high training and person- nel costs among large groups of em- ployees)

Most computer technologists today neither know how to specify measur- able levels of these attributes, nor how to systematically design a system to meet state-of-the-art levels. The re- cently emerged microsoftware world seems to be doing a better job in some of these areas than the large-scale pro- fessionals have ever thought or dreamed of.

The secret of the micro is more than its low hardware price. It is based on extreme user-friendly designs, ease of user modification (example VisiCalc) and a high degree of portability of ap- plications among various suppliers (for example CP/M, UCSD PASCAL and again VisiCalc).

Management productivity

Management, at all levels above the software technologist, can be im- proved by:

concentrating on determining user requirements identifying user requirements which will vary greatly in time due to unforeseen forces (and which, therefore, must be flexibly catered for by the system architecture) creating an organization which is totally user-result-oriented, even at the last technical level implementing measurement sys- tems relating all work to software user value and cost concepts filtering user needs through compe- tent business analysts, infotects and software engineers, rather than let- ting user needs get into the hands of technical ‘experts’ too early providing users with the power to do a maximum of their own ‘soft- ware development’ using very high- level languages such as VisiCalc and TK!-Solver, using table driven sys- tems, by teaching them to buy soft- ware at low risk, and by any other appropriate means.

Professional productivity

Business analyst

We need a much stronger interface be- tween the end user and the system con- structors. In particular we need some- one to evaluate requests for compute- rized services in a deeper way than a ‘programmer’ would.

This ‘business analyst’ should in- crease productivity by:

l avoiding computerization when other options are better

l making sure that the organization will be ready to make full use of a new computerized service.

This function operates at a higher level than most system analysts. A business analyst function must primarily ask ‘what is necessary and best for the business?’ with no presumption about writing programs.

The Infotect The ‘Infotect’ (high-level systems architect) can make an impressive con-

data tmcessine

tribution to real productivity simply because it is his/her job to design a system so that it meets the productive resources availabIe.

The infotect who can envisage several architectural solutions, can also choose the solution with the most suitable attributes. The infotect can, for example, choose the solution with the shortest implementation time (possibly a readymade package) or the least professional effort to irn~l~rne~t (possibly by making do with the old system on a faster machine) or the lowest Iong-term cost (by, for exam- ple, getting those costs guaranteed in a contract with a solid supplier of the service).

The infotect chooses the fun- damental information system strategy e.g. should it be on a microcomputer or on the corporate large-scale compu- ter?

In organi~tions where control of soft- ware quality or cost is important, there is room for another special function to follow the infotect, before program- ming starts.

The software engineer is a specialist in one or more detailed teclmologies, The software engineer will make such design decisions as file structure, Iogic- ware structures, software toois, testing and quaiity assurance procedures, and the organization of the production team.

The objective of the software en- gineer work will be to increase the pro- ductivity of the actual system produc- ers (the programmers and others like them) by making a set of design deci- sions, similar to those made by the infotect, but of a more detailed and technical nature.

In the absence of well-trained and organized business analyst, infotect and software engineer functions, these roles are taken, in a poor and informal way, by the unqual~ed programmer. In small or uncritical systems, the damage is slight and it is not worth the cost or effort to organize or employ

vol25 no 7 september 1983

these additional professional func- tions.

The I~~Fag~ method of system de- velopment quality control known as Inspection has great value as a general professiond productivity too12,

Far more than a mere ‘error finding’ tool, the Inspection method has been applied by IBM (in great depth for over 10 years) and others to the entire range of system development activi- ties,

These range from high-level goal re- quirements analysis to test case plan- ning activity. There are over a dozen points in the system development pro- cess which can make productive use of Inspection. Typical immediate net productivity benefits from a single point (such as program code) are in the range of 25% to 35%. Ex~eptio~~y high savings have been reported in test planing of 35% of test people effort’ and of maintenance productivity im- provements for error maintenance of 9W4.

Inspection acts as a sort of account- ing system for the effort and quality involved in system development. It allows management long-term insights into weaknesses and methods of im- provement. Inspection can be effective at the earliest stages of system design, where over half of all the errors occur, and where the cost of fixing an error is one or more orders of magnitude lower than it wilf be if the same defect is allowed to continue living within the system design.

E~~~~~~~~g the p~~f~~~iQn~~

Of course, the surest path to profes- sional produ~tivit~~problem solving is to eliminate the need for these profes- sionals within your own organization. Wowever, this simply increases the need for competent professionals in those orga~zatio~s which finally do provide the packaged solutions which we buy. The problem and the solu- tions I have discussed above continue to be necessary.

Most of the pr~uc~vity tools offered by the traditional ~dust~ have failed to deliver real net user result produc- tivity in a WelId~umented way,

These include database, data die- tionary, structured programming and the many variants of programming languages which seem to have in- creased overheads and specialization. They seem to have made responsive- ness to users’ real needs even worse than before.

It is perhaps most useful to contrast traditional data processing with the world of the microcomputer and the software tools of the VisiCalc class. Real users, often at high-impact execu- tive levels, seem to be producing use- ful results for themselves without any of the traditional tools,

I suggest that the productivity tools for really giving results to users are just emerging in the marketplace, and that they have little or nothing to do with traditio~ai data processing concepts.

Productivity methods are managerial in nature, and all of them support the following overall method:

* build or get the user what the user needs, to produce ef~~iently

+ let the user serve their own produc- tivity needs, but give them clear goals from management as guidance

Aiready mentioned as relevant methods are:

q~a~t~ed multidimensional goal setting (so that the concept of pro- ductivity is clearly understood and controllable) quality control and a~~ount~g pro- cedures such as Fagan, which apply to all work processes which produce documentation for human con- sumption during system develop- ment.

Other pr~u~tivity methods are:

* The collection of long-term, multi- project experience with tools and methods, such as is practiced by

IBM Federal Systems Division’. Only by careful long-term studies of this kind can we transfer individual insights on productive methods to future system developers and users. The use of chessboard-like ‘techno- scopes’ for analyzing proposed de- sign and solutions. These tools must allow us to operate at varied levels of detail, and to keep our attention focused on the user result goal@. The most powerful single method for producing user-oriented results in a controlled and early manner is by using a method which I call ‘evo- lutionary delivery’.

EVO-planning is still a foreign plan- ning discipline for both managers and planners today. One reason is that the way of plarming the steps is quite differ- ent from traditional phased planning. Instead of asking ‘how much can we do in phase one?‘, EVO-planning asks the ‘small is beautiful’ question instead:

How little effort can we spend to deliver a useful part of the future goals to the end user in the next change step?

There are some prerequisites for mak- ing this work well:

0 clearly specified final user goals l a total solution architecture (not in

l

detail, except in the immediate forthcoming steps) an open infotecture so that the solu- tion can grow from old to new and ‘unexpected’ changes will easily fit in; an architecture which ‘expects the unexpected’.

The results of using this method syste- matically seem almost unbelievable at first. Typically, we have regularly been able to deliver results to users in days, weeks or months, when conven- tional planning would expect to use years. This is accomplished by chang- ing the solution architecture (easy to say here, much more difficult to teach) to an architecture which can allow rapid quick steps in the direction of the user’s ultimate goals. No matter that those goals are constantly being mod-

ified; that is natural and we expect it. Then we simplify the entire solution

complexity by asking for the easiest changes (to the existing user environ- ment, which is our base) which give the user the most benefit. The user, of course, is working closely with us, rather than waiting for a three year project to be two years delayed. The user gets quick results, and can evalu- ate both development time and cost needed as well as the real value of the results. Perhaps even this simple ex- planation gives some insight in to why this method is ‘productive’ in the us- er’s sense of the term.

Harlan Mills of IBM’ cites the general experience of using the method for many years with projects never being late and typically cheaper than budgeted for (these are military/ space app~cations). He cites one pro- ject, the LAMPS (NAVY helicopter communications) project which was delivered in 45 increments to the user.

People productivity

Looking at the pr~ucti~ty of the pro- fessionals who develop and maintain computerized systems, several princi- ples can be described, which can also apply outside of the computer field.

First, the more precisely you can specify and measure your particular concept of productivity, the more like- ly you are to get practical and econo- mic control over it.

Second, productivity is a multi- dimensional problem. Several mea- sures of the concept may be necessary for realistic definition.

Productivity on technical projects is a managerial problem. If productivity is too low, the management is to blame.

Productivity definitions vary widely and must be tailored to the individual problem at hand. Real productivity is giving the end users what they require. Different system users will have different result priorities.

The most dramatic productivity im- provements result from radical change to the solution architecture, rather

than just working harder or more effectively.

You can design the solution to lit your available resources, instead of asking people involved to improve their productivity to meet the dead- line.

Frequent and early result measure- ments during development will pre- vent irrelevant production.

Early design quality control is at least an order of magnitude more pro- ductive than later system testing. This

The key to human productivity is in the system architecture, not

in the const~ction is because of the geometrically explo- sive costs of repairing the consequ- ences of design errors which are allowed to proliferate dough many development stages.

The key to human productivity is in the system architecture, not in the con- struction.

There will never be enough good profession~s available, so irrespective of the above principles of productiv- ity, you must have efficient selection rules for tasks, so that the most impor- tant ones get done first. References 1.

2.

3.

4.

5.

6.

7.

Remus, Horst Planning and Measuring Program Impl~enta~on, IBM Tech- nical Report TR 03.095 (June 1980). Also private conversation at NCC 1982. Fagan, M E Design and Code Inspec- tion to Reduce Errors in Program De- velopment, IBM Syst~~~~a~ voll5 no 3 (1976). Larson, R Test Plan and Test Case In- spection, IBM Technical Report TR 21.586 (April 4, 1975). Crossman, T Some Experiences in the Use of Inspection Teams in Appiica- tions D~veiopment, ~u~e/Share Ap pticutims ~~e~o~ S~~Q~U~ Pro- ceedings (Ott 1979). Felix, C P and WaIston, C E A Method of Programming Measurement and Estimation, IBM System Joumal vol 1 no 16 (1977) pp 54-73. Gilb, T Looking at problems through technoscopes, Data Processiplg ~0125 no 3 (April 1983). Mills, H E Principles of Software En- gineering, IBM System Jomal vol 19 no 4 (1980). q

20 data processing