Martin Fowler

1. “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

2.  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.

3. About ThoughtWorks
4000 Employees
14 Countries
40 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 Interview
I came to find ThoughtWorks by
I 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 is
Finding 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.

4. Publications
1996. 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.

5. The Essence of Agile Software
https://www.youtube.com/watch?v=URlnxbaHhTs
I've always seen the essence of agile thinking resting on two contrasts with traditional
plan-driven software engineering.
Agile Development
is adaptive rather than predictive
is 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.

6. 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

7. 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.

8. 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.

9. 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.

10. 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.

11. 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 quickly
Because 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.

12. Continuous Integration brings multiple benefits to your organization:
Say goodbye to long and tense integrations
Increase visibility which enables greater communication
Catch issues fast and nip them in the bud
Spend less time debugging and more time adding features
Proceed in the confidence you’re building on a solid foundation
Stop waiting to find out if your code’s going to work
Reduce integration problems allowing you to deliver software more rapidly
More than a process
Continuous 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

13. 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 Responsibilities
Check in frequently
Don’t check in broken code
Don’t check in untested code
Don’t check in when the build is broken
Don’t go home after checking in until the system builds
Many teams develop rituals around these policies, meaning the teams
effectively manage themselves, removing the need to enforce policies from on
high.

14. 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.