Agile Talk 30 Jul 1o2

Agile Software development

From a programmers point of view

7/28/2010 E-mail:akhil.kumar@gmail.com 1

Agenda
1. Introduction
2. What is Agile Software Development?
3. Review of XP values and Practices
4. XP vs Waterfall
5. What makes/breaks an agile team
6. Are Architecture and Agile two opposing forces?
7. Does agile apply only to J2EE/.net/Ruby projects
only ?
8. References
9. Q &A

Introduction
• Around 15 yrs of hands on experience in
software development
• 8 yrs in Agile environments
• IBM alumni 1996-2008
• Leading a technology startup as Chief
Architect(www.mamigo.us) since 2008. Prefer
to be called Chief Programmer.
• Keen interest in Architecture, MDD, XP.

Agile Software development
• Need a method for developing software
– Else can not foresee risks, costs, projections, value, predictability
– How/when/what/why.
• Till the art of software development matured, we looked at established
engineering methods
– civil engineering surely contributed one buzz-word: architecture
– Design review came from automobiles .
– Why did they spent so much energy (time/money/effort) on architecture/design?
• Well, Software by very definition is something soft or malleable. So why
borrow from approaches which specifically restrict this natural value.
– In contrast, can they build a quick and dirty bridge to check if it would work and iteratively
improve it?
• Whats Agile: (an adjective as per http://www.thefreedictionary.com/agile)
– Characterized by quickness, lightness, and ease of movement; nimble.
– Mentally quick or alert: an agile mind.


Change is the only constant
• Name one project where users signed off requirements and accepted them as-is.
• Users only have an initial understanding of their need, but they can not:
– document software requirements. (sign off ??)
– validate designs.
• However they can give feedback (better soon than later)
• Every feedback directly implies change
• What would you rather do (or what would they pay for):
– Build a software that meets User needs
– Build a software which meets documented requirement.
• Users know it best:
– Why cant you change it, it is software after-all.
• Extraneous factors/Bad initial choices/changing context are all examples of change.
• Change is a necessary evil though its not necessarily evil: It keeps the users/stake
holders happy.
• Need a method which reduces the risks of divergence from user needs, makes it easy
and safe to introduce change.


Extreme programming (XP)
• A method for developing software ( and specifically software
only)
• Specifically meant for Software development:
– Emphasis on “Soft”: and not a generic engineering method
– Emphasis on “development”: and not project/program management
• An Agile method (scrum/DSDM are other examples)
• Light on processes, heavy on discipline.
• Recognizes key values which should be held high in all actions at
all times.
• If you had only one day to finish the project, what would you
rather do? Code+Test or create design documents ?


5 XP values define the team dynamics
Five core values which must be held high at all times in all actions
• Communication
– Amongst programmers,
– Between programmers and business users
– Open and accessible (same room/same time, virtual room: wiki, skype)
• Simplicity
– In design
– In planning
• Feedback
– Quick and direct
• Courage
– To change
– To estimate tasks
• Respect
– Respect the values to gain respect from peers
– Respect choices made by your team


12 XP practices support these values (1/2)
1. Metaphor
– How users express an unseen system, E.g. spread sheet, mailbox etc.
– Could also be an early protoype or an existing system
2. Simple Design
– Do not build mega structures by guessing the future (simplicity)
– Let the future unfold naturally and then act in the context.
3. Test-first/TDD
– Write (automated) tests before writing the code
– Let tests be the only documentation of your code
4. Ruthless Refactoring
– Keep improving the design by refactoring code (courage)
– Change runtime code and keep tests constant (or better)
5. Continuous integration
– Integrate often (n times a day) and make sure all unit tests pass (feedback)
– Each integration advances the system from one stable state to next stable state.
6. Pair programming
– Program in pairs: tests, design, code (feedback, respect)


12 XP practices support these values (2/2)
7. Collective ownership
– Every pair can change every program: TDD+refactoring+CI (respect, courage)
8. Coding standards
– A common way of expressing programmers intentions (respect)
9. Small releases
– Keep releasing to business users frequently (feedback)
10. Planning game
– Focus on what is of highest value to the customer at all times (simplicity)
– Re-assess what is pending and what is now most important (feedback)
– Dont change course during a cycle (1-3 week)
– Consider priorities, programmers estimates in deciding what should be done
11. On Site customer
– Writes functional tests.
– Define prioiry and feature scope.
– Give constant feedback
12. 40 Hour week
– Do not burn out, instead improve estimates
– Don’t let your team sign up for whats not possible (respect, feedback)


A day in life of an Extreme Programmer
• During planning game:
– You get to choose the task(s) that you’d want to own up, rather than Mr
Project Mgr deciding who does what.
– You get to say, how much ideal time you think a task needs, no one tells
you their SWAG. Note: ideal time is different from real time and ratio keeps
changing.
• On a typical engineering day:
– Daily 10 min standup meeting (aka daily scrum)
• What did you do yesterday, what do you plan to achieve today,
• What do you need to finish up the task, from whom
– Discuss the task with your pair.
• Review existing unit tests in the area
• Simplest design that would meet the task
– Write unit tests covering your task
• These tests should fail
• Most times they would also fail compilation: Which forces you to think of design
(design by interface)
– Write runtime code which makes these failing tests pass
– Make sure all the unit tests (old and new) pass in your workspace
– Get into integration queue (manual/automated)
– Integrate code and make sure all tests still pass
– Have a nice evening, forget the code, really forget it


Let tests be the only documentation
• Would you call up someone about the code he/she wrote a month ago to know how
it is supposed to work ? Would he/she know/remember ?
• Can all code which is under development/change be documented ?
• Word/PDF documents don’t breathe, hence there is no way to assert if they are
correct.
• It takes minutes of a programmers time to diverge from documentation (code
comments, they go though the same life: or death)
• However unit tests do breathe: they turn red/green. They talk to you in your favorite
language (which better not be english)
• Unit tests express and assert the original intentions of the author, current feature
set and known bugs.
• Unit tests act as a scaffolding when you change code. Imagine a design/code
document trying to assert that there is no divergence from it in the code
• Most times, code comments can be either replaced by a better named/refactored
method or a test which shows the pre and post conditions.
• Does not replace end-user documentation though !
• If there is time available to write code documentation/comments: better spend it on
writing more unit tests.
• Reduces the stress of carrying all the knowledge in your head: makes it easy to go on
vacation/rotation.


XP vs Waterfall
• XP is water fall… practiced in the reverse order.. Here is how
– Water fall: Requirements =>Design=>Code=>Test
– XP:Test=>Code=>Design (By refactoring)=>Requirements (by Feedback)
• However there is an order of magnitude difference in time scale.
• There is also a difference between the meaning of “test” in the two
approaches: Integration test vs. Unit test
• XPs take on requirements:
– We may or may not ask right questions to the user, but we do give them working
software early in the game to make them produce feedback. Push vs Pull, key
differentiator.
– Don’t surprize them too late, let them get used to the system and speak for you,
for a common good
• XP take on Design:
– Test First + Pair Programming => simplest design to meet today’s needs
– Refactoring +Tests=> continuous improvement in design


What makes/breaks an agile team (1/4)
• Unit tests loose value if
– they are not run frequently and by every one in dev team(no not by ‘QA’ team)
– they take too much time to run hence team fears running them
– if they fail randomly and team accepts them as “known to fail”
– Whats missing ? A will to fix the tests or may be a coach to define crisp tests
• Test first should not be misunderstood as:
– I’ll have a few tests by the time I integrate but let me write the runtime code first
– After-the-fact unit tests generally check the happy scenarios and only show an invocation pattern
• Refactoring is the art of improving design (and various “-bilities) while keeping the feature energy
constant.
• Refactoring is a big adventure/risk
– If there are no tests.. leave refactoring for SuperMan
– Don’t start refactoring unless you have reviewed the test coverage
– Better add sufficient tests before boarding the refactoring train
• Refactoring should
– Enforce DRY (Don’t Repeat Yourself): express every thing once and only once: keep normalizing your code
– become second nature to programmers
– always be preferred over conditional code (iron your cloths before wearing)
– Be part of a continuous cycIe: Tests->Code->Refactor-> and back


• Continuous integration has no/low value if it does not run unit tests
– or if the team has a habit of choosing to not run unit tests in crunch (remember value system has to be
kept high at all times )
• Dev team asserts a need for refactoring but project management pushes features (respect,
courage)
• Unlikely to see an unpaired programmer to do a fair/honest job at test first/ simple design
• Don’t let team members branch off for days to creating new functionality
– Instead define baby steps (small tasks) to reach there
– Continuous integration is the key
– Stay on a single branch as far as possible (except for release management)
• Do not create communication barriers
– between programmers
– Between programmers and users
– Keep all communication open and available (physical: same room, virtual: wikis, commonly owned chat
transcripts)
• Good IDE is important and so is good command on IDE. static code analysis,
automated refactoring are useful features e.g. eclipse. VisualStudio is still catching up.


• It is wrong to assume that productivity is halved by pairing. In fact: it improves
– Peer pressure/ peer recognition
– Some people are good at pointing mistakes
– Less chances of loosing focus to e-mail/phone/chat/facebook
– Good for bonding in team,
– Very useful for coaching new team members
– Required for collective ownership of code
• It is also wrong to assume that productivity reduces because of unit tests
– Instead it increases because of drastically reduced “break-point-driven” debugging
– It makes the programmer think in terms of class interfaces which leads to robust designs
– It continuously builds a regression protection
– It makes It easy to replace parts of the system without breaking any functionality
• Ability to quickly run all unit tests is a critical success factor
– lack of which leads to real productivity losses
– Continuously focus on “small-ness” of unit tests
– Treat tests as first-class citizens in your codebase: refactor them as needed.


• Each test is like a main() program: typical test frameworks allow you to run each of them
selectively. Compare it with the trouble of maintaining N-different tool executables (or batch
files)
– It’s a good idea to create all your tools with in the test framework itself: they keep getting exercised
during your test runs and stay healthy:
– Regular (Test) Exercise Keeps you (and your Project) healthy
• Pollination is also very important
– Cautious effort should be spent in making sure that pairings rotate
– There is a fear of developing islands of excellence: whenever we need to change inventory we look
towards tom and harry. They know it best
• Self organizing teams reflect on themselves and improve
– Hold “Review and Improve” session end of every cycle.
• Critical to have a coach/mentor/scrum master in the team
• Never forget DRY (Don’t Repeat yourself)
– XP does not mean copy/pasting code
• Having a production environment clone available for development teams use (test
and deploy) since the very beginning is also very important.
– Try to deploy to that environment as early as possible (first cycle must do)


Are Architecture and Agile two opposing forces?
There is clear contradiction in the literary meanings of the two words.. So is the common
perception.
Distinguish Architecture from Software Design-Build-Test-Deploy cycles.
• Agile methods apply to the design-build-test-deploy cycles much more than they do to define
grounds up systems architecture.
• When new projects are proposed/started there may/may not be clear guidance/agreement on
the development model. Who/when/where the development takes place is not even known
sometimes.
• An early definition of an architecture is needed to create sketches of what is required/proposed
• Stated needs=>system context =>architectural overview=>component definition
• Some of these may be software components (others being hardware/networking components).
• Build vs Buy decision in software components.
• These early architectural decisions lead to a definition of what needs to be custom built, these
decisions would also typically drive how these components communicate
• Notice nothing has been detailed on the knowledge/information/software content of this project
while there is an architecture defined as an early guidance yet
• From here on things work different ly for an XP/agile team vs a Waterfall team. UP falls some
where between them


…and then we do agile
• An agile software development team starts building the software by looking at the userstoris
within the architectural sketch ..which only bounds them in choice of platform/language/package
etc.
• There may also be metaphors, architectural templates, early prototypes etc. to jump start
• Instead of an elaborated requirements gathering/documentation/sign offs or "Designing" the
whole system, they focus on user needs and turn them into testable software in small cycles.
• One strong reason why architecture is important is : The“-bilities” of a system or to mitigate the
lack of them: maintain-bility, testa-bility, scalability…
• Architecture defines the “-bilities” and tries to solve some of them in system definition, however
a majority of it (e.g. response time, memory usage) are a direct output of the build. It is “failry-
talish” to solve them by designing . Even if you do, you need to measure(test) them.
• In agile environment, refactoring keeps evolving the software design and improves its "-bilities”
driven by the current needs of the users and substantiated by tests (performance tests here)
• In-flight architectural evolution is possible with agile but impossible with front-heavy design
approach.


Agile practices help significantly in Architectural Spikes.
They also help in evaluating new platforms/frameworks/thirdparty softwares quickly.
e.g. the Unit tests come handy when we want to quickly check if we all our features would work
in a different operating environment (windows vs linux, oracle vs db2)
Example of in-flight architectural change
• We found abc database to be too slow for the current needs of this application and we need to
move to xyz".
• It is an architectural change, and an agile team reacts to it in the same manner as it would to any
change:
a) make sure you have unit tests for the impacted area
b) refactor the code
c) implement the tests for the new feature
d) implement the feature.
• Here, refactoring the code may mean bringing in a database-adaptation-layer to make sure that
the code can sustain the change in database.
• However the basic approach remains same:
– unit-tests help you survive the refactoring,
– refactoring makes way for new features.
Summary: Architecture and Agile are two complementary forces pushing projects to
success. Agile makes it easy to fix failed initial assumptions.

