Software Development Myths - Get rid of them soonest

Myth 1: Early Specification Reduces Waste

When we are awarded with a software project, we play 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 at the beginning and sign off to build a good software application.

Most customers can not tell what they actually want. In most cases they do not know actually. As a result, the customer proposes unused features which are the worst kind of 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 it. We continue to maintain it in the hope it may be used in future. But that future never becomes reality. However, every bit of code that is 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 reasons,  after spending years on it.

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

We need a process that allows us to develop the 20 percent of the code that will deliver 80 percent of the value, and only then go on to develop the next most important features. We should never establish scope with a list of everything that a system might possibly need, especially if the list comes from customers who don’t really know what they want. However we must have to keep an eye that the design and architecture are not a particular feature specific but with 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 the people 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 percent of the defects that seemed to be caused by people making mistakes were actually 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 for eliminating waste in software development: Write less code. In order to write less code, we need to find the 20 percent of the code that will provide 80 percent of the value and write that first. Then we add more features, stopping when the value of the next feature set is less than its cost. When we add new features, we have to keep the code simple and clean, or complexity will soon overwhelm us. So we refactor the design to take the new capability into account, keep the code base simple, and get rid of software’s worst enemy: duplication. This means that we should routinely expect to change existing code.

The use of TDD (test driven development) practice really can help to add quality built in. TDD test cases are basically requirement logics that may fail if not taken care of. TDD test cases are written prior to the development and by the development team itself. So writing code and making  the test pass is a side by side process by  the developer. So code provides quality built in. In the traditional waterfall process test team write test cases and simply throw the error in the defect tracking system. After that fixing those errors adds complexity to the codebase and attracts future problems.

Myth 3: Predictions Create Predictability

Software development has a notorious reputation for being unpredictable, so there is a great deal of pressure to make it more predictable. To do it, in most cases, we get the opposite effect. We create a plan, and then we act on that plan as if it embodies an accurate prediction of the future. Because we assume that our predictions are fact, 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 turn out to be 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 predictions of the future are fact rather than forecast. Instead, we need to reduce our response time so we can respond correctly to events as they unfold.

In order to increase the predictability of outcomes, we need to decrease the amount of speculation that goes into making decisions. Decisions that are based on facts, rather than forecasts, produce the most predictable results. As a control engineer, Mary knows that an empirical control system—one 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 easily. Worldly affairs do not always go according to plan and orders have to change rapidly in response to change in 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 easily it bends. This elasticity is important. 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 it is 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 easily but commitment does not.   Let’s not succumb to the myth that planning is the same thing as making a commitment. We should plan thoughtfully and commit sparingly.

Myth 5: Haste Makes Waste

If you want to go fast, you need to be engaged, thinking 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 how to do 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, 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.” There is no process that cannot be improved. To prove this to yourself, simply 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, 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 For example, we tend to 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” that is, raise the measurement one level and decrease the number of measurements. Find a higher-level measurement that will 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 really 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 really matters, the other numbers will take care of themselves.