Life, Liberty, and the Pursuit of Agility

I love Document Driven Development

One thing I really miss in Agile is having long, incomplete, boilerplate documents for me to “sign-off”.   I like to write code and deliver working software quickly, but even more I LOVE to read documents and like nothing better than to spend long days before a glowing flat-screen reading incomprehensible nonsense carefully crafted to appear complete and correct while still being essentially content-less.  Doesn’t matter what they are about, as long as they have small type and lots of words.  Of course, nothing is further from the truth.  If I want to read nonsense then I’ll read Edward Lear.  Or my own writings.

So documents are fine, but what about Sign-offs?

Even more, I love to take responsibility for documents that I did not write.  It gives me the feeling that I am a grown-up.  But apparently, I am very unsophisticated regarding sign-offs.  Or I was until recently…

I had one CEO show me the policy for documents at his organization (let’s call it “Anonymous Inc”) where there were 3 sign-off statements for a manager to sign on any document requiring her approval.  Oh joy!!!  It is in the spirit of Extreme Documents, I suppose.  If one signature is good, why not dial it up and try three?  More is always better.  In his defense, he was showing this to me as an example of something he wants to abolish - he understood the absurdity of it.

I approve this document

This typical sign-off is for the manager-type to “approve” the document.  In software development this often indicates that others can rely on this document as being “okay to use for doing whatever it is they do next based on this document”, and that it is Complete and Correct.  This is actually the third signature to apply after the next two required signatures have been taken care of.

I have read this document

At Anonymous Inc, besides approving the document you are also required to sign-off that you have read the document.  You’d think that approving something implies that you read it.  Guess what?  Apparently this isn’t as common as you might think, at least not at Anonymous Inc.  I suppose the “I have read this” signature solves the problem of someone later on saying “I just signed it, but I didn’t read it - if I knew what was in it I would not have signed it”.   I suspect that a lot of documents get “approved” without the approver having actually read it, and VP’s and upper management can always say “I was so busy I had my underling read it - he said is was okay so I signed it.  Let’s fire him, okay?”

I understand this document

Okay - “I approve this document” might make sense in some organizations.  ”I have read it” at least keeps some people a bit more honest, I suppose - I’m not sure it would.  But “I understand it” is something I just do not understand.  Still, it is a very fun idea, and Anonymous Inc is all about fun.  Still, just because I say “I understand” doesn’t mean I do.  Any parent knows that.  “I understand” can also mean “shut up already”. But then, what do I know? 

Have fun out there, and be careful when you sign-off.

Estimating Software Development

Anyone who knows me will know that the title of this post is meant as a joke.   For software development, it is my experience that estimating is rarely useful and always easy. 

Well… a little clarification:  estimating is NEVER useful but ALWAYS easy the way I have typically seen it done, which uses the WAG* method of providing some numbers that seem plausible and that will allow the decision makers (stakeholders and managers) to approve the start or continuance of a project with a clear conscience. That is, when things sour later on they can always blame the developers for giving them inaccurate estimates.  And the developers can always blame the “requirements people” for giving them unclear, incorrect, or incomplete requirements.  And the requirements people can always blame the stakeholders for providing bad direction about what was important, and so on.  Regardless of who is part of this process, it is one big happy circle of blame that lets us all do the wrong thing and still keep our jobs (not always happy for everyone, actually, and sometimes not everyone will keep their job).  I have simplified it here, but the basic idea is sound.  As long as everyone is good at deflecting blame, and everyone is willing to continue on saying we’ll do it better ”next-time” and after only a few people have been fired then everything is fine, right?

Let’s estimate a game of chess

Chess is a game that some of you may have seen.  It provides a very limited environment with only 6 different and charming pieces that have very limited ways in which they can be used, and there are only two players.  Simple. The whole game can be contained in an area of about a square foot or even less, and the complete rules can be written on the inside of the box lid.   Just like Candy Land, it is very easy to learn and play. Not so easy to win, perhaps - but that makes it interesting enough to be an engaging game for some.

So, here is a description of a simple “project” and I need your estimate:

