Life, Liberty, and the Pursuit of Agility

I’m looking forward to the Silicon Valley Code Camp in Los Altos Hills. There are over 140 sessions planned, with a lot of great topics. If you are anywhere near Silicon valley, I highly recommend you find a way to attend. It’s free, and it goes on all weekend October 3 & 4, 2009.

You can get all the details at the website: Silicon Valley Code Camp

I’ve been to a number of Code Camp events in Southern California.  This will be my first time at the Silicon Valley event, but from the looks of it, it’s going to be a great weekend.

I’m giving two talks with Llewellyn Falco: Code Excellence for the Average Programmer, and Unit Testing the Easy Way.

The Code Excellence talk is a demonstration showing how you can get control of your code using simple techniques that guide the way to maintainable and extensible code, and can lead to a quality code design.  These techniques have been used by us to bring out of control projects into a manageable condition - the rules and practices we follow can be used by anyone, are easy to do, and lead to code that is a pleasure to work on.  We’ve given this talk all over Southern California, and no one has died yet.

Unit Testing The Easy Way: Most people have already discovered that code is easier and faster to write with unit tests. But writing those tests can take a lot of time and effort. Come learn how to write tests quickly and easily, so you can get on to what we really want to be doing: coding.   This is a very lively presentation that is a lot of fun.  Llewellyn has been doing this talk all over the place, including at the Agile 2009 conference in Chicago where it was very well received.  This is my first time helping out on this talk, so it might be a lot of fun to watch me crumble under the pressure.  Don’t miss it.

If these don’t interest you, there will be plenty that will.

So be there, October 3rd & 4th, 2009.

I’ve had the great fortune lately to have a little extra “uncommitted” time to spend exploring things that I’m interested in.  On the top of my “to be explored” list is Approval Tests.  I’ve been using it a bit over the last few months, but haven’t had time (until now) to dig deeper.

Approval Tests is an open source project with the purpose of providing a very simple way to solve some difficult testing problems.  For example, one thing that Approval Tests makes easy is to provide characterization tests for legacy code.

I use characterization tests to lock down the existing behavior of code I need to work on - in other words, it is a test that proves the code does whatever it is currently doing so that I can refactor and clean it with confidence that I won’t accidentally change it’s behavior.

I first came upon the term in Michael Feathers amazing book (Working Effectively with Legacy Code), and have commonly used mock object frameworks to implement my characterization tests.  However, that can be a complicated and time consuming process, and can sometimes require some refactoring to modify the code so it can be tested.  Usually these are very safe refactorings - but can still introduce bugs.  Another issue is that coverage is typically very localized to the method of interest and perhaps a few depended-on objects.

Enter Approval Tests:  You get a lot of bang for the buck.  For example, in one of the presentations I do (Code Excellence for the Average Programmer) I show how a real life project that had become impossible to maintain or enhance was revived using very simple code-cleaning techniques.  It only took four unit test methods of a few lines each using Approval Tests to introduce sufficient code coverage to be able to confidently work on the project.

The essential concept of using Approval Testing this way is to allow the code you want to test to produce a result that you then capture by “Approving” it (which saves it).  This approved result will then be used when you run the test to verify the results.  Whenever anything changes, the test will fail and you’ll be shown the differences.  Sounds simple, doesn’t it?  And it is!!!  Approval testing has a number of other uses, and perhaps I’ll have a chance to write about those sometime soon.   I bet you can’t wait.

I encourage you to take a look the next time you get a chance: Approval Tests.   The Approval Tests project was invented by Llewellyn Falco and Dan Gilkerson, and they invite your suggestions and help on expanding and improving it.  Also, they have a talk they’ve been doing at various conferences and code camps.  If you get a chance to see it I am sure you’ll find it an eye-opener.  The next scheduled presentation is at the Silicon Valley Code Camp, and it’s called “Unit Testing the Easy Way”.   I’ll be helping out on that one since Dan can’t make it, and I’m really looking forward to that.

Lately I’ve been partnering up with Llewellyn Falco doing a presentation we call “Code Excellence for the Average Programmer.”  The main theme is that using small steps, simple techniques, and stick-to-itivness we can produce code that is pleasant to work with.  The bulk of the talk is hands-on where we take a real project (slightly simplified) that has become un-maintainable and transform it into a thing of beauty that is once again a living project. [That is an overstatement perhaps, but it isn’t far from the intent of our talk]. We’ve presented it at 4 or 5 developers groups, and at the Fullerton Code Camp. It’s a lot of fun for me, and hopefully it has been interesting and useful for the people attending.

Happiness On The Job

