I have been seeing more and more the importance of paradigms in guiding software development.  I am even including a chapter on it in our upcoming book: Lean Software Development: Scaling Agile to the Enterprise. 

What is a paradigm? It is the set of experiences, beliefs, and values that affect the way you perceive what is real and how you should react. A paradigm is a habit of reasoning. Your world view.

A paradigm is deeply held and you may not always be aware of it. For example, when you were learning how to drive, you learned which side of the road was the "correct" side. It affects every aspect of how you drive, where you look for threats, and even how you cross the street. You do it without even thinking. Doesn't mean it is right, but it is "real." If you have ever travelled to another country where they drive on the "wrong" side (note the value judgment!), it probably took you a long time to adjust your way of seeing, in spite of lots of evidence to the contrary.

Because paradigms affect our view of what is real and true, we are slow to change them.

Why am I talking about this in a software development blog? Because the paradigms we developers hold affect our behavior as developers. And if we are going to grow and improve as developers, we have to become conscious of the paradigms that keep us in place. 

In other words, we should always be investigating our beliefs as developers. We can examine our hypotheses and see if reality provides evidence to support or reject them. Hold on ot what is accurate, what works, and let go of what doesn't. Shouldn't that produce a better guide for our actions and behaviors? That is what I want to do here, briefly: examine the paradigms of software development... because they imply certain actions will be affective and others will not. 

Waterfall Method

The paradigm underlying the Waterfall method is based on the following assumptions:

• You can know everything you need to know to build software properly at the start of the project.
• Customers can accurately tell you what they want at the start of the project.
• You don't need to get feedback from the customer until the end of the project.
• You can tell where you are by completing milestones that are achieved by creating documents – that is, it is ok that no complete, tested software is delivered until the very end.
• You can effectively have separate groups do analysis, design, code and test – that is, there is little loss in the hand offs between the groups.
• Hand-offs between work types can be done efficiently by writing down what was done in each step.
• You can test at the end and achieve quality (you _can_ test in quality).
• Management can demand that certain work be done at a certain time.
• Giving people lots of projects to work on simultaneously to make sure that they are busy is a good way achieve 100% productivity

Agile Framework

The paradigm underlying Agile is based on the following assumptions:

• You don't know everything you need to know at the start.
• Customers can not accurately tell you what they want at the start of the project – they will gain clarity as the project proceeds
• You want feedback from the customer as often as possible.  You want to give developer's feedback on how they are doing as soon as possible.
• Working code is the most accurate way of seeing where you are.
• Groups working together (in workcells) is a better way to avoid the loss of handoffs.
• Moving test to the front of the cycle improves the conversation between developers and customers and testers and improves the quality of the code (you can't test in quality).
• Management must work with the team to improve the way they work to improve their efficiency.
• Working on one project at a time improves the productivity of a team.

This, of course, is just the beginning. In follow up blogs, I'll discuss the paradigms of Lean vs. Agile vs. Scrum (they are not the same).

I believe that being clear about your foundational beliefs is useful because if your actions are inconsistent with them you should expect to be heading for trouble.

What do you believe?

Technorati Tags: Lean Lean-Agile Scrum

tag with del.icio.us