Win a game of chess. Losing is not an option. Tying is not an option.  We will only make money if you win.  If you don’t win, the company is at risk, and you will lose your job (and mine).

Also, I have a diagram of a chess game with the exact position of the pieces as required at the end of the game.  To make money, it needs to end up just like the diagram.

Oh, one other thing: we don’t know yet who you will playing, but we’re pretty certain it will be someone who knows how to play the game, and might be pretty good at it.

That’s it!  There are only a few requirements:  That you win, and that the board matches the diagram I’ll give you.  Easy! 

What I need to know is exactly how much this will cost me.  In this situation, cost is the number of moves you’ll need to meet the requirements.  Oh, also, we don’t have the diagram yet, but we’ll have it soon.  Still, you should be able to estimate it because it is basically the normal chess end-of-the-game arrangement with pieces here and there and so on, and you have the opponent in a checkmate.

Should be easy to estimate that, right? 

Well, I hope you agree this is impossibly difficult.  Or actually: just plain impossible.  First of all, there is not enough information to do a good estimate, and even if we had all the information, there are many variables and a lot of stuff we have no control over. How close do you think your end results would come to the requirements?  Would you be willing to stake your job on making a decent estimate on a chess game in this situation?  Well, as long as you could blame someone else and promise to “all do better next time” you’ll probably be okay.  Or you could be a consultant and be paid and off to your next contract before someone actually has to play this game you helped them estimare.

Getting better at estimating is like pulling teeth

I hear it over and over:  Our estimates were not accurate and we had a lot of trouble because of that.  We need to get better at estimating. 

It is similar in a way to saying “My tooth hurt, so we pulled it out.  Now I can’t chew as well as I used to.  We need to get better at pulling teeth”.  What is the real problem?  Shouldn’t we work on that instead?  Hint: Getting better at pulling teeth is not it.

So what would you do to get better at estimating the game of chess, based on the basic scenario we described above?   Could you get better at it?   How good would you have to be before it had real value? Is it worth spending time on getting better at it?  What is the real problem.  Hint: Getting better at estimates is not a solution to anything because having bad estimates it not the real problem.

My suggestion: Stop That! 

I haven’t seen much value in estimates.  Actually, in the software development work I have done, I can’t recall any situation where estimates were of value to the actual job at hand.  Someone wanted them, someone saw value in them, and sadly - important decisions were made based on them.  Do you think those were good decisions?  People often tell me that “even though we know the estimates are inaccurate, they are better than nothing”.  I prefer nothing.  There are better ways.

Almost everyone tells me that estimates are very important, but estimates are actually a blind spot hiding something of actual importance and value.  This almost universal acceptance that estimates are important and useful is harmful.  A predictive approach such as waterfall itself depends on estimates - and estimates are how we make the predictions.  Don’t think “waterfall” and predictions are harmful?  You probably should be reading some other blog.

Estimates are based on guesses about the time needed to do work we don’t yet understand.  Noting about this gives me confidence that the estimates have value.

It seems I always make enemies when I suggest this, but that is not my intention.  I want to do effective work on meaningful stuff - that is my intention.  I don’t want to be spending time on work that has no value, that causes misdirection and waste, and potentially destroys any chance of being effective.  That is painful.  There are MUCH BETTER WAYS to approach software development. 

Do you need estimates?

It could be useful for you and your organization to question your use of estimates and explore new ways to think about your “need” for estimates.  What does a heroin addict “need”?  Does he/she “need” heroin?  What do you think? 

One last thing:  Do not ask me for an estimate on how long it will take to eliminate estimates from your process.  It is too much like a game of chess, only very complicated.

Here is a start at clearing up our thinking.  Let’s do a little thought experiment.

Which would better help if we have decided to eliminate estimates and find a better way in our organization? :

• Get rid of all upper management.
• Get rid of all developers
• Get rid of all upper management and developers
• Something else more realistic

Who is most insistent that estimates are important?  Who do those people answer to?  Are those people actually good at anything?  Are they going to fire you if you say things like this?

So what might be better?

What can we do instead of doing estimates?

Nothing.  Don’t do estimates.  Simple, clean, easy. 

