Tools for Technical Agility
-
Upload
versionone -
Category
Documents
-
view
599 -
download
2
description
Transcript of Tools for Technical Agility
© 2013 DevJam - All rights reserved.
Tools for Technical Agility
© 2010 DevJam - All rights reserved.
Who is this guy?
What is he talking about?
Why do I care?
© 2010 DevJam - All rights reserved.
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?
© 2010 DevJam - All rights reserved.
“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
© 2010 DevJam - All rights reserved.
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!
© 2010 DevJam - All rights reserved.
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)
© 2010 DevJam - All rights reserved.
Limited life experience +
Overgeneralization =
Advice
- Paul Buchheit, creator of GMail
© 2010 DevJam - All rights reserved.
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?
© 2013 DevJam - All rights reserved.
“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
© 2013 DevJam - All rights reserved.
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
© 2013 DevJam - All rights reserved.
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
© 2010 DevJam - All rights reserved.
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.
© 2013 DevJam - All rights reserved.
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
© 2013 DevJam - All rights reserved.
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
© 2013 DevJam - All rights reserved.
Language
“I’ll begin with a shockingly controversial statement: programming languages vary in power.”
- Paul Graham, “Beating the Averages” http://paulgraham.com/avg.html
© 2013 DevJam - All rights reserved.
But how do we get there?
• 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
© 2013 DevJam - All rights reserved.
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
© 2013 DevJam - All rights reserved.
But how do we get there?
• 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
© 2013 DevJam - All rights reserved.
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.
© 2013 DevJam - All rights reserved.
But how do we get there?
• 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…”)
© 2013 DevJam - All rights reserved.
Continuous Integration
Build Automation • Ant, Maven, Gradle, Rake, etc.
Continuous Integration Servers • Jenkins, TeamCity, Anthill Pro, MSBuild
Continuous Integration Continuous Delivery
© 2013 DevJam - All rights reserved.
But how do we get there?
• 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)
© 2013 DevJam - All rights reserved.
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
© 2013 DevJam - All rights reserved.
But how do we get there?
• 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
© 2010 DevJam - All rights reserved.
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
© 2013 DevJam - All rights reserved.
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
© 2010 DevJam - All rights reserved.
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!)
© 2013 DevJam - All rights reserved.
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)
© 2010 DevJam - All rights reserved.
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
© 2013 DevJam - All rights reserved.
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