One thing that really struck me during our last presentation at the SDJUG on Tuesday this week is that messy code can drastically reduce our level of job satisfaction.  Somewhere in the middle of the talk I asked the audience for a show of hands if they enjoy working in the code of their daily job.  Almost no one out of 40 or so people raised their hand.  That is, nobody was happy.  So, I reversed the question and almost everyone raised their hand.  That is, almost everyone was unhappy working in the code they spend most of their day with. 

Of course, we can’t blame that dissatisfaction entirely on the condition of the code itself, and we can’t assume that having clean code would make anyone happier.   For myself, however, I can boldly assert that I am MUCH HAPPIER when working on clean, easy to read, understandable code than I am when the code is an obscure, cluttered, and complex maze of cryptic detail.  That has one important motivation for me to learn how to make my code more readable and pleasant to work with. I figure that if I am happier in clean code, then it is likely that others will be happier as well.

Why not be happier?

So, this brings up a question (or two): Why do so many developers put up with messy code?  Why don’t we make an effort to fix things and make our life (or at least a small part of it) better?  There are certainly some constraints that seem to block us and make us feel we can’t do much to improve our code.  I often hear developers say “my manager won’t let me refactor because it is too risky” or “my boss says don’t waste time on improving the code, we need to get this out tonight!”  The fundamental problem with these “reasons” is that the result is probably not a faster fix or less risk, but the opposite: More testing and fixing, and more risk.  Still, these and many other pressures make it hard for us who are writing the code to find the path that leads to code excellence. 

A few ideas on how to make things better

That, of course, brings up the next question: What can we do about it?  How can we improve our situation and still produce under the pressures we seem to be under? 

First: Get Informed. Buy and read Robert Martin’s “Clean Code” book.  Study Martin Fowler’s “Refactoring” book.  Borrow Michael Feathers “Working Effectively with Legacy Code” and don’t return it until you have memorized it.  Get your hands on Joshua Kerievsky’s “Refactoring to Patterns”.  That is a good start.  Get the knowledge and practice your skills.  Even come to a code camp or dev group meeting where someone is doing a session on the subject, or put together your own session and present it at some local group you attend.

Second: Always leave your code in better shape than you found it. Never touch code without making it just a bit cleaner and easier to read. Stop allowing the “quick fix” to increase the clutter and complexity.  It only takes a second to improve the clarity of your code by formatting it properly, or using an intention-revealing name for a new method (and so on.)  Vow to never again add to the mess.

Third: Take baby steps.  There are many simple improvements you can make that no boss or manager can complain about.  Find out what they are and do them.

Fourth: Find like-minded co-workers and discuss this stuff with them.  A whole team working toward cleaner code can bring a more pronounced result.

Fifth: Never give up, Never Surrender.

What do you think?

In an interview you can view at InfoQ, Jean Tabaka talks about the difficulties of decision making for Product Owners on an Agile project, and an approach called RAPID Management that provides a model for being an effective Product Owner. 

Here is the link: http://www.infoq.com/interviews/Agile-Jean-Tabaka#

I have read Jean’s book on collaboration as well as articles by her, and find I always find a lot of value in her writings.  This interview is particularly relevant and useful to me this week as I am working on ideas to make planning and decision making more effective for the teams I work with. 

One thing I found particularly helpful is Jean’s comments about the difficulty some people have taking on the role of a decision maker.  Although Agile emphasizes collaborative decision making, most organizations still expect someone (that is, some individual) to take responsibility for the decisions made.  In a Scrum environment, for example, it is the Product Owner who has responsibility for decisions about what gets worked on.  

Although this pressure and stress of decision making is real, as Agilists we have an approach and some practices that help to reduce or even remove this stress.  We understand that decisions need to be made at the “last responsible moment” and that we can steer development using a toolset or practices designed to address and remove the “single wringable neck” problem. 

Practices such as:

• rapid feedback
• on-going collaboration with customers and end users
• working with Sprints (or iterations) that allow us to take on small, human digestible chunks
• regression and unit tests in place that help take the pain out of making changes
• emergent design and continual attention to technical excellence
• and so on

In the Agile world mistakes aren’t as costly as they are in a traditional waterfall project.  Because we are delivering value rapidly and visibly we can learn from our mistakes as they happen and apply what we learn in the next Sprint, instead of 6 months later during some “stabilization” phase when it is impossible to recover.  Most decisions are relatively small allowing us to move forward confidently without fear that we’re making big, costly mistakes.  We can grow our knowledge rapidly and making correct decisions becomes easier as we go. 

This is a big part of what I enjoy and treasure about Agile.  The end result is that we can make decisions with less stress knowing that we have gathered enough knowledge to make good decisions, and that no mistake is a show stopper.

Here is a link to a nice little article on the idea of Interuption Driven Development by Vikas Hazrati at InfoQ: Interruption Driven Development

