The Importance of Paradigms (Beliefs)

September 12, 2008 — Posted by Al Shalloway

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-Agile Software Development: Achieving Enterprise Agility

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 traveled 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 to 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?

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, SAFe
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban