Some Myths about Managing Software Development

INTRODUCTION

With widespread frustration over slipping schedules or outright runaway development projects, the dawning of a new millennium is an auspicious time to call into question the most basic assumptions regarding management of software development and adopt a strategy that reflects reality. This Section reviews and debunks these assumptions, outlines an alternate view that takes into account the quantum changes that have occurred in software development within the last decade, and positions managers to succeed into the future.

MYTH: REQUIREMENTS EXIST

That requirements exist is the fundamental assumption of all software development projects. At first they exist in the minds of the users, in documented form from which the design proceeds, and then form the basis for acceptance of the finished project.

As logical and hopeful as this may sound, it’s generally not proven true. Although users know what they want, it’s not unlike the Supreme Court' s understanding of pornography: they know it when they see it. Until then, requirements are inchoate: inarticulate needs that do not, of themselves, describe the features and functions that would satisfy them. What is widely attributed to scope creep, or the continuous expansion of the project requirements, is really just the natural process of distilling user needs into objective expression. E.g., a requirement for a banking application might be to maximize the profitability of each customer. Once understood, this requirement spawns new requirements: the need to maximize the number of services sold to a single customer, which leads to the need for a unified database of all customers and services, and relational access among them. Once the implementation begins, these requirements metamorphose into yet more: users realize that what appear to be many separate customers and accounts are often managed by a single individual, such as a parent creating trust accounts for children, and the requirement arises to define and associate subaccounts, followed by the need to present consolidated statements and reports … and so forth, and so on.

Therefore, if the project manager assumes the requirements can be expressed coherently and completely before development commences, and the entire project plan and schedule is based on that assumption, subsequent changes wreak havoc.

Scope creep, then, is really the inevitable realization that requirements are living, growing things that are discovered instead of defined.

Reality: Seek Problems, Not Solutions Instead of asking users to describe requirements and solutions, ask them to describe their problems. If this is a new system, find out why it’s being created - what is being done today and how will it change with the system? If this is a rewrite of an existing system, ask what is wrong with the old one. What problems will be solved? This is a radically different approach than asking for requirements. A commonly told illustration of this involves the building manager whose tenants complained about slow elevators. After rejecting a series of costly elevator upgrade or replacement scenarios, the manager hired a problem-solving expert.

This expert interrogated the manager. What was wrong with the elevators? The tenants, he said, were complaining about waiting for them. Why did that matter, the expert asked? Because if they are unhappy they may move out, the manager responded, and I may lose my job. The expert promised a solution.

The next day, mirrors were installed outside the elevators on all floors. The tenant complaints subsided. The expert explained: the tenants were complaining about waiting, not about the elevators. The solution was to make the wait more pleasant, and mirrors offer the most popular pastime of all: admiring ourselves. This solution, of course, cost a tiny fraction of the time and money to speed up the elevators.

The point is, if one focuses on the real problem, one will arrive at the best solution. If starting with a solution, the wrong problem may be solved.

MYTH: DESIGNS ARE DOCUMENTS

The next assumption proceeds from the first. If requirements can be captured and subdued into a static state, then the design can be based upon them and reduced to a written document from which development flows. This assumption fails not only because the first is flawed, but also for an independent reason. It’s difficult, if not impossible, to adequately express functionality in words and pictures. Software is interactive; documents are not.

There are at least two levels of interactivity of a design. The first is external, at the user interface level: what the user sees and does. A perfectly plausible screen design on paper may prove to be impractical when created. What appear to be trivial matters, such as using the mouse to position focus on a field or object, may render the application awkward and unworkable to a high-speed data entry clerk, trained in touch-typing, whose fingers never leave the keyboard.

The second level of interactivity is internal: the hardware platform, operating system, development language, database, network topology, and other decisions that affect how processing occurs and data is managed. An otherwise elegant database design may fail due to response time of the underlying network access protocol, or sheer volume demands.

Reality: Go with the Flow

Instead of expressing the design as a series of static artifacts - data elements, screens, files, reports - describe it in terms of business processes. What will the user do with it? Users don’t think about customer information databases or order entry screens.

They think about adding a new customer as the result of an order, answering customer questions about their orders, shipping the orders and sending out invoices, and making sure invoices are paid. They think in terms of processes, information, and workflow: they know their job.

Understanding the system as a set of processes as a user experiences it, beginning to end, will lead to a much different design than approaching the subject as a set of disparate entities. It forces the consideration of the flow and purpose of information -- not how it’s stored, but when and why it’s used.