The correct question is: since we think that estimates are important, and you say that they are not, how can we develop software without doing estimates?

The answer is… Well, I suspect no one reads this blog, so that doesn’t really matter.  This is just a clearing house for my thinking and has nothing to do with the reader.  However, I am sure to write some stuff someday about ways to get things done without estimates, and I guess some of my earlier posts cover some of this thinking. If someone is actually interested and asks for me to cover this, I might get to it sooner.  But I am sure you can figure it out without me - this is truly simple stuff.  Read the Agile Manifesto and Agile Principles, and use them to invent better ways.

Another hint: Get good at frequent incremental delivery of useful software.  That might be worth considering.  That takes a LOT of experience and open thinking.

NOTES:

* WAG = Wild Ass Guess.  A Wild Ass is a beast that is indigenous to parts of Africa and Asia.  A Guess is a guess.  Wild asses are about as good at making software estimates as anyone else.

Requirements Gathering

In the traditional phased SDLC approach, a phase for  ”Requirements Gathering” is done very early on in the process.  We can argue about all the issues with this some other time - I am just covering one issue here. 

My opinion of this “phase” is that it is pretty much worthless: THERE IS NO WAY TO PROVE THAT THE REQUIREMENTS WE’VE GATHERED ARE COMPLETE AND CORRECT UNTIL WE HAVE WORKING CODE.  Working code, in this sense, means code that is actually being used to do real work for the real users.  Does that make sense?  If not, you probably don’t want to read on, and probably shouldn’t bother reading anything I have ever written or will someday write.  Plain and simple.  

Requirements Hunting and Gathering

One issue is that requirements will rot if not used promptly after collecting them. 

Early humans are thought to have used a subsistence strategy where they hunted and gathered (and scavenged and stole) their food for immediate use.  If the food was not eaten shortly after it was obtained, it would rot or otherwise become useless.  The food needed to be put to work within minutes or hours, or at most a few days.  Otherwise, the effort of hunting and gathering would go to waste.

Just like the early hunter and gatherer folks, we have no way to “preserve” the requirements we’ve gathered.  We don’t even know if they are edible.  And yet we store them for a long time, and do a lot of work with them during that time, and base a lot of decisions and work on them (like estimates, budgeting, designs, architectures, ramping-up efforts, coding, testing, marketing, and so on) and all the time the requirements are rotting.  

It isn’t until the code becomes true working code that we can get real information about the correctness and completeness.  Until then everything is just assumptions and guesses.  Unfortunately, by the time we learn that the requirements have indeed rotted it is too late.  They have become toxic, wasting our money, time, and effort, and killing the usefulness of the project they are supposed to define.

Early Humans understood this, and therefore rarely wrote software, and never ate mayonnaise that had not been “refrigerated after opening”.  Fortunately for Late Humans (us, that is), someone eventually figured out how to preserve foods so we could buy and eat them days, months, or years and years after they had been plucked, prepared, and packaged.   However, to this day, I have seen no way to preserve requirements.

Requirements MUST be used while fresh

So, my recommendation is: Eat your requirements as soon after you have picked them as possible.  Between the garden and the kitchen they have already started to lose their sweetness.  [Please imagine that there are many other very funny food based metaphors here.  I am not having trouble coming up with them as such, they just don’t seem all that meaningful, and they aren’t as funny as I thought they would be].

How do you do this with software?  You use a very short “discover, define, code/review/re-discover, deliver, discover more, repeat” approach during which we are continually discovering what it is we really need to do:

1. Keep your requirements at a very high and general level until just before use.  Details in the requirements are a smell of the rot.  Pay attention to that.  Understanding the business need is important, details about how that translates into software is not.
2. Pinch off a small but useful bit of one of the high level requirements - preferably something of immediate and high value to the end user, but anything of value will do. 
   • Find something that you have a pretty good chance of turing into working code quickly - in a day or two if possible.
   • Prune as you go as needed. 
   • Identifying small bits, pruning as you go, and getting something of value quickly are skills you must aquire.  It takes practice, dilligence, and close attention. 
   • You don’t have to understand the requirement completely - you will discover the details and what is important as you code it up while partnering with the business experts/users.
   • Prioritizing is useful - you want to take on features in a prioritized manner, but don’t go overboard on this - close enough is close enough.  We’ll talk about this some day.
