13 Pains in My Software!
With Healthy Medications for Each

By Paul Newcum, MS, Ph.D.

Introduction

Do you believe that software development is just simply difficult and overruns are just part of the territory? Have you ever wondered if there are practical ways to make software development more "doable" while at the same time removing the stress of trying to achieve yet another software deadline? Much research has been expended to uncover the root causes of software development roadblocks and difficulties. Using Pareto analysis (sometimes called 80-20 analysis), 13 software pains are identified as the principal factors associated with software development difficulties, overruns, stress and burnout. Software development encounters these again and again, virtually without any meaningful corrective actions being applied in any particular project. Their plentiful prevalence is the chief groundwork for CIO (chief information officer) job loss that occurs on average about every 18 months, as well as the lower morale, staff burnout and employee turnover characteristically experienced in the information technology divisions, often revealed through debilitating IT politics.

By recognizing and dealing with each pain in a practical manner, the IT division will undoubtedly discover that senior management as well as key clients/users will become much more satisfied with their software projects and their IT people; and long-term relief should occur in the IT division as well, namely, less software development difficulties, overruns, burnout, more stable careers, happier staffs, and much more varied and interesting software development work.

1. Complexity

Reduce the "apparent" complexity of software projects through the liberal application of automated software organizing and defect discovering tools. Software tools are universally used to reduce the complexity and remove defects during the design and construction of complex tangible products such as electronic boards, automobiles and even space vehicles. Software developers may be happily amazed to discover that rugged sets of automated software development tools are now available to greatly reduce the complexity of designing and developing complex IT software as well.

2. Technical Jargon

Software designs and discussions habitually abound with technical jargon, but this has proven to be less than effective for clients/users of information technology; this is one of the most often voiced complaints from them. They want business-speak liberally used in their software discussions, requirements, design and software documents with the IT division. To solve this, prepare business-speak discussions and documents for clients/users, while storing the complex technical software requirements in automated software development tools, such as those described above.

3. Imprecise Specifications

A central truth about most software projects is that they proceed into the programming and the delivery stages without an explicitly clear, unambiguous, precise and consistent set of software specifications (including viable test scenarios that fully reflect these authenticated specifications); these are needed to drive the development work and to prove the validity of the deliverables. This failing can be conquered by:

1. Stating ALL client/user requirements and specifications in relatively brief English-Verb-oriented business-speak sentences.
2. ALL data-models and object-models must be formed in understandable business-speak expositions.
3. Preparing a non-programmed business-speak interactive prototype based upon the specifications captured in points 1 and 2, listed above.
4. Present these to the key and principal clients/users using business-speak throughout.
5. Obtain concurrence or revisions as the case may be until ALL are fully satisfied with these specifications and the prototype.
6. Translate these business-speak specifications and designs into truly technical counterparts.
7. Obtain a technical review by objective non-project-assigned personnel that this technical translation has been correct, complete and proper and that NO business-speak specifications, designs and prototypes were inadvertently corrupted along the way.
8. Utilize these specifications to drive the entire development work and ALL deliverables.
9. Constantly check and double-check that the development and deliverables totally adhere to these specifications all along the way.

4. No Prototypes

Software projects commonly do not prototype the design nor the programming for clients/users in the early phases of the project; instead the business functions are designed and developed afresh just for this particular software project, and then for the first time they are demonstrated to clients/users during the later development phases. By this time, due to the above mentioned impreciseness and inconsistent specifications, significant defects and errors will have been embedded in the newly developed software. Now at this late point in the project, clients/users will want to address and even remove these defects and errors; and of course, from their perspective, the developed software is merely a prototype for them, but for the software team it is the final software version that is heading out the door for delivery. What is required are up-front prototypes that fully display the business functions and capabilities of the software before any development or programming begins. Such prototypes can be constructed without programming by a variety of strong development tools now on the market.

5. No Re-usables

Software projects generally never build and then re-use macro design components nor macro programming components (macro components are those which are intended to be available for many, many projects thereafter). Even within the object-oriented paradigm, re-usable designs are not the intention, but the intention is to create some re-usable programming components strictly for use within this current project. Re-usable design and programming components can be built around generic business functions and systems which are already known, and which previously exist, and then when a new software project is initiated, much of the design and programming work will already have been completed and proven worthy to include in the new software project. This will reduce the design and programming work, as well as make the resulting re-usable components much more reliable than if they were developed one at a time, for each and every individual project.

6. No Costs and Schedules