Vikas discusses the situation where a team needs to work on unplanned bug fixes and other “emergencies” during a Sprint thereby diminishing the value of following the Scrum methodology.  Here is the situation he describes:

Scrum talks about having minimum disruptions during the sprint so that the team can work effectively in achieving their target. The Scrum master, is responsible for removing those impediments which might hamper the velocity of the team. However, in a practical situation, when the team is churning out deployable increments of functionality, they have to support production issues along with new feature development. These interruptions, might seem like a disruption to the team but they are important impediments to the system users and the product owner. The product owner, would not see any value in adding new functionality to the system if the existing system is not working fine.

He covers a few approaches to dealing with this scenario.  It is a good, quick read.

I’m signed up to do 3 talks at the upcoming UCSD SoCal Rock & Roll Code Camp in La Jolla.   The dates are June 28th and 29th at University of California San Diego Extension - you can get the details and maps, schedules, and etc. at the link above.

Agile Development Basics - In this presentation I cover the Agile values and principles, as well as the a little about why we need something like Agile.

A Quick Introduction to Scrum - Here I’ll present the who, what, and how of Scrum.  Scrum is one of the most common methodologies for managing an Agile effort.

Agile Coding Techniques for Legacy Apps - This talk shows various techniques for introducing unit tests and micro tests into an application that has insufficient tests.

I am planning on doing a couple of additional talks on using NMock or Mock Objects, and I’ll post the details here as soon as I get the time to sign up for the presentations.

It is always a great time at all of the Code Camps.  I’ve been to 4 or 5 in the last year, including the Fullerton and San Luis Obispo code camps - I highly recommend you attend if you possibly can!  Every Code Camp I have been able to attend has been a wonderful experience for me.   So far there are about 80 sessions, and there will probably be a few more added over the next week or two.

[This is part of my series on the Communication Problems with Waterfall]

A common flaw of many develpment documents: You can’t test them.

It is a glaring flaw of the typical document generated in software development that there is no way to know if it is correct or complete.   We can do our work diligently and honestly and still end up with a lot of mistakes, missing pieces, extra (unneeded) pieces, and misunderstandings.

It would be nice to be able to “click a button” and prove that we have collected all the requirements, and that they are exactly what the customer needs and/or wants, or even that it is what the customer THINKS they need or want.  We can’t test an ER Diagram to prove that it will result in a database that stores everything we need and nothing more than we need, and allows us to create, retrieve, and use data with all the qualities we expect.  We can’t test object models and sequence diagrams (as far as I know, anyway) to prove our design is useful or good.  Well… you get the idea.  Continue reading ‘You Can’t Test Documents for Correctness or Completeness’ »

One set of problems I have often seen with “the Waterfall” are the Communications Problems, particularly the over-reliance on communication by documents. 

Communication-By-Documentation (CBD) - What’s so bad about that?

It seems so correct and natural to use documents to capture and communicate all the details of what we are working on that it is almost unthinkable to question this practice.  But I am going to try.

The sort of documentation I am discussing here are requirement docs, graphs, ER diagrams, models of all sorts, analysis docs, architectural diagrams, and etc.  (There is a lot of etc., by the way. )  I am not saying that documentation is not needed, or that it is not useful, it is just that we have to be careful to protect our project from the problems that these documents bring with them.   Continue reading ‘Communication Problems with the Waterfall’ »

Jason and I had a great time presenting at the XPSD last night, and meeting up with the Ruby programmers later on at the Rock Bottom in La Jolla.

As far as I could tell it went over pretty nicely, and everyone really enjoyed watching Jason coding live on his laptop where the ReSharper demo license had just expired.  He didn’t let it stop him, and it was a nice demonstration of how pitiful life can be without a good refactoring tool. 

Here are the slides from the NMock2 intro presentation givn at XPSD.org on April 3rd.

NMock2_Intro.pdf

Don’t get your hopes up too much - they are just my talking points.  I hope you find them useful.

There are a number of blog posts, books, and articles that discuss the idea of “Technical Debt” in a software project. One good (and short) article on the subject is Technical Debt at Martin Fowlers bliki. (He attributes Ward Cunningham with coining the term in 1992, so this is nothing new). I’ve also heard various presentations at conferences and developer group meetings that covered this idea as well, and I find it useful as a way to think about a harmful practice that is prevalant in software development.

Here is my attempt at a description of Technical Debt:

Technical Debt is the accumulation of bad code and design that degrades the quality of a project in such a way that it is harder to maintain, enhance, and support. (That is, the code has become more rigid, fragile, opaque, and so on - which are design smells as presented by Robert Martin in his Agile Principles, Patterns, and Practices books.) Continue reading ‘Another metaphor for Technical Debt: Deferred Mainentance’ »