Being Agile

This is a bit complicated than it sounds. Agile is not a set of processes that one can blindly follow. Nobody practices Agile method. It's a way of thinking about software development.

Let's start with a more formal description called Agile Manifesto. Agile Manifesto is a collection of 4 values and 12 principles to guide us through the process of software development.

Rather than dumping everything here, I'll take you through the right resources to read about it. Here is the Manifesto for Agile Development and the Principles behind Agile Manifesto. To be agile, you need to put these values and principles into practice.

Agile Methods

Agile methods are processes that follows agile philosophy. They consists of individual practices like setting coding standards, using version control etc. Of course, these practices have been around for years. But agile refines the set of existing principles by handpicking those which are aligned to agile philosophy, discarding the rest and also by bringing in some new ideas.

Every team, project and situation is unique. You might want to create your own agile method by mixing together various agile practices. But, creating a brand new agile practice from scratch is a bad idea unless you have used agile development for a prolonged period of time. Always start with an existing, proven method and refine it in lieu of starting one from scratch.

- learnings from the Art of Agile Development

The Art of Simplicity (Part 2)

Most of the time, we never realize why some concepts are simple until we think about them. Just consider this example. Have you ever wondered why manholes are round in shape? We could have made them in many other shapes, say squares or real artistic ones.

Not many people had an answer when Venkat asked this question to the audience. For shapes other than round, there is a greater chance for its lid to fall into the hole. But with a round lid, we don’t face this problem. It can also be easily moved by rolling. Also, at the end of a long tiring day, the workman doesn't have to worry in which direction the lid has to be placed to close the hole properly. See how a very simple design helped in solving many issues that could have happened.

Have you ever given a thought why Mona Lisa is considered to be a masterpiece? Along with the fact that it was painted by the famous artist, Leonardo Da Vinci, it is simplicity that always attracts people towards it.

The essence of this keynote was this: Never complicate things too much.

He concluded the session with a very nice story based on Richard Feynman’s quote...

• • • 

Once, I was giving lectures to a bunch of students in the college. I was teaching the same stuff from past one decade. But, for the first time, something strange happened. All the students had nothing to say, after an hour long lecture , other than-

“Sir, we didn't understand anything!”

I was puzzled. I didn't know what had happened. I went back home. I kept  thinking and thinking about it. Then, I went back to read the same topic.

Slowly and surprisingly, I started understanding better. I uncovered many aspects and by the end of  that night, I got a clear picture about the entire concept.

Next day, I went to the same class and started with the same lecture, but with a new insight. Within five to ten minutes, I could make out that every student understood the concept clearly. All students were happy and they exclaimed-

“Sir, why couldn't we understand this yesterday? It is really very easy. ”

“It is simple. I hadn't really understood what I was teaching till yesterday. But now I know.”

• • • 

- summary of the keynote, The Art of Simplicity, by Dr. Venkat Subramaniam (Agile Kerala 2013)


Thanks to +Vaishnavi M K, +Arun Prakash and +Rohit Kumar for your suggestions and proofreading.. :-) 

Version Control Systems

Version Control Systems allow users to manage changes in programs stored in a computer system. Changes are usually identified by an incrementing number or letter code also known as revision number or revision.

One of the main features of version control system is branching. When you’re working on a feature which you are not sure is going to be in the next release, you can spawn a new branch and start working on it. After completing the feature, you can decide whether to merge it to the main line or to avoid it altogether. 

( image courtesy: FeatureBranch, by Martin Fowler )

Consider a scenario when 2 persons, Professor Plum and Reverend Green, work on their own feature branches as shown above. Both of them periodically pull from the main branch so as to avoid losing any updates. When Professor Plum finishes his feature, he’ll push it to the main line. After that, when Reverend Green pulls from the main line, he’ll get an entirely different version of the code. This results in a merge ambush when he tries to push it to the main line.

( image courtesy: FeatureBranch, by Martin Fowler )

The best practice to avoid this is to push the code to the main line regularly. This helps to achieve Continuous Integration. The longer you wait, the more painful it becomes.

( image courtesy: FeatureBranch, by Martin Fowler )

There are mainly two kinds of merges: textual merge and semantic merge. Textual merge refers to merging text from one source file to another. Semantic merge is tougher compared to textual merge, where we need to ensure that the feature that we’re going to merge should work with all other existing features. 

An alternative to using branches for making new features is a technique called Branch by Abstraction. This allows to make structural changes to the code-base incrementally without spawning another branch.

