Life, Liberty, and the Pursuit of Agility

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 prevalent 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 Maintenance’ »

Jason Kerney and I are going to once again present our NMock2 Exploratory techniques presentation.   This time at the XPSD meeting on April 3rd.

See their site at XPSD.org to get the details on the group… or just read this which I just copied from their site:

Meeting Information & Location

XP San Diego meets the first Thursday of each month to informally discuss and exchange ideas. We feel we learn best from our peers, the merely curious, active practitioners, as well as experienced consultants, when they share their skills, knowledge, concerns and experiences. We encourage everyone to participate in our monthly forums and learn something new. We meet on the SAIC Corporate Campus from 6 PM to 8 PM; 10260 Campus Point Drive, a.k.a. Building C, in the fifth floor conference room. Please find parking on the street and check in with security in Building C before heading upstairs. See our mailing list (http://groups.yahoo.com/group/xpsandiego/) for more information.

Here is the synopsis of our talk:

“A Little Taste of NMock2 For That Smooth, Relaxing, Unit-Testing Flavor”

We’ll explore how the NMock2 library makes it easy to remove dependencies and test behaviors in unit tests, allowing you to quickly set up tests that confirm your code does what you want it to be doing.

This code-intensive presentation covers the motivation for using Mock Objects, and once we have covered the basics, we’ll show our unbelievably effective technique for using dynamic mock objects as an exploratory discovery tool for introducing characterization tests for “legacy” code (that is, code without sufficient tests as described by Michael Feathers).

NMock2 is a free, open source dynamic mock object library for .NET that can help you isolate the target and test only the localized functionality. This is very easy to do, and you can be up and running in just a few minutes. Mock objects can give you years of trouble-free pleasure that you otherwise miss out on if you don’t come to this presentation.

I hope that you can make it, or to some future meeting of the XPSD.  I always learn a lot at the XPSD meetings – the people that show up are among the best XP/Agile folks in the country. 

When I do my “Quick Introduction To Scrum” presentation  the most popular feature is a little Sprint task board animation that I put together in PowerPoint.  I got the idea from a slide from the ScrumMaster training that Ken Schwaber provides.  My main goal was to try to give a visual “time-spanning” representation of what a Sprint task board “looks and feels” like over a two week Sprint that is operating in a more or less healthy manner.    If you aren’t doing Scrum, but rather some other Agile methodology,  just replace “Sprint” with “Iteration”, and “Scrum” with “Agile” and you’ll do fine. 

I’ve converted the animation to Flash and added a little running  commentary to cover a few things about how we

Continue reading ‘The Task Board Animation’ »