“I was lucky enough to be at the beginning of this story, with early experiences on the 'birth project' of Extreme Programming and a co-author of the Manifesto for Agile Software Development.” Martin Fowler By Adeem Akhtar

Born: 1963 in England

Education: University College London (BSc, 1986)

Occupation: Software developer, author, public speaker

Employer: ThoughtWorks, an application development and consulting company. Working as Chief Scientist.

He has written eight books on the topic of software development.

He is a member of the Agile Alliance and helped create the Manifesto for Agile Software Development in 2001, along with 16 fellow signatories.

He maintains a bliki, a mix of blog and wiki.

He popularized the term Dependency Injection as a form of Inversion of Control.

About ThoughtWorks

4000 Employees14 Countries40 Offices Game-changers - ThoughtWorks started using agile techniques in 2000 We work with people and organizations who have ambitious missions –Our Agile development tools help our clients continuously improve and deliver quality software. We are focused on helping our industry improve, and believe in sharing what we learn. We do this by writing books, blogging, running events, talking at conferences, and championing open source.Martin Fowler’s InterviewI came to find ThoughtWorks byI first spent some time as a consultant on a large Java project to build a back-end leasing application. After nine months of that, they asked me to join full time.The thing I love most about my work isFinding interesting techniques and figuring out how best to communicate them to a wide audience. I can have days of frustration trying to figure out how to write about something clearly, but once it clicks, there's a definite joy there.

Publications1996. Analysis Patterns: Reusable Object Models.

1997. UML Distilled: A Brief Guide to the Standard Object Modeling Language.

1999. Refactoring: Improving the Design of Existing Code, With Kent Beck, John Brant, William Opdyke, and Don Roberts

2000. Planning Extreme Programming. With Kent Beck

2002. Patterns of Enterprise Application Architecture. With David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee, and Randy Stafford

2010. Domain-Specific Languages. With Rebecca Parsons

2012. NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. With Pramod Sadalage.

2013. Refactoring: Ruby Edition. With Kent Beck, Shane Harvie, and Jay Fields.

The Essence of Agile Software https://www.youtube.com/watch?v=URlnxbaHhTsI've always seen the essence of agile thinking resting on two contrasts with traditional plan-driven software engineering.

Agile Development

is adaptive rather than predictiveis people-oriented rather than process-oriented

Plan-driven engineering expects us to come up with a predictive plan that precedes development. Agile plans are a baseline that we use to help us control change. Agile teams plan just as carefully as traditional teams, but the plans are constantly changing to reflect the things we learn during a project. Success is based on value delivered by the software. Plan-driven engineering seeks a process which provides enough structure to reduce individual variations to insignificance. Agile engineering sees software development as a primarily human activity, where the people involved and how they bond as a team are the primary driver behind success. Processes (and tools) can enhance a team's effectiveness, but are always second-order influences.

Purpose Of Estimation

A common scenario runs like this:

Developers are asked for (or given) estimates for upcoming work. People are optimists, so these estimates tend to be too low, even without pressure to make them low (and there's usually at least some implicit pressure)

These tasks and estimates are turned into release plans tracked with burn-down charts.

Time and effort goes into monitoring progress against these plans. Everyone is upset when actual end up being more than estimates. In effort to increase pace with the estimates, developers are told to sacrifice quality, which only makes things worse.

In this narrative, effort put into estimates is, at best, waste - since "an estimate is a guess in a clean shirt

Estimates also set expectations, and since estimates are usually too low, they set unrealistic expectations

Faced with situations like this, it's easy to see how people turn their angry glares towards estimation. This leads to an increasing notion that anyone indulging in estimating is Not a True Agilist. Critics of agile say this means that agile development is about developers going off and doing vague stuff with promises that it'll be done when its done and you'll like it.

I don't share this view of estimation as an inherently evil activity. If I'm asked if estimation is a Bad Thing my answer is the standard consultants' answer of "it depends". Whenever someone answers "it depends" the follow-up question is "upon what". 

To answer that we have to ask why we are doing estimation - as I like to say "if it's worth doing well, it's worth asking why on earth you're doing it at all".

For me, estimation is valuable when it helps you make a significant decision.

My first example of an estimation-informed decision is allocation of resources.

Organizations have a mostly fixed amount of money and people, and usually there are too many worthwhile things to do. So people are faced with decisions: do we do A or B?

Faced with such a decision it's useful to know how much effort (and cost) each will involve.

To make sensible decisions about what to do, you need to have a feel for both the cost and the benefits.

Another example is to help with coordination. The blue team wants to release a new feature to their web site, but cannot do so until the green team builds a new service to give them crucial data. If the green team estimates they will be done in two months and the blue team estimates that it will take them a month to build the feature, then the blue team knows it's not worthwhile to start today. They can spend at least a month working on some other feature that can be released earlier.

Understanding the decision may also lead you to alternative actions that may not involve an estimate. Maybe task A is so much more important than B that you don't need an estimate to put all your available energies into doing it first. Perhaps there is a way for blue team members to work with the green team to get the service built more quickly.

Similarly, tracking against a plan should also be driven by how it informs decision making. My usual comment here is that a plan acts as a baseline to help assess changes - if we want to add a new feature, how do we fit it into the FivePoundBag? Estimates can help us understand these trade-offs and thus decide how to respond to change. On a larger scale re-estimating a whole release can help us understand if the project as a whole is still the best use of our energy.

A few years ago we had a year-long project that was cancelled after a re-estimate a couple of months in. We saw that as a success because the re-estimate suggested the project would take much longer than we had initially expected - early cancellation allowed the client to move resources to a better target.

But remember with tracking against plans that estimates have a limited shelf life. I once remember a gnarly project manager say that plans and estimates were like a lettuce, good for a couple of days, rather witty after a week, and unrecognizable after a couple of months.

Many teams find that estimation provides a useful forcing function to get team members to talk to each other. Estimation meetings can help get better understanding of various ways to implement upcoming stories, future architectural directions, and design problems in the code base.

Estimation is neither good or bad. If you can work effectively without estimation, then go ahead and do without it.

If you think you need some estimates, then make sure you understand their role in decision making. If they are going to affect significant decisions then go ahead and make the best estimates you can. Above all be wary of anyone who tells you they are always needed, or never needed. Any arguments about use of estimation always defer to the agile principle that you should decide what are the right techniques for your particular context.

Continuous Integration (CI)

Eliminate blind spots so you can build and deliver software more rapidly.Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.By integrating regularly, you can detect errors quickly, and locate them more easily.

Solve problems quicklyBecause you’re integrating so frequently, there is significantly less back-tracking to discover where things went wrong, so you can spend more time building features.Continuous Integration is cheap. Not continuously integrating is costly. If you don’t follow a continuous approach, you’ll have longer periods between integrations. This makes it exponentially more difficult to find and fix problems. Such integration problems can easily knock a project off-schedule, or cause it to fail altogether.

Continuous Integration brings multiple benefits to your organization:Say goodbye to long and tense integrationsIncrease visibility which enables greater communicationCatch issues fast and nip them in the budSpend less time debugging and more time adding featuresProceed in the confidence you’re building on a solid foundationStop waiting to find out if your code’s going to workReduce integration problems allowing you to deliver software more rapidly

More than a processContinuous Integration is backed by several important principles and practices.The Practices Maintain a single source repository Automate the build Make your build self-testing Every commit should build on an integration machine Keep the build fast Test in a clone of the production environment Make it easy for anyone to get the latest executable Everyone can see what’s happening Automate deployment

How to do it Developers check out code into their private workspaces. When done, commit the changes to the repository. The CI server monitors the repository and checks out changes when they occur. The CI server builds the system and runs unit and integration tests. The CI server releases deployable artefacts for testing.The CI server assigns a build label to the version of the code it just built. The CI server informs the team of the successful build. If the build or tests fail, the CI server alerts the team. The team fix the issue at the earliest opportunity. Continue to continually integrate and test throughout the project.

Team ResponsibilitiesCheck in frequentlyDon’t check in broken codeDon’t check in untested codeDon’t check in when the build is brokenDon’t go home after checking in until the system buildsMany teams develop rituals around these policies, meaning the teams effectively manage themselves, removing the need to enforce policies from on high.

Continuous Deployment

Continuous Deployment is closely related to Continuous Integration and refers to the release into production of software that passes the automated tests.Essentially, “it is the practice of releasing every good build to users,” explains Jez Humble, author of Continuous Delivery.By adopting both Continuous Integration and Continuous Deployment, you not only reduce risks and catch bugs quickly, but also move rapidly to working software.With low-risk releases, you can quickly adapt to business requirements and user needs. This allows for greater collaboration between ops and delivery, fuelling real change in your organization, and turning your release process into a business advantage.