3. Code it up.  The code-it-up process is not just coding - we must work closely with the business people discovering the details as we go. 
   • Code some tiny bit the business expert can see and use (click a button, see a list, choose an option, whatever)
   • Get her feedback, comments, and direction continuously - early on and frequently - every 10 minutes to 2 hours.  Every time you have something meaningful you can show get it in front of the business expert. 
   • Sitting side-by-side works well when appropriate, but if that isn’t practical at least be within shouting distance. 
   •  If you go longer than 4 hours without getting useful feedback you are wasting your time and need to learn how to work in smaller chunks.
   • You might discover you have completed some small but deliverable bit of funcitonality that is just a part of what you had chosen to work on.  If so, then deliver it, and go on to the next bit.
4. Deliver it.  That is - put the code into actual use with actual users. 
   • You’ll discover more things about it as the users use it.
   • This will help expose the next thing to work on.  The real next priority.
   • If they don’t use it once delivered, you’ll have learned something else of value: It wasn’t of value. I’ll cover that some other day - but that is a magical and very valuable bit of knowledge to gain early.
5. Do it again tomorrow (or today, I suppose) with another bite-size chunk of functionality.  
   • You are now steering the project toward the best possible result given the abilities and knowledge you and your team have.
   • Important things will become apparent and be added to the working code in a prioritized manner.
   • Useless things will show themselves or be ignored and you’ll waste as little time as possible on them. 
   • You’ll get better and better at it.

Following this approach the requirements will not rot because you leave them “on the vine” until you are ready to eat and digest them.  Of course, what comes out after the eating and digesting is not covered in this article:  At some point all analogies break down.

I’ve signed up for a few sessions at the SoCal Code Camp at USC in Los Angeles.  The dates of the camp are October 15th & 16th, and I will probably be there both days.  There are about 87 sessions listed so far, so you are sure to find something of interest.

Here are the sessions I am doing:

• Coding Dojo Part 1 - Hands on “mob” programming
• Coding Dojo Part 2 - Hands on “mob” programming
• Code Excellence Part 1 - Demonstration of cleaning, refactoring, and improving working code
• Code Excellence Part 2 - Demonstration of cleaning, refactoring, and improving working code
• Agile Success - An Introduction - An interactive discussion of how to make Agile a success for your project

I hope to see you there… whoever you are.  Let’s talk Agile and write some code.

Losing Interest?  Refill Your Cup Before it is Too Late

A boss of mine once said to me ”I wish I had your passion and interest in coding - I lost that a long time ago”.  I think that is kind of sad, especially if you make your living making software.  I don’t think I could spend each work day doing something I was bored with - but of course, a lot of people do that, and I’ve worked with a lot of programmers who have lost interest in programming.  Seems they were once interested, and now they no longer are. 

Perhaps I’m just naturally interested in programming and can’t help myself, or maybe I have a mental disorder - but I seem to be able to stay engaged and still enjoy programming every day. I think part of the reason I keep my interest is that I continuously “refill the cup”.  When I sense I am starting to loose interest (or even long before that) I look for a way to refill the cup. 

One note: I don’t really think it is ever “too late” to regain interest.

I’d like to share a couple of ways that work for me: Intentional Practice/Effortful Study, and Programming as a Social Activity.

Intentional Practice and Effortful Study

My friend Jason Kerney did a talk on Intentional Practice at the San Diego .NET Development Group back in March.  I have a lot of respect for Jason.  He has an infectious passion for programming, clean code, and continuous improvement and I always learn a lot from him.

I had talked with Jason about this idea and like it a lot:  It’s important for us programmers to intentionally practice our craft.  I remembered reading an article on the topic somewhere, and tracked it down at Coding Horor: http://www.codinghorror.com/blog/2008/06/the-ultimate-code-kata.html. In this article from 2008 Jeff Atwood quotes an article by Steve Yegge (from 2005) called Practicing Programming.  You can read this article at http://sites.google.com/site/steveyegge2/practicing-programming. Steve refers to some other articles, and I think if you follow the references in those articles you eventually end up at Kevin Bacon - but you know all about that.  With all this great stuff already written about practicing our coding craft I won’t have to regurgitate that here.