Software projects prevalently do not prepare nor utilize realistic project costs and schedules based upon the agreed upon up-front prototypes discussed above, nor the actual costs and actual schedules of previously completed software projects which bear resemblance to the current software project. In fact, software projects often publish ambitious and oftentimes politically motivated schedules, which of course, will universally not be met; or if they are met, they will include a liberal dispersement of defects and errors since time was not allowed on the project to identify and remove them (this is confirmed by the BETA TESTING that occurs after the software is developed, which has the intention of finding and eliminating gross errors discovered in the software at this late point). However, reliable and believable project costs and schedules can be developed by utilizing a technique known as COCOMO (constructive cost model); this technique has been cast into several affordable software packages that are readily available. Using and constantly revising these will permit the software team to predict the true costs and schedules of the project.

7. New Paradigms

New paradigms enlarge the problems of defect and error creation and propagation. For instance, the object-oriented paradigm permits the "overloading" of multiple objects with the same object name. Thus more than one object can have the same name; and it is only by the context of the exact programming situation that a particular object can be differentiated from other objects with the same name. This adds to the complexity. To minimize the complexity inherent in new paradigms, development standards need to be created to assist the software team to adhere to simplistic and reliable design and programming constructs which have these extra complexities eliminated.

8. Deadlines

Research has uncovered that most software projects stress the necessity of meeting a pre-established and often politically motivated deadline delivery date; this incessant deadline pressure has proven to be a major contributor to the creation and propagation of defects and errors in software projects. Other research has shown that by carefully observing software quality practices, correct and vital business functions will be created in the software right from the start, and the project will remain at the predicted cost and within the predicted schedule throughout. Clients/users will be much more satisfied, and projects will actually cost far less since software re-work and major enhancements to correct initial deficiencies will be eliminated.

9. Not Removing Defects and Errors

Extensively, software projects do not concentrate upon detecting and eliminating defects and errors at the point of origin within the design nor within the programming. Seldom are "walk-throughs" performed in a consistent or regular fashion; developers universally have a bad taste in their mouths about "walk- throughs" because they usually devolve into politically-centered-favored-cliques which exclude valid work just because it is not "politically correct" in their eyes. In these cases, defects and errors are attempted to be removed after the fact by the quality assurance group during the testing phases. Actually, it is too late to adequately identify and remove all of the costly defects and errors that have been embedded in the software at the quality assurance and beta testing stages of the project. They can only be identified and removed in a low-cost, low-effort manner at the point of origin in the design and in the programming phases by:

1. Constantly checking the design and programming against the concise specifications mentioned above.
2. Initiating a practice of conducting objective in-depth "walk-throughs" with members who only have a focus on placing quality into the software.
3. Allowing an independent verification and validation team to inspect the design and programming for the purpose of identifying and eliminating defects and errors at the point of origin.

10. Quality Not Pursued

Quality in software is not pursued, and it is not even widely understood. For example, quality in software does not mean after-the-fact quality assurance testing nor beta testing endeavors. Quality in software does mean:

1. Speaking in business-speak and illustrating the new software functions through business-speak, up-front prototypes.
2. Correctly predicting the true costs and schedules through up-front COCOMO techniques.
3. Obtaining an A+ grade or better from the clients/users of the new software on the business functions and the extremely low defect and error rates encountered by them right from the start.
4. Building and using re-usable design and programming components.
5. Making software quality a viable business objective of the IT division.

These efforts will make work in the IT division much more interesting and far less stressful than heretofore.

11. Defects Installed

These are habitually installed in the design and the programming because of:

1. Deadline pressures.
2. Disinterest in identifying defects and errors at the point of origin; namely not consistently holding worthy "walk-throughs" throughout all development phases.
3. Placing all of the stress and interest upon removing the remaining bugs solely at the beta testing stage.

Senior corporate and IT management must place software quality into the mix as a viable business objective for the IT division to diligently pursue right from the very beginning as well as throughout the software project. In this manner, defects and errors will be regularly detected and eliminated at the point of origin, and well before they become truly costly to identify and remove from the software. IT people should be objectively and tangibly rewarded for achieving this kind of software quality.

12. Poor Functions

Due to the lack of focus upon software quality as a viable IT objective, as well as the universal importance placed upon meeting the pre-established software project deadline dates, initially poor and defect-ridden business functions are created and delivered to the clients/users.

13. No Measurements

Software projects do not measure the quantity and complexity of the function-points within the design and within the programming. If these measurements had occurred, then a realistic understanding of the amount of work, the complexity of the work and the probable costs and development schedules could be objectively calculated within a COCOMO (constructive cost model) spreadsheet. Additionally, past projects' design and programming function-points could be used to accurately calculate the current project's function-points, hence its costs and schedules. Software measurements are required, at the design stage and throughout the programming phases.

Paul Newcum was featured at DCI's Engineering Solutions Conference: From the Desktop to the Internet.