Another argument in favor of branching is Feature Toggle. Feature toggle helps to develop and test a feature on trunk. Imagine we are releasing into production every two weeks, but need to build a feature that's going to take several months to complete. Here we can create a configuration file to define a toggle for the unfinished feature. The feature will not be shown when the toggle is turned OFF. After completion, we can turn the toggle of that particular feature ON.

Distributed Version Control System

The distributed version control system uses a centralized repository, which allows a user to check in and check out. Here, the programmers are not aware of other people working in parallel, since they are isolated from one another. But there are some situations where it is handy to be aware of people around you. That’s why decentralized version control systems were introduced.

Decentralized Version Control System

A decentralised version control system, like distributed VCS, allows users to push and pull from a central repository. But here, every version of the repository that exists is a complete version of the repository. Each person has his own personal repository. A user can pull, not only from the central repository, but also from other users’ local repositories. In addition to that, commit and push can be performed within the local repository as well as on the central repository.

- a summary of the video, Version Control Systems, from Agile Engineering Practices, by Neal Ford

Pair Programming

A summary of Pair Programming video, by Neal Ford (Agile Engineering Practices)

Pair programming is a controversial agile development practice. It involves two programmers working on a pairing station. A pairing station consists of two monitors, two mice, two keyboards and a single processing unit. So, technically, it is a shared computer system. The pairing system has all the tools required for development.

The two programmers have distinct roles. One of them is the driver, who types the code and the other is the navigator, who goes through what the driver is doing. The latter analyses the code in a holistic fashion and decides whether the driver is moving in the right direction. The navigator may thus interject the driver for suggestions and/or corrections. The two switch roles frequently.

The navigator and driver may have different ideas and due to collaboration, the resulting software tends to be much more efficient. If the same project has more than one pair of programmers, pair rotation can be done, which allows all the programmers to pair with each other. Pair programming and pair rotation helps to spread knowledge within the team rapidly. If one programmer discovers something really cool, within no time, everybody else learns it.

The human brain is divided into two: the left part and the right part. When coding alone, we use only the left part, which deals with linear (step-by-step) thoughts. During pair programming, the navigator uses the right part of the brain, which deals with non-linear and holistic thoughts while the driver uses the left part of the brain. Since the programmers always switch, they effectively end up using both parts of their brains and the code thus developed is of much higher quality.

In Flow, The Psychology of Optimal Experience, the author, Mihaly Csikszentmihalyi, explains about a psychological state called flow ( that’s what the book is all about! ). When a person is in his state of flow, time completely disappears. He dedicates full attention to what he is doing and may also experience tunnel vision. In this state, people are highly productive. However, the flow state is highly fragile and once broken, it can take up to 20 minutes to get restored.

The state can be compared to sleep. We fall asleep unconsciously. But when somebody wakes us up, it will take time to get back to sleep again. Similarly, the train of thought, once broken, will take time to get loaded back into the brain again.

During pair programming, it is possible for two people to be in the flow state at the same time! That is a really powerful source of productivity. Moreover, when we work in pairs, people are less likely to interrupt us presuming we are busy, as opposed to when we work alone. This helps retain the flow state for a longer period of time. A person also ends up wasting less time after breaks since he knows that the other programmer in the pair is waiting.

Pairing is tightly feedback-driven. Coding is the most complicated part in the development cycle and getting correct feedback at the right time helps increase productivity and decrease error rate.

The driver narrates his actions, which helps him understand better what he is doing. It is proven that when we recite something, we’ll be able to comprehend it in a much better manner. Pairing helps in knowledge-sharing and communication. It also makes programmers experts at explaining complex technical concepts.

Furthermore, it is fun too..!!

What pair programming is not

1. Two people crowded over one computer
2. Mentoring - Mentoring is when one person is learning and the other is coaching. This is a little hard for both parties, because the coach has to slow down for the learner to understand and the learner needs to push himself beyond his comfort zone to understand things better.
3. Keyboard domination - This happens when one person loves to type. One idea to avoid this situation is to combine it with Test Driven Development. One person writes a failing test and the other writes code to make the test pass then writes another failing test. The former now writes code for that second test to pass, and this process continues.
4. Pair marriages - This happens when pair switching does not happen.
5. Less productivity - The decrease in productivity is not significant when compared with the decrease in error rate. In fact, errors take more time to get fixed during later stages.

Isn’t it awkward if I pair with someone who is much better than me? Of course not!

- “When you play with a better player, your game gets better.”

Thanks to +Jerry John Jacob for the proofreading and edits.. :-)