Anyway - Jeff quotes a Scientific American article that uses the term: “Effortful Study”.  I like that, and suggest you read that article too, and then tell me what it is about.

I’ve been meeting up with a few friends at work, at code camps, and remotely during the last few years to intentionally practice programming.  We engage in effortful study to focus on very simple things that lead to code excellence. I have been learning a lot.  Hovever, even more imortant to me is that I feel rejuvinated after these study sessions.   Some of the Katas have been very simple, others have been very complicated.  Sometimes we move quickly to a good solution, sometimes we flounder about and don’t get anywhere.  Regardless, I have a great time interacting with my fellow programmers and find I’ve refilled my cup.  And that is the concept I call:

Programming as a Social Activity Just for the Fun of it

People get together to watch sports, go on bike rides, have dinner, go to movies, play games, get drunk, and lots of other fun stuff JUST FOR THE FUN OF IT.  Programming can be done the same way.  Two people or a whole group of people.  You can do simple Kata exercises, complicated code jam style contests, work on some Open Source project of mutual interest.  Whatever.  A friend of mine (the brilliant and dynamic Llewellyn Falco) used to have “Monday Night Programming” get togethers every week at his house.  What a great idea!  

I don’t know how or why this works for me, but it does - every time I do one of these code dojos or attend a coding gathering, or some similar activity it definately stimulates my interest in the work I love to do: programming. 

It might not work for you, but I love it.  Next time you run into me let’s sit down, open up the laptop, and code something - what do you say?  Come on, it could be fun.

What I did last Thursday and Friday

Last week I was able to spend two days at the AOSoCal 2011 event with 70 other Agile enthusiasts who are all practicing, thinking about, coaching, consulting, and working with Agile Software Development.  I had a great time, learned a lot, made a lot of friends, and can’t wait for the next one.

Like I said several times at the event, I felt surrounded by friends the whole time.  These are the sort of people I would hope can attend my funeral to balance out the other folks who will be there to gloat and trash-talk me.  Do people still say “trash-talk”? 

A little about Agile Open, and Open Space

Each Open Space event has a theme that defines the purpose of the gathering.  Our theme for AOSoCal 2011 was People, Principles and Performance.  That’s pretty wide open.  However, unlike many typical conferences, an Open Space event is invented by the people who show up. The sessions are not scheduled until the morning of the event. 

Everyone gathers in a circle, and the participants propose session topics by writing the topic on a piece of paper and announcing it to the gathering.   Typically, the proposer takes responsibility for the session, choosing a time and space to hold the session, and later facilities the session.  One by one the event schedule it built, and once that is done everyone selects the first session they will attend… and then off we go - the Space has been Opened.  Sessions can be added at any time, and some get combined or morph into something completely different.  Overall it is a very dynamic process.

You can learn more about the process at Open Space World, or at the Agile Open site, or the Agile Open California site, and about the AOSoCal event specifically at the AO Southern California site.

So what is it really like?

From my description it might be hard to get a picture of how this all works - but it does work, and rather nicely.  I encourage you to attend an Agile Open event - they are generally very inexpensive and then you could easily experience it for yourself.  All the people I’ve talked to who have attended these events have been very pleased they were able to join in. 

I have been to a variety of Open Space events and the details vary from one another - but overall I get a lot more of what I want from a conference than I ever get at the more traditional conferences.  One thing I have especially enjoyed is that the sessions are engaging, personal, and interactive - I find this keeps me energized throughout the entire two days.  Most sessions keep things lively using facilitated (or non-facilitated) discussions, hands-on activities, or interactive techniques of some sort.  I love that I get to spend a couple of days continuously interacting with fascinating people who are discovering, learning, experimenting, living, and inventing what Agile Software Development is all about.  How is that for a poorly formed sentence?

In addition, there are endless opportunities to just sit and talk, pair program, or take a walk (or whatever) with other attendees.  Overall, a lot of fun.

