Beyond Code

Best Practices Gone Wrong

Introduction:

In Buddhist psychology, there exists the concept of the "Near Enemy". The "Far Enemy" of a healthy or beneficial state of mind is its direct opposite. For instance the Far Enemy of the peaceful mental state of equanimity would be anger or agitation. On the other hand, the Near Enemy of equanimity is indifference, a quiet, but negative state of mind, which does give a similar appearance, but at closer inspection does not have the same beneficial qualities. The Near Enemies are considered particularly pernicious, because they give misleading impressions of health and benefit.

In software engineering also, there exist look-alikes to some of the current Best Practices in software project management that have been recognized over the last ten to twenty years. As in the above 2500 year old example, these new "Near Enemies" put the projects they visit at particular risk, because the true state of affairs will not be recognized until it may be too late - in fact, the project stakeholders may think themselves safe in using modern, accepted practices, when in reality they are not actually employing them.

1) User Input

An early, throw-away GUI-prototype is one of the best ways to ensure that the software that is being built is an application that customers will actually want to use. The risks inherent in developing such a prototype are also well-known: the possibility that the throw-away prototype never gets thrown away (shudder!), and the risk that it turns into a semi-fledged technical application, which fails to offer the rapid turn-around times necessary for effective user interface prototyping.

Beyond these well-known risks in the technical domain, there are other, less tangible problems related to the content of the user input. There is a strong tendency for every statement a business domain expert makes to become "The Law" - after all, this demonstrates how seriously the customer's wishes are taken. The difficulties only become apparent much later, when in purely technical design sessions (without any customer representatives present) a specific requirement turns out to be exceedingly hard to model - in particular when the difficulty does not seem to be in balance with any perceivable benefit. In such cases, surprisingly often it turns out that the actual user's requirement had been misunderstood by the technical team: a miscommunication, which was never detected until late (possibly too late) in the project.

Another very real difficulty is that user input may be just plain wrong! The user may simply have been mistaken, or may have expressed a personal point of view, which is not representative of the targeted customer base, or the customer representative may not have been truly competent in the specific business domain. The latter is a particular problem in the not uncommon case that the customer representative comes from a Marketing or Management background.

For all the acknowledged benefit that customer involvement brings to a software project, the process is still widely mismanaged. The particular importance of the iterative approach towards customer requirements discovery has yet to be fully realized. The introduction of a feedback loop into this part of the project is essential because user input analysis is inherently a two-step process: in the first step, the actual user input is solicited, typically in joint sessions between members of the technical team and customer representatives. In the second step, the raw user input is translated into tangible concepts and firm language by the technical team alone. It is in this second step that the majority of translation errors creeps in. Therefore it is crucial to provide a feedback step, in which the customer is given the opportunity to verify the model which was created by the technical team.

Even when a basic feedback mechanism is in place, care must be taken to ensure its efficacy. Having several independent customer representatives provide input to the project prevents the outcome of the entire project to depend on a single person's views and preferences. Feedback loops must not be terminated too early or be invoked too late - it is still not uncommon to have a brief period of intense user involvement only at the very beginning of a project, and then again at the very end, for acceptance testing of the finished product (by which time it is definitely too late to incorporate any sort of feedback!).

2) Project Tracking through Regular Progress

Meetings The odds of a software project failing in one way or another are still worse than even. Progress visibility is therefore often an explicitly stated goal for new projects. The typical approach involves regular (often monthly) status tracking meetings by the project's supervisory board (often including various upper level managers, as well as representatives from marketing and other departments, but only a select few technical staff). Very rarely does this arrangement provide any meaningful control over the project.

First of all, status reports from the development team are too easily manipulated. (In fact, the total absence of Bad News from the development team should be taken as a critical warning sign by any project stakeholder!) Demonstrations of the product under development also can be manipulated too easily - in the worst case leading the development team to spend most of its time dressing the system up for the next customer demo, respectively cleaning the system up afterwards, without sufficient resources being left to drive the actual development effort forward.

The danger of status reports being manipulated is real, not because most developers intentionally try to mislead management, but because developers tend to be under double pressure to report good news: external pressure to finish the project, and the self-applied pressure to deliver. Furthermore, developers do not tend to be corporate fighters, in fact, they often have very nice, though slightly awkward personalities, with a strong desire to please everybody (occasional horrendous exceptions notwithstanding).

