Using object-oriented design structures for project agility

From the Agility and Project Leadership Blog
by
A contrarian and provocative blog that goes beyond the traditional over-hyped dogma of "Agile", so as to obtain true agility and project leadership through a process of philosophical reflection.

About this Blog

RSS

Recent Posts

Has Scrum outlived its usefulness? Should Scrum just go away?

The rise of Agile’s SAFe is like a bad episode of the movie Groundhog Day

Marcel Proust’s recursive novel: Why the concept of iteration in Agile is shortsighted

Forecast for 2015: The beginning of the end of Agile?

Google considered the best US company to work for due to HR agility



I read this interestingI read this interesting piece from the Dr. Dobbs website by Allen Holub, in which he argues for the use of object-oriented design principles to drive Agile software development projects.  One area in particular that I like is the idea of adhering to the “Liskov Substitution Principle (LSP)”:
I read this interesting piece from the Dr. Dobbs website by Allen Holub, in which he argues for the use of object-oriented design principles to drive Agile software development projects.  One area in particular that I like is the idea of adhering to the “Liskov Substitution Principle (LSP)”:
 
It should be possible to completely change the implementation of an object without the clients of that object knowing that the change has happened. You should be able to add, remove, or modify any or all of the fields in an object, replace all the non-public methods of the object, and completely replace all the implementations of the public methods. As long as the public interface hasn't changed, the users of the object shouldn't know or care that a change has happened. This principle extends to any sort of modularized system, not just OO classes and objects.
 
In an Agile world, following LSP gives you the freedom of changing implementation without the effects of that change rippling out to the rest of the program, and this property is, again, essential when constant change is in the picture.
 
More formally, LSP can be defined for an object oriented computer program where “S is a declared subtype of T, objects of type S should behave as objects of type T are expected to behave, if they are treated as objects of type T”.  An important point to note is that the LSP is all about expected behavior of objects.  One can only follow the LSP if one is clear about what the expected behavior of objects is.  As this Wikipedia page outlines:
 
The Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address entitled Data abstraction and hierarchy.  It is a semantic rather than merely syntactic relation because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular.
 
So what does this have to do with managing Agile projects?  A lot and this principle could be applied to any type of project.  From just the perspective of the agreed to software functionality scoped for an Agile project, there will be expected behavior of that functionality from the customer’s perspective.  If you have thought through and solicited the correct requirements and have facilitated a modular design and flexible process like Agile, then you should be able to change the implementation if needed and still deliver the expected behavior without the customer ever knowing it.
 
Taking this further, any project whether using an Agile or traditional approach should always be incorporating a way to ensure modularity and flexibility so as to accommodate the inevitable changes without compromising the expectations of the customer for the agreed to deliverables.
 
I know this is common sense, but it’s not only intellectually interesting but an important reminder to be aware of these synergies in different fields to ensure you are providing the most optimal solutions for your projects.
I know this is common sense, but it’s not only interesting but an important reminder to be aware of these synergies in different fields to ensure you are providing optimal solutions for your projects. piece from the Dr. Dobbs website by Allen Holub, in which he argues for the use of object-oriented design principles to drive Agile software development projects.  One area in particular that I like is the idea of adhering to the “Liskov Substitution Principle (LSP)”:
 
It should be possible to completely change the implementation of an object without the clients of that object knowing that the change has happened. You should be able to add, remove, or modify any or all of the fields in an object, replace all the non-public methods of the object, and completely replace all the implementations of the public methods. As long as the public interface hasn't changed, the users of the object shouldn't know or care that a change has happened. This principle extends to any sort of modularized system, not just OO classes and objects.
 
In an Agile world, following LSP gives you the freedom of changing implementation without the effects of that change rippling out to the rest of the program, and this property is, again, essential when constant change is in the picture.
 
More formally, LSP can be defined for an object oriented computer program where “S is a declared subtype of T, objects of type S should behave as objects of type T are expected to behave, if they are treated as objects of type T”.  An important point to note is that the LSP is all about expected behavior of objects.  One can only follow the LSP if one is clear about what the expected behavior of objects is.  As this Wikipedia page outlines:
 
The Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address entitled Data abstraction and hierarchy.  It is a semantic rather than merely syntactic relation because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular.
 
So what does this have to do with managing Agile projects?  A lot and this principle could be applied to any type of project.  From just the perspective of the agreed to software functionality scoped for an Agile project, there will be expected behavior of that functionality from the customer’s perspective.  If you have thought through and solicited the correct requirements and have facilitated a modular design and flexible process like Agile, then you should be able to change the implementation if needed and still deliver the expected behavior without the customer ever knowing it.
 
Taking this further, any project whether using an Agile or traditional approach should always be incorporating a way to ensure modularity and flexibility so as to accommodate the inevitable changes without compromising the expectations of the customer for the agreed to deliverables.
 
I know this is common sense, but it’s not only interesting but an important reminder to be aware of these synergies in different fields to ensure you are providing optimal solutions for your projects.
Posted on: December 27, 2013 08:43 PM | Permalink

Comments (2)

Please login or join to subscribe to this item
Don, excellent article!

"Taking this further, any project whether using an Agile or traditional approach should always be incorporating a way to ensure modularity and flexibility so as to accommodate the inevitable changes without compromising the expectations of the customer for the agreed to deliverables."

You''ve hit the nail on the head. This should be true for all projects.

Thanks for sharing

Please Login/Register to leave a comment.

ADVERTISEMENTS
ADVERTISEMENT

Sponsors