Agile Manifesto: Incredible Success and time to Move On

This blog was originally written in April, 2012

I have incredible respect for the signatories of the Agile Manifesto. I believe it to be a great document. I say this for several reasons – the greatest being it created a new space for effective development to take place. It started a movement that has changed the lives of millions.

That said, I believe manifestos, by their very nature when they are effective, tend to be time dependent. In the case of the Agile manifesto, this is particularly so – it’s very success has created a vacuum.

The Agile Manifesto’s success has created opportunity for Agile to manifest (pun intended) throughout the organization. However, because it focused on the development organization, it has left a vacuum.

Some people have challenged me about my assertion that the Agile Manifesto focuses on the development team. A twittervation with Derek Neighbors (@dneighborsr) prompted me to make the following table about the Agile Manifesto – showing what it mentions by role/area:

  Which Area / Role Is Referred to
Principle Business Management Developers / Software / Project Customers
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software     Explicitly Mentioned Explicitly Mentioned
         
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.     Explicitly Mentioned Explicitly Mentioned
         
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.     Explicitly Mentioned  
         
Business people and developers must work together daily throughout the project Explicitly Mentioned   Explicitly Mentioned twice  
         
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.     Mentioned 4 times  
         
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation     Explicitly Mentioned  
         
Working software is the primary measure of progress.     Explicitly Mentioned  
         
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Explicitly Mentioned   Explicitly Mentioned Explicitly Mentioned
         
Continuous attention to technical excellence and good design enhances agility     Explicitly Mentioned  
         
Simplicity–the art of maximizing the amount of work not done–is essential.        
         
The best architectures, requirements, and designs emerge from self-organizing teams.     Mentioned 3 times  
         
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.     Mentioned  
         
Total Times Mentioned 2 0 17 3

I am sorry if I can’t see how the numbers on that last row don’t make my case. However, be very clear, that this actually is evidence that the Agile Manifesto was great and worked! So no one should take this as an attack on it. By working so well, we have expanded Agile into a space outside of where the Agile Manifesto originally existed. I can’t think of a greater testament to it than that.

Agile is now as much, or more, about the enterprise as it is about teams. We don’t need a new manifesto, we just need to be open to expanding what we are going after.

Practice: Encapsulate by Policy, Reveal by Need

Traditionally, encapsulation has been thought of as the hiding of data or “state.” While it is true that hiding data encapsulates it, encapsulation can mean much more than this. It’s like the notion that all dogs are mammals, but not all mammals are dogs.

The better way to think of encapsulation is, “the hiding of anything.” A lot of things can be encapsulated besides data.

Here are examples of things that can be encapsulated.

  • How something is designed
  • How something is created
  • When something is created
  • The number of actions that take place
  • The order in which actions take place
  • The actual type of something
  • The nature of a type (concrete or abstract)
  • An interface
  • The implementation of anything
  • The structure of a collection
  • The current status (mode) of a system
  • The number of modes a system has
  • The cause of a modal change

Learning the patterns teaches you how to encapsulate all of these things, and more. But not everything should be encapsulated. How do we decide what to encapsulate once we know how?

Knowing how to do something empowers you. But then you have to decide under what circumstances to do it and when not to.

This would make for a good sign to put on the wall where you’ll see it repeatedly throughout your workday:

Encapsulate by policy, reveal by need.

Encapsulation is a decision. We know it is inevitable that we will make mistakes, will make wrong choices from time to time. The question is, what will we have to do when we realize we are in error?

If you encapsulate something and then later realize that you should not have encapsulated it (for example, you need to make it reusable or you need to test it in isolation), then breaking encapsulation is usually trivial. You either change it from a private thing to a public thing, or you add some kind of accessor. This is easy.

If, however, you fail to encapsulate something and then realize later that you should have this can be a lot of work, especially if other parts of the system have become coupled to it over time. It can cause a redesign of those other parts. This can cause a lot of rework.

Encapsulating too much can be an easy problem to solve. Encapsulating too little is often very difficult to solve.

I’d rather make the mistake of encapsulating too much.

Practice: Programming by Intention

Programming by Intention is a way of writing code that capitalizes on the way a programmer thinks.

Whenever you write code, what you are essentially doing in breaking down a behavior into its steps. In sense, that’s what code is. So, your brain, as a developer, is good at this. Programming by Intention says let’s capitalize on this fact.

Example

You have a transaction processor that can commit a transaction more than one way, depending on its size. The transaction string needs to be tokenized and normalized before being committed. Programming by Intention suggests you write the code this way:

class Transaction {
   public Boolean commit(String command){
      Boolean result = true;
      String[] tokens = tokenize(command);
      normalizeTokens(tokens);
      if(tokens.Length > getMaximumLength()){
         result =
            processLargeTransaction(tokens);
      } else {
         result =
            processSmallTransaction(tokens);
      }
      return result;
   }
  }
}

Why this is a good idea

The “helper” methods do not exist yet. We are hypothesizing that they will later: we will create them. This is a very simple thing to learn and do. But what is the point? Why is it a good idea?

Coding in this way creates a fundamental separation of concerns.

  • The primary function code is all about the process of the behavior. If, in the example, this code is inherited by a new developer or team, then reading the commit() method in the example will tell the entire story of how this object works.
  • Each helper method is about the implementation of one step along the way. This makes finding defects and integrating new steps much easier. It also makes the code easier to understand, thus requiring minimal comments along the way.

Also, creating discrete methods for each functional step makes for reusability and ease in refactoring. For example, if later it is determined that tokenizing the committed string should be done in different ways under different circumstances, then converting the tokenize() method into a Strategy will be much easier.

Programming by Intention can be adopted as a practice because it does not create additional work: the code written into the helper methods is the same code that would have been written in-line. It’s just written at a different time and in a different location. Also, developers will readily adopt it once they try it even a single time. It proves itself.

Practice: Encapsulating Constructors in Simple Classes

A recurring question in OO is, “When it is determined that an algorithm should be established in its own separate class (to make it testable, or reusable, or simply as an issue of cohesion) should it also be given a separate abstract type that it implements?”

The advantage, of course, is that the client (or clients, as more arise) will not couple to the specific service class, but rather to the abstract type. If more versions of the service are added, then clients will be largely unaffected. It’s a form of “future proofing”. But can you do this all the time? Should every class, when deemed necessary, also have a second class that hides its real type? Often this would seem like overkill or over-design. Does that mean it should never be done? That seems wrong too.

Is there something that can be done to resolve this conundrum?

Continue reading “Practice: Encapsulating Constructors in Simple Classes”