Another important aspect of what is done is, how many and how often? Will there be 100 customers or one million? What happens most frequently - entering new customers or checking on orders? Are dozens of orders received daily, or thousands? These numbers will greatly influence the internal design of the system, including not just the amount of storage but the throughput rates. The external design is also affected: screens are designed to support the way they will be needed. Frequently needed information will be readily accessible, and high volume transactions streamlined for heads-down entry instead of heads-up aesthetics. Don’t ask the users what they want to see. Ask them what they need to do.

MYTH: DEVELOPMENT IS LINEAR

If the foundation of requirements was coherent and complete, and the structure of the design solid and stable, development would indeed be a simple, predictable matter. In the traditional, linear development life cycle, coding is a segment that begins after design and ends with test.

Yet everyone knows this is not how it is. Our budgets tell us so. Sixty to 80 percent of corporate IT budgets are consumed by maintenance, which is a euphemism for development on existing systems - systems that have already been " released," sometimes decades ago. There is not an application alive -- that is, being used - that does not experience constant development. Whether called modifications or enhancements, the fact is that 25 percent of even a so-called stable application undergoes revision each year.

This indicates that software systems reflect the business, and successful businesses are in a state of continuous change and improvement. Change can be a good thing, but only if it’s planned.

Reality: The Schedule Rules

Once ready to start creating the system, set a schedule that provides for the earliest possible release of the least possible amount of functionality. In other words, deliver the system before it’s ready. Don’t come up with the design and then the schedule:

come up with the schedule first and design as you go. Don’t target for error-free completion; attempt to have something that does something.

Sometimes called " time-boxing," this approach focuses on rapid-fire releases where the amount of functionality in a given release is based on the amount of time, not the other way around. One can think of this as rapid prototyping - it’s and it’s not.

Rapid prototyping usually means throwing together a mock-up that is used as a model for the real thing. Instead, this is the real thing, it’s just successively refined.

Today' s development technologies make it only incrementally more difficult to create a screen that works than one that does not.

In the early stages one might use a " toy" or personal database while nailing down the actual contents, then later shift to an industrial strength version when the tables settle down. The point is to get users to use it right away. The sooner they use it, the faster will be their feedback. Make sure everyone knows this is a moving target, and don’t get painted into any corners until necessary. Stay out of the critical path at first, and let the users report when it’s ready for prime time. Expect changes and problems and plan for them, which means not only releasing early but repeatedly.

MYTH: DEVELOPERS DEVELOP and TESTERS TEST

The mere fact that there is a title or job description of tester does not mean that testing is only done by testers. Quite the contrary: a major component of the test effort occurs in development.

The fact is, only the development organization has the knowledge and information essential for unit, integration, and system testing: testing the individual units, their interaction with each other, and their behavior as a whole. Developers are responsible for creating the software, and they not only should test it - they must . The assumption that only testers test is especially insidious, because it shifts responsibility for software quality to those least able to affect it. The testers are not there to check up on development; they are there to protect the business. When development operates under the assumption that they have a safety net, the odds are higher that the system will crash.

The real and only reason for having an independent test organization is to represent the users: not to assure that the software does not break, but that it does what the business needs.

Reality: From the End of the Line to the Front

In this new paradigm, testing moves from the last line of defense for development to the front line of defense for the business users. It changes from testing to make sure the software runs to making sure the business does. Developers test software; testers test business processes.

This means the test cases and conditions are derived from the processes that have replaced the requirements. Testers don’t verify that the order entry screen pull down list of items is sorted alphabetically; they try to enter 100 order s in an hour.

Granted, the sorting of the list may dramatically affect productivity if it’s not alphabetized, but the focus is on how well the job gets done, not how well the development was done. The design has no meaning outside of its purpose: to support the process.

In this scenario, testers are not baby programmers hoping to graduate to real development. They are expert users, making sure that the business needs are served. Developers are not creative, temperamental artistes; they are professionals delivering a working product. The purpose of testing is not to break the system, it’s to prove it.

MYTH: TESTERS DETERMINE QUALITY

Test organizations generally find themselves in an impossible position. They are asked to determine when or whether the software is " ready." This is impossible because the testers usually cannot control the quality of the software provided by development or the rate at which problems are corrected. They cannot control what end users expect of it or will do with it. To say that the schedule is out of their hands … well, that should go without saying.

The uncomfortable truth is that testers are often approached as impediments to release, as though they somehow stand in the way of getting the software out the door. This is a dangerous idea, because it puts testing in a no-win situation. If they find too many problems, the release to production is delayed; but if they don’t find enough, the release fails in production.

Reality: Ask, Do Not Tell

