tools for technical agility

© 2013 DevJam - All rights reserved.

Tools for Technical Agility


Who is this guy?

What is he talking about?

Why do I care?


Kurt Christensen

I actually write code! (github.com/projectileboy)

Software development coach

for small teams, big corporations, and everything in between

Available for purchase at:

[email protected] Twitter: @projectileboy

The Agenda:

Survey of tools and technologies

to help you achieve technical agility

(and why you care)

The Agile Roadmap!

The Agile Roadmap?


“In the South Seas there is a cargo cult of people. During the war they saw airplanes land with lots of good materials, and they want the same thing to happen now. So they‘ve arranged to imitate things like runways, to put fires along the sides of the runways, to make a wooden hut for a man to sit in, with two wooden pieces on his head like headphones and bars of bamboo sticking out like antennas - he’s the controller - and they wait for the airplanes to land. They‘re doing everything right. The form is perfect. It looks exactly the way it looked before. But it doesn’t work.”

- Richard Feynman, 1974 Caltech Commencement Address http://calteches.library.caltech.edu/51/2/CargoCult.pdf


Agile – Engineering = “Cargo Cult” Agile

If we can’t build, test and deploy (and learn from what we’ve done)

then process won’t save us!


Exercise

Two minutes

Introduce yourself to someone sitting near you

Share one thing you absolutely know to be true about writing code, or testing code,

or deploying code (and why)


Limited life experience +

Overgeneralization =

Advice

- Paul Buchheit, creator of GMail


Imagine it’s four years from now, and you have to make a change to a system you built

four years ago…

…would you want this?

(with XML configuration files at every step!)

• Easy to understand • Easy to change (add/edit/remove) • Automated tests • Automated deployments • Environments in which to work and test

…and so on. In a nutshell: simplicity

Very few parts, very simple parts

What would you want?


“My whole life was basically trying to optimize things…every time you save parts you save on complexity and reliability, the amount of time it takes to understand something. And how good you can build it without errors and bugs and flaws.”

- Steve Wozniak


Typical Enterprise Tech Stack