Status tracking can be made more efficient by providing a reference model to compare the actual status against. A detailed project plan, scheduling frequent (weekly or at most biweekly) tangible milestones in form of completed features can help considerably to assess the true status of the project. It can also help the development team, by laying out an easily followed road map and providing clear prioritization for the work to do. Finally, by managing the customer's expectations, it may reduce the pressure to dress the system up for dog-and-pony shows.

Of course, a project plan does not prevent manipulation of status reports, either. However, a credible plan, worked out by the project team itself, may give the developers increased support and credibility to stand up to external pressures, and can therefore help to preserve the overall level of integrity.

3) Deferred Release

Many projects take a staggered release approach, in which requirements analysis and architecture is done at the beginning, and the system is subsequently implemented and released in several stages. The primary advantage of this lifecycle model is that it permits to ship a working product earlier than when all the functionality would be delivered at once. It also reduces overall project risk by providing tangible signs of progress at several points along the way.

In the classic staged release cycle, the most important functionality is released first. However, many projects implement a seemingly innocuous variation of this lifecycle model: in the first release, all the functionality is implemented that is considered "easy", the actual core functionality is planned for the second release, and then there is usually a somewhat nebulous third release in the discussion, which will mop up everything that has been left out of the first two and also promises to include unspecified bells and whistles.

The success rate for these projects is not very high. In particular, when release 1 already runs into problems of one sort or another, there is a good chance that the second release (which was to realize the primary value to the customer, after all) will never ship - with the effect that the entire project will fail in the market place (since release 1 alone usually does not offer enough value to the customer to enable it to succeed by itself).

The primary mistake here is that the staged delivery model requires the most important functionality first - whereas the "Release 2" project ships it not first.

The following problems are inherent in the "Release 2" model:

• Since version 1 brings not enough value to the customer, the customer may go cold on the entire project.
• Since (often) all work on release 2 is deferred, it may not even be certain that release 2 is technically feasible.
• The actual killer app is delayed, giving competitors more of a chance to fill the targeted market niche.

• The project as well as the project team loose credibility when the first release (which, after all, was supposed to be "easy") is late - what does this say about the project team's capability to do the "hard" part?
• The same applies if the first release is sub-standard (often in a non-functional area, such as having an unpolished user interface, poor performance or stability), since there is not enough functionality in the application to compel users otherwise.
• Any corners cut in the attempt to ready the first version for release will come back with a vengeance during the second, more challenging release.

Since there simply is no way to stuff 10 pounds into a 5 pound sack, an alternative model is needed. If we accept as a premise that the most important functionality has to be delivered first (even when this proves a challenge), something else will have to give. One approach might be the attempt to cut as much of the non-critical functionality as possible (for instance in the area of user interface design).

Another approach would call for extensive technical prototyping early in the project, to get the "hard" part under control before anything else is done.

Finally, simple honesty might be called for. When the only valuable product that can be shipped is the one that combines releases 1 and 2, one has to realize that the cost for developing a shippable product is the cost for the development of both release 1 and 2! The attempt to spin out an earlier release as a shipping product is self-deceptive. Should the answer be that the initial investment to build both releases before a revenue stream can be generated is too high, this realization should be welcomed before any money has been spent on the development of release 1.

4) Feature Set Control and Change Management

In recognizing the importance to actively manage change over the course of the project, projects commonly define a change process at the beginning of the project - such as the level of formality for change requests, the assignment of responsibility to accept or reject such requests, and an escalation procedure, in case no decision can be reached. However, projects often fail to give enough attention to the most important issue for successful change management, namely the establishment of credible baselines against which change requests are generated.

This can go wrong in several ways. In particular in client/contractor relationships, there is a tendency towards detailed a-priori specification documents. Unfortunately, this suggests a project lifecycle based on the dreaded waterfall model and encourages unnecessarily legalistic stances between both parties exactly in the case when changes become necessary or desirable: The entire change management process can quickly deteriorate into antagonistic quibbles over "Who is at fault?", i.e. "Who pays?".

