Life, Liberty, and the Pursuit of Agility

I like to talk

I was given an opportunity to present a session at the Agile San Diego group last night.  I have some pretty clear ideas about how to be productive in developing software (and a fair number of solid successes in turning out useful software), and those who know me are sick of hearing this stuff.  I am always looking for an opportunity to find someone new to bore.  Thanks for stopping by. 

Agile Success seems elusive

Over the past 13 years I’ve been using (or sometimes fighting to be allowed to use) an Agile approach in software development.  For about a year I have been slowly gathering my thoughts into a talk on Agile Success.  I’ve given about 5 talks on this theme now – each very different, and the audience has mostly been folks new to Agile thinking.  

Agile San Diego is a group of highly sophisticated Agilists who are typically expert debaters and highly competent loud arguers –  I like it very much.  So I took this opportunity to solidify my materials and put it to the test.  The results were so-so, IMHO, but it is in the doing of a presentation that I discover the presentation that I must do.

Agile Success – Why Not Me Too?

In its current state, the talk is called “Agile Success – Why Not Me Too?”.  It’s mostly about the “Why Not”: we tend to block ourselves from achieving good result by hanging on to “old and busted” thinking and practices.  Perhaps we do this because the old ways seem so right (but they are oh so wrong) , or perhaps just because we are comfortable with them, or “our customers (or boss, or manager, or marketing) require it”,  or … well  – there are a lot of reasons we keep doing things the same old way – you get the idea, I am sure.

For this instance of the talk, my main goal was to show that we are typically our own worst enemy.  More specifically, it is the things we think are most solid, meaningful, useful, and productive in our process that are the most likely to be hampering our progress and wasting our time and money – and we don’t have the skills or openness or whatever to recognize this.  In other words, those are our blind spots. 

The Maxims

Here are my three main talking points.  I call them Maxims (to differentiate them from the Values and Principles):

Critical Maxim 1:
It is in the doing  of the work that we discover the work that we must do.

Critical Maxim 2:
Embracing change is IMPOSSIBLE if your code is not Easy to Read, Easy to Maintain, Easy to Grow, and Easy to Change.  Everything else is secondary.  Everything.  This applies to “lean start-ups” too!  Code becomes HARD really fast – often within a few hours if we are not paying attention.

Critical Maxim 3:
Question Everything

In my own work, I use the Agile Manifesto and Principles as a guide to evaluate everything.  I use them as a quick sanity test for every practice that I am using or thinking of using.  However, I also recognize that I am the inventor of the process I follow, and therefore use the 3 Maxims to keep from getting off track. 

Using Maxim 3, I also question the value of the Maxims and the Agile Manifesto/Principles themselves.  It is a vicious, never-ending continuous loop of vicious, never-ending continuous loop of… – so I don’t get too serious about it.  Whenever my brain starts bleeding I take a break, let things coagulate, and then get back to it.

Also, the 4 values, 12 principles, and 3 maxims are not written in stone.  It is likely that there are other important missing maxims/values/principles, and there might be errors and partial omissions.  But this is a living thing – adjustments are allowed – cells split, some things become vestigial – and so on.  Complete re-writes are allowed.  Nothing is sacred.  Continuous improvement must include improving the things we improved previously and think can’t be improved.  Throwing some things out and letting other things die off is okay.

The talk took less than an hour, plus about 1/2 hour for discussion.   Not bad for solving all the problems that ever were or ever could be.  Well, no one else saw it that way, but this is my blog and I can make up anything I want.

However, what I was trying to show is that my current thinking (which is based on real, every day cranking out of healthy, usable functionality) is that:

• most development efforts are chock-full of harmful practices that we hold sacred yet are massively wasteful or even counter-productive
• that we are the cause of most of the problems
• and there is a way to make things better.

I won’t cover the rest of it here unless enough people actually ask for more.  That has never happened yet, as I don’t think anyone reads this blog, and most people who attend my talks spend most of the time trying to find a way to respectfully withdraw. 