So, that is what I did last Thursday and Friday

Cheers!

Written: May 26, 2011

NOTE: This article relates to the domain of software development.  Nothing else.  Also, the idea of failing early, fast, often, and better does not apply in all situations.  Use with caution.  However, it has been very useful for me in software development, and I can recommend that you try it out.  Otherwise, leave me alone, okay?

Failure and Mistakes are a Valuable Part of Software Development

We are going to make mistakes, misteps, and “failures”.  It’s part of the process.  We need to recognize failure as a valuable learning and steering opportunity.  Here are a couple of quotes on mistakes/failures:

“Mistakes themselves are often the best teachers of all.” - James Anthony Froude -

“I have not failed. I’ve just found 10,000 ways that won’t work.”  - Thomas Edison -

That is pretty clear, I think.  If we buy into the idea that failures can bring value, we might want to focus on ways to increase that value - it’s just another application of the concept of “Extreme Programming” - if something brings value, let’s figure out a way get the maximum value for the time and effort spent.  Make sense?

Fail Early

If we believe that we can learn from our failures then let’s start the learning.  The sooner we have a chance to fail, the sooner we get the benefit of the learning that comes with it.

How do we fail early?  Take action and make something small (but useful) right away, and immediately deliver it to the the customer (or user, or whoever) and get real and useful feedback.  Dig in, do something of value, see what works and what doesn’t, learn from it, adjust our course, and march on.

I have seen this quote of Napoleon about his basic military strategy: “On s’engage et puis on voit” which I am told means “I engage and then I see”.  This might not work in all cases but has worked very well for me in software development.  I shorten it to “Engage And See”.   [N.B.: Unlike Napoleon, please attempt in all cases to avoid a disastrous winter campaign in Russia.]

Fail Fast

We want to fail fast so we can learn in a matter of minutes, hours, or days rather than weeks and months (or never).  There are lots of ways to approach this in software development.  One great example which can give us “instant” results is TDD (Test Driven Development/Design).  Before we write any code, we write a failing (and very small) test.  Of course, there is more to it than that - but for my purpose in this article, the key is ”VERY SMALL WITH INSTANT FEEDBACK”.  With TDD, the test fails immediately, which is about the shortest feedback loop as we can have.  Once the test is working, any time we work on our code we will run the tests and learn immediately when we have broken something that was previously working.  Instant feedbcak.

This instant feedback is great, but we can’t get instant feedback for everything.  However, what we CAN do is find a way to take very small steps that lead to useful feedback as quickly as possible for everything we do.  For example, the “business people” should work directly with the programmers and round-trip each step/task/feature continuously - let’s work to get this feedback in a few minutes rather than having a meeting every two weeks. You get the idea.  For every aspect of the process we want to minimize the time it takes to discover we have a mistake.

Fail Often

Once we are good at the failing/feedback/learning loop, we can ramp up the learning by failing a lot.  The more things we try, the more failures we might have, the more chances to learn and steer.  We are NOT after failure for failure’s sake.  We ARE after the good things we can learn by trying things that stretch our abilities and understanding.  Another benefit is that we waste less time working on the wrong thing.

I’ve often seen it that a little step towards what the user needs will lead to a change in direction to a better result for the next “chunk” of work.  Sometimes it can lead to a complete about-face where the customer all of a sudden realizes they want to go in a completely different direction, which is also very valuable.  And of course, they most often say “that is great!  it’s exactly what we wanted”.  Well…

Anyways - if one failure is good, lots of failures can be better.

Fail Better

So: early, rapid, and frequent opportunities to fail is good.  All that is left is to find ways to maximize the results of each learning opportunity.  Inspect and adapt.  Here are a couple of ideas:

Finding better ways to communicate feedback is one area worth improving.  For example, sitting side-by-side with the customer to do a hands-on walk-through of a new feature might be (and generally is) more productive than a “shared screen” online session, and is way better than traditional demos.  Being with a real user while they really use the project is the best.   Try it.