Does Agile apply to only Java/.net/Ruby projects? (1/2)
• Which project would not want
– To make end users satisfy
– To take a risk mitigation approach since the very beginning
– Improve their chances of success
• What parts of today’s talk were language/platform specific?
• In general it has nothing to do with platform/language etc.
– However tools may vary in availability/maturity level
• Once you cross the fence, the other side looks too murky no matter what
language/platform you work on
• I was in the same state when I started working with DSP assembly programming after
12 years of C/C++/Java/Perl/C# and 5 years of agile
– Could not wait till the code was deployed on test-boards to know if it is working
– Wrote Unit tests directly in assembly langauge and tested all modules in place in visual editor
– Refactored assembly code by re-arranging the code into reusable macros
– A test board to run all tests and give feedback.
• Do not rule out maintenance and repair projects:
• create unit tests to reproduce bugs and cautiously invest time in developing regression test suites for
buggy/frequently changed areas.


Does Agile apply to only Java/.net/Ruby projects? (2/2)
• Do not try to do agile with >20 team size.
– It is arguable if a programming team of 40 means a project or a program
– Almost certainly it will not be coherent
– Better break it at natural fracture boundaries and run smaller close-nit teams with
pollination
– Could also be a geographical boundary, but not necessary
• Distance (onsite-offshore) should not make a communication barrier any more,
– ICT solves that (skype, video chat, desktop sharing, many different ways)
– however needs focused effort to make geo-separated teams co-operate
• Spend initial energy in choosing tools (IDE/test framework/CI Platform)
– If there is nothing available, create and use.


References
Books (must read)
1. Extreme programming explained, embrace change by Kent beck
2. Test driven development: by example by Kent beck
3. Refactoring: Improving the Design of Existing Code by Martin Fowler
More books
1. Refactroing to patterns: by Joshua Kerievsky
2. Agile Software development by Alistair cockburn
3. Extreme Programming installed by Ron Jeferries

Web:
http://C2.com: wiki run by Ward Cunnigham
http://agilemanifesto.org/
http://www.extremeprogramming.org/


Q&A


Agile Talk 30 Jul 1o2

Related slideshows

More Related Content

Agile Talk 30 Jul 1o2