The most important thing:

For me, acceptance of Maxims #1 & #2 gives a clear way to evaluate 90% of the badness I have encountered in software development.  They are on an equal with the Agile Principles in the way I use them.  Maxim #3 keeps me honest about Maxims #1 & #2.  I have another 3 or 4 slides on Maxim #3 that guides the questioning process.  Perhaps I’ll write about that sometime soon.  It is not the 5 Whys, and I don’t think there is a Japanese word for it either.

There you go. 

Have a nice day.

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 turning 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.

[NOTE: Everything I say in this post and on this blog is based on my experiences, study, and observations.  It is MY OPINION. It is the way things seem to me.  It might be useful to you, might not – I don’t really care.  If you want to argue about it, that is fine.  I am suggesting that there are better ways to do almost everything we do in software development, and that it is worth thinking about it and doing something about it. You might already have better ways to do things, and I want to hear about it.]

I Like to Hike

I like to hike.  I hike whenever I can.  I prefer the trails and paths and wilderness, but I’ll hike on the roads and streets when I have no other option.  There is not much real wilderness around where I live anymore, but there are a lot of places that are remote enough that they seem wild.  Good enough for me.

I was out hiking today on the Coast to Crest Trail with my wife and our dog.  I’ll call him Rex, but that is not his real name (he’s asked me not to use his real name).  Rex is a great hiker, and at 9 years old he is still anxious to get out on the trail and can out-hike most.

We got about a mile up a pretty steep trail and Rex started favoring his left hind leg.  We’re not sure what happened, and he wouldn’t tell us.  We suspect he was bitten by a red ant since we couldn’t find a thorn or a cut or any other obvious issue – but we did notice a bunch of red ants on the trail.  Whatever it was, we decided to turn back and call off the hike while Rex was still in good enough shape to hike himself out of there.  Rex weighs about 45 pounds, and if he couldn’t make it under his own power I’d have to carry him.  I could probably handle it – but it would be very slow going.  Also, the whining and complaining is something neither my wife nor Rex would care to put up with.

As we headed back down the trail, I was thinking of other hiking I have done, and the risks and possible trouble you can get into out on a hike,  which eventually reminded me of a saying they have at the Grand Canyon:

Hiking the Grand Canyon: Getting to the Bottom – Optional. Getting Back to the Top – Mandatory

I’ve hiked in the Grand Canyon to the Colorado River and back out four times, including a “rim to rim” from the North Rim down to the Phantom Ranch and the River then up to the South Rim.  It is a lot of fun, and even though there are a lot of hikers out on those trails, it’s not hard to get a sense of wildenerss in that spectacular setting.  Some trails are lightly traveled and you can get very remote and lonely if you like.

These Grand Canyon hikes are “backwards” compared to most I’ve done – typically, we start at the bottom of some mountain and hike up – and once all the hard uphill work is done, we can come back in a relatively easier downhill mode.  At the Grand Canyon, we start at the top and hike down and take pride in our tremendous pace.  When it is time to return, it is all uphill and we start to remember how “pride cometh before a long trudge up”.  That is the way they built the place.

From the top of the Bright Angel Trail on the South Rim you can see many of the fabled milestones and exotic destinations such as the Mile-and-a-half Rest House, the Three Mile Rest House, Indian Gardens, Plateau Point, and the Colorado River itself – you can even see the Phantom Ranch from some viewing areas.

All these interesting and enticing places don’t look all that far away. They seem very close, and they are if you are a crow.  But this is deceptive – the distance for the non-crow hiker is greatly extended due to the long grades and switchbacks necessary to make the trail possible to hike.  Things that look close are many trail miles away.