Another area we can explore is how to expose hidden requirements.  These are the things that in traditionally managed projects the ”requirements gatherers” and customers have trouble capturnig in a document and eventually lead to BIG failure at the end of a long death march style effort. Fun! One approach we can follow is to ”take a stab at it”.  If there are things we don’t understand we can often get clarity quickly by coding up what we currently understand and getting it into the hands of a user.  This will often result in something that is close to (but not quite) what is needed - and will allow us to discover the right path.  I am talking about doing real code that does real things for the purpose of showing us where we have a “failure to communicate” - clarity ensues.

Conclusion

Anyways - these are just a few thoughts that will hopefully lead to further thinking and improvement in our ability to make progess through failure.  That could be my new motto: “Progress Through Failure For A Brighter Tomorrow.”  Well, probably not - but… you get the idea.

One Last Quote:

“Agile doesn’t prevent us from making mistakes, it gives us a way to reduce the cost of those mistakes.” - Llewellyn Falco, paraphrased

Robert Martin recently posted a paper titled “What Killed Waterfall Could Kill Agile”.  It’s a pretty good paper and (as I hope all three of the people who actually read this blog knows) I have tremendous respect for Bob Martin.  He’s the best. I recommend his books all the time and at all the talks I give.  BUY HIS BOOKS, READ THEM, PRACTICE THEM, AND APPLY THEM.
 
I have read the “What Killed Waterfall Could Kill Agile” paper, and I am not in complete agreement with Bob’s assesment of things regarding how Agile might be Killed, Waterfall’s death, and so on.  I bet those of you who know me saw that coming, and you are excused from reading the rest of this post.
 
Here are a few of my thoughts, without going into too much detail:
 
1 - The problems with Waterfall are many, and elitism is just one of them.  The Waterfall/Traditional/Phased approach (Known as WTPh!, but pronounced WTF!) doesn’t work well for a lot of reasons, but Martin seems to say that elitism is THE problem with Waterfall, and the reason it has failed.  I hope I misunderstood that.  A much more fundamental reason WTPh! fails is because the deep ineffectiveness of the phased model, which we’ll cover next semester in “Why Waterfall Fails”.
 
2 - Elitism, and the problems that it brings did not “Kill” waterfall.  Nothing has, and it will be a long time before it can be declared dead.  Believe it or not, waterfall is still very much alive as a process (I am sure you know this).  I talk to a lot of developers and managers, and regardless of what they call it, many are still using a process that is more aligned with Waterfall than anything else.  WTPh! seems so logical and correct that it is almost against human nature to think it won’t work.  It will simply keep cropping up no matter how low you mow it, pernicious weed that it is.  Remember the famous quote (repeated here, word for word): All it takes is for good men to do nothing, and vois la: you get waterfall!
 
3 - Agile won’t be “Killed”.  Agile provides good results when applied appropriately (or so I have found, anyhow).  Those of us who have had success with it will continue to use it, learn more, grow it, and continue to have success with it.  Success is what makes Agile attractive.  (I am grouping the basic concepts of Agile/Lean/XP when I say Agile). It will change, but I would be surprised to see it change to where the core of it has been replaced.  But I do like to be surprised, so when something better comes along, I’ll want to know about it, try it, and adopt it.
 
4 - Agile is not Scrum, and Scrum is hardly Agile (at least as it is typically implemented - or at least as I have seen it implements and have heard from countless others as well).  If Scrum is “Killed”, or somehow has an unfortunate “accident”, I doubt if it will “Kill” Agile (for the reasons in item 3 above).
 
5 - Likewise, the certification frenzy will not “Kill” Agile.  Anyone who is fooled by certifications has probably already been fooled by other certifications (like MCSD, PMP PMI, some college degrees, and etc.) and will continue to be fooled by certifications.  It is in the corporate genes, so to speak, for a lot of companies.  I won’t waste my time trying to convince them otherwise (well, I won’t waste MUCH of my time… well, I won’t waste ALL of my time…).   Back to the point: Most people who have had success using Agile while producing software will continue to do so.  If we need certs to satisfy our employers or clients, perhaps we’ll get certs - but we’ll still know the truth, and it won’t “Kill” Agile (see point 3).
 

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.

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?