Software Development Myths

We love to live with myths. In software development, there is no exception to it. It is true it often temporarily keeps us away from stress, but finally, it adds more stress to our life. It simply drags the development process, adds more rework and often becomes the single most reason for the premature death of the software project.

Myth 1: Early Specification Reduces Waste

When awarded a software project, we start playing games with our valued customers. We simply request them to define everything about the proposed software and sign off. And if he wants further changes, he has to go through an arduous process called “change management”. So we force the customer to tell everything initially and sign off to build a good software application.

Most customers can not tell what they want. In most cases, they do not know actually. As a result, the customer proposes unused features, which are the worst waste in software development.
And 2/3rd of the requirements fall in this category. But we develop these with top priority and care because the client has provided them. We continue to maintain it in the hope it may be used. But that future never becomes a reality. However, every bit of code there rather creates complexity that plagues the code base for the rest of its life. Unused code still requires unnecessary testing, documentation, and support. Finally, over time, we are forced to throw away these codes for maintenance after spending years on them.

Even we develop important features with wrong specifications. Because clients can never tell the detailed logic without seeing the software working. So the developers make their best guesses, which are often incorrect. Most of all, it takes months and sometimes years to deliver if we attempt to define full software in one go. By that time, even correctly defined requirements get changed. At launch, we are left almost with the wrong system.

We need a process that allows us to develop the 20 per cent of the code that will deliver 80 per cent of the value and only then go on to develop the following most essential features. We should never establish scope with a list of everything a system might need, especially if it comes from customers who don’t know what they want. However, we must keep an eye that the design and architecture are not a particular feature specific but a target to optimise the whole and accommodate future additions.

Myth 2: The Job of Testing Is to Find Defects

The job of tests, and those that develop and run tests, is to prevent defects, not to find them. A quality assurance organization should champion processes that build quality into the code from the start rather than test quality later.

This is not to say that verification is unnecessary. Final verification is a good idea. It’s just that finding defects should be the exception, not the rule, during verification. If verification routinely triggers test-and-fix cycles, then the development process is defective.

Research suggests that 80 per cent of the defects that seemed to be caused by people making mistakes were caused by a system that allowed the mistakes to happen. So the slogan “Do it right the first time” was coined. However, it is a dangerous myth to think that software should not have to be changed once it is written.

Let’s revisit the best opportunity to eliminate software development waste: Write less code. To write less code, we need to find 20 per cent of the code that will provide 80 per cent of the value and write that first. Then we add more features, stopping when the value of the following feature set is less than its cost. When adding new features, we must keep the code simple and clean, or complexity will soon overwhelm us. So we refactor the design to consider the new capability, keep the code base simple, and eliminate software’s worst enemy: duplication. This means that we should routinely expect to change existing code.

TDD (test-driven development) practice can help add quality built in. TDD test cases are requirement logics that may fail if not addressed. TDD test cases are written before and by the development team. So writing code and making the test pass is a side-by-side process for the developer. So code provides quality built-in. In the traditional waterfall process test team write test cases and throw the error in the defect tracking system. After that fixing, those errors add complexity to the codebase and attract future problems.

Myth 3: Predictions Create Predictability

Software development is notorious for being unpredictable, so there is tremendous pressure to make it more predictable. To do it, in most cases, we get the opposite effect. We create a plan and act on it as if it embodies an accurate prediction of the future. Because we assume that our predictions are facts, we tend to make early decisions that lock us into a course of action that is difficult to change. Thus, we lose our capability to respond to change when our predictions are inaccurate.

We forget that the predictions of the future are always going to be inaccurate if they are

1) complex,
2) detailed,
3) about the distant future, or
4) about an uncertain environment.

Any attempt to make accurate predictions is likely to fail. There are, however, well-proven ways to create reliable outcomes, even if we cannot start with accurate predictions. The idea is to stop acting as if our future predictions are facts rather than forecasts. Instead, we need to reduce our response time to respond correctly to events as they unfold.

To increase the predictability of outcomes, we need to decrease the amount of speculation that goes into making decisions. Decisions based on facts rather than forecasts produce the most predictable results. As a control engineer, Mary knows that an empirical control system based on feedback delivers more predictable results than a deterministic control system.

Myth4: Planning Is Commitment

Sometimes plans are useless, but planning is indispensable. Plans change very quickly. World affairs do not always go according to plan, and orders must change rapidly in response to circumstances. If one sticks to the idea that once set, a plan should not be changed; a business cannot exist for long.

It is said that the sturdier the human spine, the more quickly it bends. This elasticity is essential. If something goes wrong and the backbone is placed in a cast, this vital area gets stiff and stops functioning. Sticking to a plan once set up is like putting the human body in a cast. It is not healthy.

But there is a difference in planning and commitment. Plans can change quickly, but commitment does not. Let’s not succumb to the myth that planning is the same as committing. We should plan thoughtfully and commit sparingly.

Myth 5: Haste Makes Waste

If you want to go fast, you need to be engaged, thinking of people who can be trusted to make good decisions and help each other out. In fast-moving organizations, the work is structured so that the people doing the work know what to do without being told and are expected to solve problems and adapt to changes without permission. Lean organizations work to standards, but these standards exist because they embody the best current knowledge about doing a job. They form a baseline against which workers are expected to experiment to find better ways to do their job. Lean standards exist to be challenged and improved.

There are two ways to achieve high quality. You can slow down and be careful, or you can develop people who continually improve their processes, build quality into their product, and develop the capability to repeatedly and reliably respond to their customers many times faster than their competitors.

Myth 6: There Is One Best Way

There is no such thing as “one best way.” No process cannot be improved. To prove this to yourself, spend some time quietly watching people doing their work. After a while, you will notice many things that could be improved. Processes should be improved by the work team doing the job. They need the time, the charter, and the guidance to tackle their problems, one at a time, with the biggest problem first. This never-ending continuous improvement process should be found in every software development organization.

Myth 7: Optimize By Decomposition

We can’t measure everything, and because we have to limit our measurements, some things invariably fall between the cracks.30 We measure project performance based on cost, schedule, and scope targets. But these measurements don’t take quality and customer satisfaction into account. If a conflict arises, they lose out. So what should be done? The decomposition approach would add two more measurements, so now we measure cost, schedule, scope, quality, and customer satisfaction. Voila! We have turned the iron triangle into an iron pentagon. It may go on. It can't be a solution.

The solution is to “Measure UP”, raising the measurement by one level and decreasing the number of measurements. Find a higher-level measurement to drive the right results for the lower-level metrics and establish a basis for making trade-offs. In the example of project metrics above, instead of adding two more measurements, we should use a single measurement—the one thing that matters. Return on investment (ROI) is a possible candidate for projects. Profit and loss models work well for products.

If we optimize the one thing that matters, the other numbers will care for themselves.