Sunday, July 31, 2011

Follow-up on Getting Fit Using Agile Workstations

Back in late December, I blogged about my New Year's resolution of using a standing workstation. Well 6 months later, I can say that I have stuck to it. I can now work standing for about 6 hours a day, with a break during lunch. Overall, I definitely feel better and more energized, but I do not have concrete metrics to show that my health is improving. There are however more studies that have come out on the subject. Some warn of the dangers of sitting, yet other warn of the dangers of standing. Go figure!

And here's an info-graphic from medical billing and coding that sums it all up:

Sitting is Killing You
Via: Medical Billing And Coding

Tuesday, July 19, 2011

Importance of Well Designed Software

Refactoring: Improving the Design of Existing CodeAt the 2011 Agile Development Practices West conference, Martin Folwer addressed trade-able quality.

Martin explains that quality is something we can trade-off for other things. We often hear managers saying “We need to put less effort on quality so we can build more features for our next release.” We also do this every day. We do it when we buy a car. Sure we want the fancy car, but we go for the cheaper one and spend the extra savings on something else. This is a natural part of how we think about the things that we buy every day.

In software, there are visible and invisible quality features. For example, with a UI, you can feel the difference. But internal quality is not visible to the users. As a buyer, if I can’t see it, why do I want it? In that case, I will always pick the cheaper option.

Next Martin introduces the Design Stamina Hypothesis to illustrate why we should care about internal design of software.

Figure 1 - Stamina Hypothesis

The graph shows functionality over time.
The blue line shows bad design. We start out strong, but fade and slow down over time.
The red line shows good design. We start out strong and over time, we can keep a steady pace and even speed up.

With the clean system, a year from now it will have another 5 new features. The bad design system will probably only have 1 or 2 new features as they struggle with their bad code base.

Next Martin introduces the term technical debt which was originally coined by Ward Cunningham. Complexity that we don’t need causes extra effort to add new features. The unnecessary complexity in your code base is like the principal of a debt and the extra cost that you pay for adding new features is like the interest on the debt. This metaphor is useful when talking with non technical people. When building new software, you can choose a quick and dirty approach, increase your debt and increase your interest payment. Or you can pay down the principal and reduce interest payments.

Martin then explains the reasons we get into technical debt.

Figure 2 - Technical Debt Quadrant

1. Prudent/Deliberate: “We must ship now and deal with consequences” – This is a conscious decision. I have a deadline and I’m prepared to tradeoff some quality to meet that deadline.

2. Inadvertent/Reckless: People have no clue about software design.

3. Deliberate/Reckless: Very close to prudent/deliberate however, it is done without understanding what is going on. The decision to trade-off quality (debt) for speed only makes sense when we are below the design pay-off line (where the 2 red and green lines cross in figure 1). The key is to understand how far away the design pay-off line is. It is probably in the order of weeks and not in the order of months. It is a lot shorter than what people tend to think it is. If I am close to the point where I go over the design pay-off line, then there is no point in sacrificing design for speed because them I will end up losing both.

4. Prudent/Inadvertent – Here the financial metaphor breaks down. This case is when we’ve taken on debt without noticing it. It is because we learn new things as we code and when we look back at what we coded we say “Now we know how we should have done it”.

Clean Code: A Handbook of Agile Software CraftsmanshipThis presentation is available on youtube at (starts at minute 29:05)

Martin also discusses technical debt on his blog and

Tuesday, July 12, 2011

Command and Control vs. Agile

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))
In her book, Coaching Agile Teams, Lyssa Adkins nicely maps out the transition in beliefs that traditional project managers have to go through when adopting agile.

Lyssa explains that the command and control project management beliefs on the left need to be replaced with the agile beliefs on the right:

Project management belief Replaced with
We can plan the work and work the plans. Planning is essential, plans are useless.
The triple constraints can be traded off for one another to correct for unknowns. Time and budget are held constant. Only scope flexes.
The plan gets more accurate over time as we flush out the project through phases of activity: requirements, design, testing, and so on. The plan gets more accurate over time because it is constantly reviewed and tuned up based on the teams actual performance.
Delivering on time, within budget and on scope equals success. Clients getting the business value they need is the only value of success.
Scope can be locked down with later discoveries being handled as change requests against the schedule end date. Scope remains flexible and changes of any kind are welcomed even late in the schedule.
Controlling through the project plan is my job. Controlling through a plan is not possible; releasing the team into the safety of agile is my only measure of control. So I coach the team to use agile well.
Completing tasks and delivering deliverables indicate progress and value delivered. Only delivered end products indicate progress and value delivered.

Tuesday, July 5, 2011

The Agile Manifesto – 10 Years Later

At the 2011 Agile Development Practices West, Martin Fowler reflected on where we are in the agile movement 10 years after the creation of the Agile manifesto. Martin looked at what was going on back in 2000. We were in a world of badly managed software. A group of people felt that to clean up this mess we needed big methodology, planned driven methodology, or an engineering approach to software development with lots of documents and lots of processes (waterfall).

Others had success with a different approach. They believed in rapid iteration, lots of collaboration, and an evolutionary approach to requirements, design, and architecture. They felt that they were not getting heard and were getting trampled by big methodology approach.

This group got together in Snowbird 10 years ago. The idea for the meeting originated a year earlier when the group got together at a workshop at Kent Beck’s home. Kent described XP as a set of practices governed by a set of principles and values. However, there were some that liked the values or principles, but did not like the practices.

This led to the Snowbird meeting where they concentrated on the values and discussed the different approaches like XP, SCRUM and Feature Driven Development. Uncle Bob felt the group needed a manifesto as a statement of what they believed in. In the end, the people that wrote the manifesto were just the people that were free to meet up that week.

Now 10 years later, a lot of the people that where there at the creation feel a sense of unhappiness with Agile and the manifesto.

Martin believes there are 2 main reasons for this.

The 1st is due to the inevitable consequence of success. The idea of Agile spreads out but the true meaning gets diffused. He refers to this as semantic diffusion. Anything that is successful spreads faster than the semantics can follow it. Martin stresses that we have to keep reminding people about the core concepts.

The 2nd reason is that the Agile revolution is still in its infancy. We are in the early days of a very long running change. Martin remembers the OO revolution. It started in the late 60s, it was put together in the 70s, had a good definition of what OO is in the 80s with small talk and took another 20 years or so before OO became main stream in languages like java, C++ and C#. Still today, 40 years on, people think they are doing OO, but they really just have procedures and naked data structures and not true OO.

Martin thinks Agile will take even longer than OO because it affects more people. It’s not just developers, but it is testers, BAs, managers, etc…

Martin then argues that people should still care about agile. He remembers how the manifesto was written.

The group came up with 8 valuable useful good things in software development. The idea was to arrange them in pairs so that one useful thing was more valuable than the other. The guiding light was the drive to the engineering methodologies. Flipping the values around was the value system of the engineering methodologists.

A lot of companies care about processes and tools over individuals because they want to be able to move people around.

The design and documentation is important to them because they believe that once it is produced they can give it to a bunch of developers that can code it up.

You have to have contracts in place and decided. The conversations are based on what is in the contract.

Following a plan was important because the definition of success was based on whether they stuck to the plan.

Martin argues that if you don’t care about Agile then you can be equally happy in a flipped or agile environment. The order within each pair of values does not matter.

Martin wraps up by looking to the future. He sees 2 emerging areas for Agile. The 1st is Agile User interface design where the UI evolves through customer, designer and developer collaboration instead of handing the UI to a team and then asking the developers to code what was designed (even if the developers see much simpler and faster solutions).

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))The second is the concept of continuous delivery and improving the process of how we move code from development to test to production.

This presentation is available on youtube at (minute 50)