• HTML / CSS / Javascript • Java (Java) or .NET (C#) • Multiple, heavyweight frameworks • Relational database

– Oracle, SQL Server, etc.

• Enterprise service bus • Dedicated data center

– In-house or managed


Agile Enterprise Tech Stack

• Responsive UI • Dynamic languages on hosted platforms • Small, simple frameworks • Document databases • Open APIs and third-party services • Cloud-based virtual servers


So is this just about bright shiny objects??

No.

The Technical Agility Roadmap

…we’ll start with the principles underlying Extreme Programming:

Communication Simplicity Feedback Courage Respect

The Technical Agility Roadmap

• Communication – Code (language), tests, tools, systems

• Simplicity – Habitability: small, replaceable, easy-to-understand

• Feedback – Metrics (complexity, performance, etc.), logging

• Courage – Practice, and a supporting environment

• Respect – Respect for customers, respect for executive sponsors, respect for

support and ops, etc.


Technology Stack

• Java (Java, Groovy, Clojure, Scala, etc.)

• .NET (C#, VB.NET, F#, etc.)

• Rails (Ruby)

…and so on (Django (Python), etc.)

Many (most?) enterprise apps could be implemented with smaller, simpler technology stacks


But how do we get there?

• Try piloting with a small, internal project • Context matters!

– People: if everyone in the organization only knows Java, Groovy and Grails might be better than Ruby on Rails

– Existing technology: if everything is on a JVM, consider a lighter framework and language that runs on the JVM


Language

“I’ll begin with a shockingly controversial statement: programming languages vary in power.”

- Paul Graham, “Beating the Averages” http://paulgraham.com/avg.html

http://paulgraham.com/avg.html





• Start with the unit tests – Java Groovy, JRuby, Clojure, etc. – .NET F#, etc.

– Controlled experimentation!

• Other options: – Explore language features which you aren’t

using (e.g., C# lambdas) which provide value – Start with small, non-critical modules or

applications


Version Control and Workflow

• Centralized version control systems – Subversion, Perforce, ClearCase, etc. – Workflow for a team is largely dictated, but you still

must determine workflow across multiple teams!

• Distributed version control systems – Git, Mercurial, etc. – More powerful, more complicated – GitHub can add additional value



• For each team and across teams, you MUST establish and socialize the workflow – The more dysfunctional the culture, the more you’ll

need formal branching and merging strategies

• Don’t assume people know how to use your version control system properly! – Get training if needed

• Teams trying a new version control system can first try using it on top of the existing VCS – e.g., git-svn


Automated Testing

• Unit testing and integration testing – Java: JUnit, TestNG, Mockito – .NET: MSUnit, Nunit, Moq – Javascript: QUnit, Jasmine, etc.

• Behavior testing – Cucumber, etc.

• UI testing – Selenium, T-Plan, Eggplant, QTP, etc.



• Start with defects – Learn the tool AND grow the culture!

• Include tests as part of the automated build • Test-drive new functionality • Pair test-infected developers with QA testers

to automate QA tests • Treat your tests like you treat your code • Culture! (“Show me the tests…”)


Continuous Integration

Build Automation • Ant, Maven, Gradle, Rake, etc.

Continuous Integration Servers • Jenkins, TeamCity, Anthill Pro, MSBuild

Continuous Integration Continuous Delivery



• Writing a build script is easy! (Keeping it under control is harder…)

• Setting up a CI server is easy! (Getting anyone to care about its output is harder…)

• Culture! (People need to care)


Automated Environments

Our automated build assumes we have an environment into which we can deploy. How do

we automate the creation of environments? • Chef (www.opscode.com/chef)

– Seems friendlier to developers

• Puppet (puppetlabs.com) – Seems friendlier to system administrators

http://www.opscode.com/chef



http://puppetlabs.com



• One approach: start with local development environments and work your way up towards production

• Alternate approach: go after the most painful problems (often QA environments)

• Create a DevOps cross-functional tiger team to go after these issues

The root cause of many software development problems

is a lack of automation


Courage

- Practice makes permanent ! - Good habits help (refactoring, pairing, TDD) - Automation provides support

Respect

- Respect for those paying - Respect for those who will maintain - Respect for our teammates


Impossible?

Q: How much traffic does craigslist get?A: More than 50 billion page views per month Q: How many employees does craigslist have, and where are its offices located?A: 30-some craigslist staff work at offices located in San Francisco, CA

- http://www.craigslist.org/about/factsheet


Tools do not create culture

(much of craigslist is written in Perl!)

…but tools can act as a catalyst

towards creating a better culture (and process is a tool!)


Additional Tools

• Optimizely (A/B testing) • Google Analytics (general analytics) • Chartio (reporting on top of Google Analytics (and

more)) • Splunk (logging and monitoring) • New Relic (intelligent logging and monitoring) • Amazon Web Services (virtual services) • Heroku (virtual technology stack) • MongoHQ (virtual database)


Exercise

Two minutes

Introduce yourself to someone sitting near you

Share your biggest technical constraint, and one tool or technique from this session

that you could use to address it


Recommended Reading

• Continuous Delivery, Humble & Farley • Continuous Integration, Duvall, Matyas & Glover • Refactoring, Martin Fowler • Working Effectively with Legacy Code, Michael Feathers • Extreme Programming Explained, 2nd Ed., Kent Beck • Test-Driven Development: By Example, Kent Beck • How Google Tests Software, Whittaker, Arbon & Carollo • http://paulgraham.com/articles.html • http://www.foundersatwork.com/steve-wozniak.html • Seeking Wisdom, Peter Bevelin • Surely You’re Joking Mr. Feynman!, Feynman & Leighton

http://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912

http://www.amazon.com/Continuous-Integration-Improving-Software-Reducing/dp/0321336380

http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658



http://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530

http://www.amazon.com/Google-Tests-Software-James-Whittaker/dp/0321803027

http://paulgraham.com/articles.html

http://www.foundersatwork.com/steve-wozniak.html

http://www.amazon.com/Seeking-Wisdom-Darwin-Munger-3rd/dp/1578644283

http://www.amazon.com/Surely-Feynman-Adventures-Curious-Character/dp/0393316041


Questions?

[email protected] www.devjam.com

mailto:[email protected]

http://www.devjam.com

tools for technical agility

Documents

technology stack java

agile roadmap

unit tests java groovy

respect forsupport

etcnet c

enterprise apps

multiple teams

agile engineering