At the other extreme (and perversely sometimes on the same project) there is not enough emphasis on technical reviews of documents or work products before they are baselined. In these cases, the change management process turns into a belated technical audit - given that change boards tend to be staffed more by managerial than by technical people, the process again quickly deteriorates into highly acrimonious (and technically unproductive) political infighting.

In the end, change management is a question of trust: At the beginning of each project phase, all the project's stakeholders need to look one another in the eye and say: "Yes, verily, as of this day we agree that this document or work product is a true statement of our intent. We understand that there will be changes, but we understand that there will be a price to pay for any changes made after this point, and we will not take the decision to make such changes lightly!" With trustworthy project stakeholders that should lay a very good foundation for a reasonable change management process - with untrustworthy stakeholders, nothing will!

5) Software Development Infrastructure

For the purpose of this discussion, software development infrastructure means the tools and procedures that perform tasks such as source code control, the build process, and unit and regression testing. While a certain level of sophistication in this regard can be expected, and is clearly necessary for a development process of constant (daily) integration and testing, some projects spend an inappropriate amount of resources (time, effort, money) on these - resources which may not even be explicitly accounted for in the project's budget!

In such projects, it is commonly forgotten that development infrastructure improves the process, not the product (with the possible exception of testing frameworks, which actually can influence the quality of the product itself directly). Furthermore, the total cost of ownership of overly sophisticated project infrastructure can be remarkably high. It comprises not only the initial investment to build and install the selected tools, as well as training for all developers in their proper use, but also the cost to maintain these tools over the course of the project. Also, the more complex a tool or process is, the more expensive its maintenance tends to be. Furthermore, complex procedures may prove brittle in the face of changes, leading to increased rework, or may necessitate a considerable amount of additional planning effort at the very beginning of the project. Finally, overly complex processes may silently be abandoned by developers in favor of simple, yet sufficient ad-hoc methods, leading to wasted effort.

These costs are exacerbated by the fact that most of them tend to be hidden - few projects budget explicitly (and sufficiently) for activities such as infrastructure maintenance and training. Additionally, since development processes are typically not considered part of the work product, they tend to be particularly badly documented, making staff turn-over even more costly (since now other team members will have to advise the newcomer in the proper use of the tools).

Overly complex infrastructures also introduce entirely new risks into projects. For instance, all development work may be brought to a sudden, but complete standstill if the build tool fails (and its maintainer is unavailable).

Clearly, the appropriate level of sophistication depends on the size and complexity of the project - but more is not always better. Furthermore, it is extra important to budget for necessary activities in this area properly. Lastly, it is in the application and refinement of established processes that mature organizations stand to benefit particularly strongly from reuse.

Conclusion:

It has been said that small social groupings under extreme stress are able to rush through the three developmental phases that great civilizations usually require many millennia to establish. These three phases represent: the bare survival, intellectual curiosity, and the ultimate refinement, colloquially also known as the How-, Why-, and Where-phases. In software project management, we have successfully conquered the first: "How do I get this program to run?" and the second: "Why do software projects always fail?", and have happily arrived in the third: "Where did the resident business domain expert go now?".

Our understanding of the success factors influencing software projects is incomparably greater than even ten years ago. In consequence, our attention has shifted from the state of bare survival to the application of (at least potentially) relatively well-understood principles. However, it is in this fine- tuning stage that it is important to remember that better techniques by themselves cannot guarantee success, but rather that it is their effective and appropriate implementation in real-world situations which will deliver results.

Finally, a common thread in the on-going development of software project management techniques has been the continuous shift of attention to activities which are positioned ever higher upstream in the software project lifecycle. It has long been known that the classic "jump-to-code" approach to software development fails to deliver, and that preparational activities, such as requirements gathering and architecture, are necessities for successful software projects. However, many projects still fail (though relatively fewer than before). One reason is that instead of "jump-to-code" we now often seem to practice "jump-into-project". While the naive approach to simply start coding may work on a small, simple project, it often fails on even medium-sized projects. In the same way, simply starting with requirements gathering and architecture will work well enough on a project of medium complexity, but is a very risky approach to a large or complex project. Some of the Best Practices pitfalls outlined above are the direct result of short-changed activities in the pre-project phase. As the complexity of the average project rises, more and more time has to be spent ever further upstream, studying the feasibility and risks of the project.