When development looks like burps, there is serious trouble. Why is there trouble? Where does this trouble come from? What can be done against it?

So Welcome to my blog series about burpy software development. In this blog series I want to focus on four things:

• how to detect
• the effects of
• the causes of
• how to prevent

... burpy software development.

Introduction

Infrequent, large changes can be a sign of trouble - it can, in some cases, indicate destabilizing changes to the code.

↗Robin Luckey on ↗Project Codebase History

Robin Luckey is right. Reading his article opened my mind for this topic and made me write this blog entry.

Robin chose the soft wording can, in some cases, indicate for the context of ↗Ohloh which is Open source software development. Open source is mostly developed in the spare time of the developers. Their time breakdown often does not allow development to look like a constant flow: In their spare time, they also have to care about life, families, friends, hobbies. And many of them are involved in more than just one project. They will code whenever they have time for that.

But what if we look at commercial software development? Software development which is done by companies to earn money, to make profit? Shouldn't they be able to have a constant flow of development?

And even if we do open source development, how can one distinguish good from evil when confronted with infrequent, large changes?

Summary of aspects

Development can be burpy with many symptoms, many effects, for many causes and on many different scales.

So let's have a closer look. Under the hood, I see several aspects which may make development look like burps. One of them is infrequent changes. Another is large changes. In this blog entry I will focus on those aspects which are related to project management and time schedules. I want to focus on infrequent, large changes which are caused by management.

Waterfall

Author: ↗James Dignan
License: ↗GNU Free Documentation License
Source: ↗Wikipedia

The most evil, most ugly form of burpy development is the waterfall. The article ↗Managing the developement of large Software Systems (Dr. Winston W. Roy, 1970) already described some of the negative aspects of the waterfall.

That means we know for 40 years that the waterfall is evil. Why is management still deploying waterfall processes? And even worse, why is it finding more and more disguises for proclaiming waterfalls under different names?

Management Driven Development Interruption

Management Driven Development Interruption

An example of a waterfall that sometimes isn't recognized as such happens to many long-term projects. For instance, imagine your project is an embedded operating system. The operating system's life span is something like 20 years (or even more). Every 1.5 years a new project is setup for the next generation of the operating system. The project manager starts an analysis phase and wants to have a new architecture defined, the efforts estimated etc.. The wishes of the project manager are not evil themselves, but they are a cause of trouble if taken too serious. Developers tend to take their project manager serious, which is very good in itself. But the combination of this easily leads to developers stopping development and doing paperwork instead.

Planning and thinking is not bad either. In the current project, we're in the planning phase for 5 months now, and the project manager now is already thinking about prototypes and warmup-phases when the implementation phase comes. Man, something has gone seriously wrong.

• The way the project is setup and contracted is wrong because it already defines that the project is performed in a waterfall.
• The way the previous project(s) have been run were wrong because otherwise the architecture wouldn't need so much preparation for the new requirements.

About

About Cher

Cher is a computer hacker that actively contributes to open source software and also runs some of his own projects as open source.

Cher's homepage is ↗http://www.riedquat.de/.