I’ve seen a lot of casual hikers sprightly scamper down the first two or three miles (or more) thinking it’s an easy hike, only to find it takes a great deal more time and effort to hike back out again once they turn around and head back to the rim.  Especailly if you are wearing flip-flops or other inappropriate footwear.  And worse things can happen.  On one trip I met a man near the river (met is a bit of a lie.  He was lying on his back in the middle of the trail almost unconscious.  It was more like “stumbled upon” than “met”).  He was suffering from euvolemic hyponatremia (look it up).  At least that is what I think he was suffering from.  Anyway – he was suffering.  He should not have been down there.  We helped him with some electrolytes and salty snacks and then helped him slowly make the couple of remaining miles to the Phantom Ranch. He recovered, but had a hard several days.  As a side note he was hiking with his ex-wife.  Now THAT is interesting.

Another trick of the Canyon is that as you hike down, the temperature increases.  At the rim where it might be 65 degrees on the very same day it can be 100+ degrees at the river.  (On one day I was there it was 120f at the river and 70f at the rim.  Dang! ).   What starts out as a pleasant, cool, and easy down-hill hike turns into a stressful, hot, dry, and very lengthy up-hill trudge.  Once you have used up your water, water starts to seem more important to you.  And don’t forget the electrolytes (remember the euvolemic hyponatremia?)

There are about 400 rescues per year in the Canyon (not all are hikers, but a lot are), and they only do rescues for the really critical cases such as heat stroke, serious injuries, and other medical emergencies – a lot of hikers get rescued by other hikers who share their water, food, gear, time , and electrolytes.

The “backwards” nature of the hike (Down then Up, Cool then Hot, Seemingly Short, Actually Long, Easy then Hard) lulls hikers into going too far down the trail.  It all seems so easy and fun at first.  By the time you discover how HARD hiking back out is, you’ve already used up all your food, water, energy, happiness, and other resources.  You’ve spent everything and now comes the real work – hiking up and out of the Canyon in the heat.  And oddly, the distances are even longer hiking up than hiking down.  Funny how that works.

The reason to hike in the Grand Canyon (or anywhere) is slightly different for each hiker: Recreation, fitness, adventure, or whatever – [Note: in the world I live in we rarely hike out of necessity anymore.]  In the Canyon, a lot of people also have a goal to get to one or more of the milestones or well known points of interest, or all the way to the river.  But the real goal for every hiker has to be to get out alive and in reasonably good condition (aches and pains are acceptable, I suppose, but dehydration, heat exhaustion, heat stroke, and alarming leg swelling aren’t so nice) .  Getting out is Mandatory – All other goals are optional.  They have warning signs all over the place at the Canyon about the risk of misjuding your skill, ability, and the difficulty of the environment.  Still, many hikers end up in trouble.

What The Heck Does This Have To Do With Software Development???

You probably hoped I would forget to drag Software Development into this post, but…sorry.  Here goes.

I’ve seen this same basic scenario in Software Development.  The goal, the abilities of the organization, the apparent short distance to enticing and desirable “points of interest”, and the risks are all often misunderstood.  All the available money, time, and effort have often been expended by the time the real work of coding/testing/deploying begins and we realize how difficult everything is and how far we’ve gone down a winding, narrow trail we can no longer get back up.  And even worse, we have nothing useful to show for it except documents, diagrams, designs, and some code that can’t climb out of the test-and-fix cycle.  Whew.  Glad that is over.  Now – your assignment – go back over this post and equate all that stuff about hiking to some software development effort you have worked on.

I’ve seen and heard about a LOT of backwards, risky, hot, long, painful, death march trudges – Lucky for me I have worked on only a few of them.  Just remember – there is a way to work that isn’t backwards.  Let’s do that instead.

This turned into a long post. I think the corollaries are obvious.  Maybe they aren’t.  Maybe I am just full of it.

So, have a good night.  Tomorrow go do something fun – and stop wasting your time reading stuff on the Internet.  Go out hiking instead.  And by the way – hiking the Grand Canyon is FANTASTIC.  I recommend it to anyone still healthy enough to get out and hike – thousands of people hike the Canyon each year without problem.  Bring some electrolytes or at least some salty peanuts and cheese crackers or something.

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).

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.

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

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