In the millennium, the business decides when the software is ready, based on what the test group discovers. The rolling release strategy provides for a constant flow of functionality, and the test organization' s role is to constantly measure and report the level of capability and stability of the software. However, it’s the business user' s decision when it’s acceptable. In other words, the user may elect to accept or waive known problems in order to obtain proven functions. This is a business decision, not a test criteria.

This does not absolve development from creating working product or test from performing a thorough analysis. It does mean that it’s not up to them to decide when it’s ready. This can work either way; the developers may be satisfied with a design that the users reject, or the users may decide they can live with some bugs that drive the testers up the wall.

The key is to remember that the system belongs to those who use it, not those who create it.

MYTH: RELEASES ARE FINAL

The initial release of an application is only the first of many, perhaps over decades.

Mission-critical applications are frequently revised monthly, if not more often, throughout their entire lives. The idea that everything the system will ever do must be in the first release is patently untrue.

This belief drives schedule slip: that one must hold up or delay the system because it does not do one thing or another, or because it has bugs. The truth is that it will never do everything and it will always be imperfect. The real question is whether it can provide value to the business today and, especially, in the future. Thus, a software release is not an event; it’s a process. It’s not a wall; it’s a step.

Reality: The Rolling Release

The concept of a release as a singular, monolithic and, often, monster event is an anachronism. Software that truly serves the business is flexible and responsive, supporting competitive agility and rapid problem resolution. Releases are like heartbeats: if they are not happening regularly, the system is dying.

Therefore, instead of a one-year development project with a vacuum after that, plan for four quarterly releases followed by monthly ones. During test, make weekly builds available. While this may sound like a pressure cooker, and using traditional methods it would be, it can be properly positioned as a safety valve.

Design defects are more easily corrected the earlier they are identified. Additionally, errors or inconsistencies are less annoying if they will be corrected in weeks instead of months. Emotion over missed requirements subsides considerably if they will be coming sooner rather than later. Value is perceived faster, and the potential for runaways is all but eliminated.

All of this, of course, drastically changes the nature of testing.

RECOMMENDATIONS

With a development process based on assumptions that are consistently demonstrated to be untrue, it’s no wonder one misses schedules and budgets. The answer, of course, is to throw out the existing process and define a new one based on reality.

The accelerating rate of new technology and techniques aimed at improving the development process can address the technical hurdles but not the organizational ones. In order for this rapid-fire, rolling release strategy to work, several things have to happen.

Code Speed

Although it sounds good to say that developers need to slow down and get it right, the fact is they need to speed up and get it perfect.

A case in point is the no longer simple process of creating a build, or executable. The build process involves assembling all of the individual components of an application and compiling them into a single, working whole that can be reproduced and installed as a unit. With the advent of component-based development, this is no mean feat. The build may encompass dozens, if not hundreds, of discrete modules, libraries, and files. As a result, the build can take days … if not weeks, or even months, to get it right.

In the time-box, rolling release world, builds are done no less than weekly. The only way for this to work, and work consistently, is for the code to be under tight management and control and for the build process to be strict and streamlined.

Speed has a way of burning off fat, and sloppy coding practices cannot survive the friction of this new model.

Standard Standards

Many development shops have adopted, documented, and published development standards, only to find them in useless repose, stored in binders, never to be referenced again. Without constant training, consistent code inspections, and other oversight practices, standards quickly fall by the wayside. To a developer, standards are straightjackets to be worn only unwillingly.

The new millennium won’t tolerate nonstandard practices for the simple reason that they won’t work. Delivering increments of functionality means that each succeeding layer must fit smoothly with the others: it’s like trying to build a brick wall - the bricks must be of uniform size and shape to keep it from falling over.

Not to be overly harsh, but maverick programmers won’t cause the organization to step up enforcement procedures; they will cause the organization to cull them out.

When running a tight train schedule, one does not coddle late passengers … one leaves them behind.

Owning Responsibility

Users, on the other hand, must step up to the plate and own the system being developed for them. No longer can the test organization serve as a staging area for new hires or misfits, following a random, spontaneous agenda that shifts with time and turnover. It must be an elite corps of experts who bring their professionalism to bear.

Nor can users hide behind the excuse that they are not technical and must rely on development to tell them how and what to do when. Nonsense. They must take the responsibility for articulating what they need, assuring that they get it, and deciding when to release it. They pay the price to have it developed; they will pay the price if it cannot be used.

SUMMARY

While no one questions that development technology is taking quantum leaps almost every day, few question the fact that our process for applying that technology can still be found in a 1940s textbook. This anomaly is crippling our ability to move into the next millennium, and must be exposed and removed. If something quits working, it needs to be fixed … or replaced.

==