Life, Liberty, and the Pursuit of Agility

This is  a little story about how I learned the right way to manage people

My First Job: Age 13 or 14

When I was a kid, if I wanted something (like a slot-car, or a pellet gun), I could wait for my birthday or Christmas and hope my folks could afford to buy it for me, but beyond that it was pretty much up to me.  So I pulled weeds, sold garden seeds door-to-door, sold Christmas and greeting cards door-to-door, sold grapes on the roadside, delivered newspapers as a back up for friends who had paper-routes.  Typical kid stuff for that day.

But those little jobs never brought in much money for the amount of work, so I decided to get a “real” job.

There was a plant nursery about a mile from my home, and they occasionally hired teens to water plants, move stuff, mix soil, plant seedlings into nursery cans, and similar nursery work.  So, to make a long story a bit shorter: I asked for a job, and the owner of the nursery, Mr. Smith (his real name), hired me.  He knew my folks.

Lesson One: Treat everyone nicely

The day I started, the Mr. Smith introduced me to Bill (also his real name).

Mr. Smith: “It’s great to have you join us here.  Bill is going to show you how to water the plants today – it’s not difficult, but there are a few important things you’ll need to know. You won’t have any trouble with it.”

Lesson Two: Continuous Improvement

Mr. Smith: “However, another part of the job is for you to think about what you are doing, and look for better ways to do things.  Keep track of your hours, and next Saturday when I pay you for the week I want you to tell me one way to do things better.  Look for problems, and think about how we could deal with them.  Okay?”

Me: “I’ll do that”

Mr. Smith: “Great! Bill will take you out and show you what you’ll be doing”.

Lesson Three: Give people a sense of the importance of what they do.

Bill: “Hey Woody, I’m glad Mr. Smith hired you. We’ve been too busy to take care of everything and we’ve got a very important job for you. Let me show you.”

We walked out into the nursery, and Bill grabbed a hose with a watering wand attached to the end and handed it to me.

Bill: “You are going to water the plants. It might seem simple, and in some ways it is.  But these plants depend on us for their lives – they can’t get water without us.  We water most of these plants every two days.  Each plant is in a can just large enough to provide the room it needs for it’s roots.  When you water a plant, give it just enough water to wet the roots completely, but no more – we don’t want to waste water.  However, if you give it any less, the plant may possibly dry out too much by the next time we water, and that stresses and weakens the plant.  Got it?”

Lesson Four: Most People Are Smart Enough To Figure Things Out.  Let Them Do That.

Me: “Sounds good.  How do I know what’s enough water?”

Bill: “Well, it’s a bit tricky.  You have to check some of the plants after you’ve watered a row.  Go back and see that a little water is dripping out the holes in the bottom.  That shows you the whole root-ball has gotten some water.  Keep your eyes open.  If some of the plants start wilting a bit – you know you have to adjust your technique.  You’ll figure it out”.

Me: “How do I tell if a plant is wilting?”

Bill: “Each species is a bit different, some need more water, some need less.  It’s just something you get used to over time.  You’ll figure it out.”

And so I did.  I watered the plants.  Hundreds and hundreds of plants. I dragged the hoses around, and I carefully watered each plant.  I also went back to check some of the plants when I got to the end of a row to make sure I was doing things right. I watched for wilting plants.  I was careful to not waste water.  IT WAS GREAT.  I was outdoors all day, I was doing an important job and it gave Mr. Smith and Bill more time to work with customers, pot up plants, make deliveries and so on.

Lesson Five: Make Everyone Welcome, Not Just Feel Welcome, But Truly Welcome

After about 2 hours on the first day, Bill came over to me and said it was time for a break.  A break? This was great!  I get to work, I’m making money, AND I get to take a break.  This was heaven. [Remember, I was just a kid and had no idea what work was actually like – I was just excited to be working]

Bill: “Hey Woody, let’s take a break.  We take about 15 minutes every few hours to get in the shade and have a soda.  Let me show you the soda machine.”

Soda machine?  I had no money with me.  I had no money, period.

We walked over around the back of the nursery to one of those old fashioned refrigerated coin-operated soda bottle vending machines with bottles of soda you pulled from a slot after opening the big, heavy, metal lid.  They had rigged it so you didn’t need coins.  Just pick out the drink you want.  SWEET! And they had Vernors Ginger Ale.  I was living high on the hog!

We sat and talked about plants, and the weather, and how wet you get watering plants. Bill was sincerely welcoming me.  He treated me kindly that day, and every day I worked with him. We were all there to work together, each of us depended on each other, and it was expected we would be polite and respectful in all things. I felt like I was part of the family already.  And that never stopped.

Lesson Six: Trust People

At the end of the week, I went to Mr. Smith to get paid.  I handed him my notebook where I had written my hours for each day.

Mr. Smith: “Well, how was your first week?”

Me: “I loved it”

Mr. Smith: “Thanks for keeping track of your hours. Please add them up, and multiply by $1.25 per hour, and then go get your money out of the cash box under the front counter.  Write down the total on a slip of paper and put it in the bottom of the cash box  – I need it to do the taxes.”

I am not kidding.  Maybe it was a different time back then, but I have a feeling it was much more than that.

Lesson Seven: Give Meaningful Feedback

Well, I got my money and went back to Mr. Smith.

Mr. Smith: “So, how did it go this week?  You getting a feel for the work?”

Me: “It went pretty great.  I really like working with Bill.  I like being outside all day.  I like the pay.  I like everything.  I think I figured things out, and I made sure every plant got plenty of water without wasting any.”

Mr. Smith: “I’m glad to hear that.  We’re glad to have you here – it’s really helping us out. There is one thing we need to work on. I noticed you are very diligent, and you didn’t allow any of the plants to dry out, or even get stressed.  That is exactly what we need.”

Me: (I couldn’t say anything I was so proud, but I was BEAMING!)

Mr. Smith: “But… Bill and I can each water the plants in about half the time it takes you. I’d like to see if you can do it in about half the time too.”

Lesson Eight: Let The Worker Figure Out How To Do The Job Better

Me (a bit saddened, but only a bit): “I thought I was doing a good job. I don’t want to kill any of the plants.  How do I deal with that?”

Mr. Smith: “Well, the trick is to give each plant the exact amount of water it needs.  No more, no less.  We can’t measure the amount, because each plant is a bit different even for the same species: slightly different age, slightly different soil mix, a little more sun here, a little more shade there… that sort of thing”.

Me: “So how can I tell?”

Mr. Smith: “You’ll figure it out.  Next week, I expect you to be able to water the whole nursery in half the time.  It took me time to learn – it will probably take you time too.”

Me: “I’ll do my best”

Mr. Smith: “I have a feeling that your best is going to be better than my best.  Let’s see how you do. So, remember I asked you to keep your eyes open for problems?  Did you find any?””.

Lesson Nine: Continuous Improvement Continued:

Me: “I remembered to look for problems, and I noticed that there was a leak in several of the hoses. It was wasting water and making the paths muddy.”

Mr. Smith: “What should we do?”

Me: “Well, I showed it to Bill, and he showed me how to fix the leaks.  We did it yesterday”.

Mr. Smith: “That’s great.  Let’s go get a soda.”

Lesson Ten: Reflect, tune, adjust

The next day, I tried to figure out how I could work faster and still water all the plants. One problem was that I still didn’t know how much “just enough” water was.  I knew when the plants had too much water – it ran out of the can, and into the gravel – but without letting the plants get under watered, how would I know what too-little looked like?

My solution was to set aside one plant out of each 100 or so, a “test” for me to experiment with.  I set them next to the edge along the row, and gave those plants about half the amount of water I had been giving all the other plants – 1/2 because I was taking twice as long as Mr. Smith needed. That seemed like a good starting point. At the end of the day, I checked those I had set aside along each row (about 200 plants or so overall) to look for wilting, dry soil, stuff like that.  I lucked out.  Each was fine.

The next day, I checked the “test” plants, and most of them were doing just fine… so, I had my solution: I had been overly concerned about too little water, and it was taking too much time.  Now I had “dialed in” the right amount.

So… the rest of that week, I used the new “correct” amount of water.  I made sure to stay alert and keep my eyes open for wilting and drying – and it went well.  Every now and then I’d spot one that was starting to stress, and I’d give those plants a bit more water with a watering can I carried for the purpose.  Overall, it went very well.

Lesson Eleven: Continuous Improvement Revisited, And Listen To What The Worker Says, And… More Lessons

At the end of the week, I went in to Mr. Smith to get my pay, and report on improvements I wanted to suggest.

Mr. Smith: “Hey Woody.  I was watching you this week.  You really did a great job – all the plants look healthy with just a few dry ones here and there, and you got your time right where we need it to be.  Thanks!”

Me: “Thanks for noticing, Mr. Smith.  I was really glad I was able to figure it out.  I was worried I wouldn’t be able to”.

Mr. Smith: “Well, I had no doubt.  You care about the job you do.  You pay attention, and learn from what you see.  So.  What did you figure out we can improve on this week?”

Me: “I’ve been dragging that hose all over the place.  There are only two faucets, one in the front and one in the back.  I have to drag the hose back and forth, and up and down each row.  I think it is taking a lot of time and effort just to do that, and it is wearing out the hoses.”

Mr. Smith: “How will you fix that?”

Me: “You want me to fix it? We’ll need to dig some ditches and lay some pipes, and put a faucet at the end of each row, and get a hose for each row.  That’s a lot of work. I’ve never done that before.”

Mr. Smith: “Can you figure that out?”

Me: “I guess so. But it will cost a lot of money to do that.”

Lesson Twelve: Engage And See

Mr. Smith: “How much time do you think it will save?”

Me: “I think I’ll save a lot of time – maybe an hour or two each day”

Mr. Smith: “How can you prove that to me?”

Me (after thinking a while): “Well, I could put in one new faucet for one row, and keep track of how much time that saves me.  Then multiply that for each row.  Will that work?”

Mr. Smith: “It might. Give it a try”.

Lessons Thirteen Through Infinity

That is just the start of the things I learned about the workplace and the way things should be.

So, What Happened Here?

I could go on like this for a long time.  This was my first two weeks working at the best job I’ve ever had. Kind people, trusting people. They were trustworthy, and expected me to be trustworthy.  They worked hard and expected me to work hard.  Even more, they worked smart, and expected me to work smart.  I was 13 (or 14, I don’t quite remember).  I was just a kid.  They treated me as an equal, and expected out of me as much as they expected out of themselves.

Worst thing: This spoiled me for all other jobs.  I worked there after school and on weekends all through high school, and after high school I continued on and off for a few years.  I learned a lot – about plants, and more importantly, about work, how to treat people, how to “manage”, and how to “lead”.  And how good it could (and should) be.

I haven’t been able to live up to my memory of Mr. Lawrence Smith, and I have fallen short of what I think he expected of me and my life, and in how I treat others.  I miss him still, all these many years later (he died long ago.)  God Bless You, Mr. Smith – you were, and are to me, one of the best.

Lately I’ve seen/heard a lot of discussion about deadlines – and it seems that they are often misunderstood.  Fortunately, I am often misunderstood, and I misunderstand most things… so it seems perfect I should write a blog post about this.

I Worked As A Flyboy At A Newspaper In My Teens – [you can skip this part]

You might have heard of newspapers.  They used to have these things where you could read news that was printed on paper – thus “newspaper”.

In my teens (in the late 1960’s) I had a night job as a “Flyboy” and printer’s assistant for a small newspaper printer who had their own web press (a web press is a huge machine where you put in 1-ton rolls of paper at one end and output printed and folded newspapers at the other end).

What’s a flyboy? It is a boy who stands at the “output” end of the press and picks up an arm-full of newspapers as they come off the press, quickly “jogs” them into a neat stack, and bundles and ties them on a bundler/tier.  “Fly” because the papers “fly off the press”, “Boy” because no reasonable adult would take this job unless they had no other choice.

A Few Things About This Job  – [you can skip this part]

• It’s LOUD: you will soon loose your hearing.
• It’s DANGEROUS: the various parts of the machines (cutter, folder, bundler/tier, etc) are all capable of removing parts of your body, mostly fingers or hands.
• It’s DIRTY: the ink is still drying as you handle the papers. You get completely covered in toxic pigments that you have to scrub off with a scrub-brush at the end of a shift, and you’re breathing paper dust and toxic fumes the whole time.
• It’s a NIGHT JOB: Or, very often it’s a night job because the papers go out in the morning.
• It’s HARD: It takes a great deal of constant physical exertion so you are guaranteed to be worn out at the end of the shift.
• In other words, at the end of the day you are tired, dirty, injured, and nearly deaf – much like computer programming.
• You don’t want me to tell you the bad things about this job.
• This has nothing to do with the point of this story.

Besides being a flyboy and a printer’s assistant, I also would do typesetting for some of the less important content, and operate smaller presses to print advertising flyers that get “stuffed” into the papers at some point, and help run the cameras and to do various layout, stripping, and other tasks.  Most of this stuff is now considered a “dying trade”. And good riddance, I suppose, but I loved it – it seems I always loved books, printing, machines, noise, lettering, typesetting, doing stuff, craft, high skills, hand work, hard work, and late night radio.  Especially the shipping reports from England that come on at 2:00 am PST.

Point is:

The point is I don’t know a lot about the whole process except what I learned when I worked in this environment for about a year, and I think I remember just enough to make my point (hopefully).

Getting the newspaper ready for printing each day requires a lot of specific things get done ON TIME

All of the following list of work must get done on a very tight schedule every day:

• Before you can print you must make the printing plates.
• Before you make the plates you must do the layout, camera work (separations, halftones, etc), and stripping
• Before you do the layout, camera work, and stripping you must do the typesetting.
• Before you can typeset you must have edited copy
• Before you can edit copy you have to decide that a story merits getting into the newspaper
• Before you can decide which stories merit getting into the newspaper someone must write those stories (or at least the headline and some copy) and take photos
• Before you can write stories and take photos the reporters and photographers have to go to the scene of the story and gather news, do interviews, etc.
• Before you can write a story you have to decide what to write the story about – a “news events”.
• Often the “news events” happen throughout the day and we don’t know what they might be until they happen. Man Bites Dog. Nuclear Annihilation Avoided – Again, Major Caught In Drug Scandal – Again, and so on.
• And so on and so on.

There are a LOT of deadlines in there – and they ALL HAVE MEANING.  As a matter of fact, I’ve left out a lot of details just to keep this post small enough to fit on the Internet.  Also, a number of these things happen “in parallel” – a story can be “gathered”, written about, and edited while other stories are at different stages of “completion” and still all get into the same daily paper.

So I am going to talk about the classic “Printers Deadline”.

There is a HARD DEADLINE in Newspaper Printing

At least where I worked, we had a hard deadline.  To get the paper out to the “marketplace”, the trucks must leave sufficiently early before traffic starts so the papers can be where they need to be when people want to buy them.  That’s the business. So – the hard deadline is: The press must start early enough to start putting newspapers into trucks so they can leave on time.  It is a complex dance with a lot of variables.

To do this, each step along the way has a specific deadline: It’s the time all items for this step MUST BE DONE with enough time to do all the following steps and still be on the press when printing starts.

The bottom line: if a story isn’t ready and “on the press” when the press starts printing, it is NOT going to be in the newspaper (there are ways around this, but that’s the general idea).  That is a hard deadline.  A lot of things can be easily changed right up until that minute.  After that, it is costly in both time and money to make changes.

Sometimes someone will yell “Stop the Presses”, like you see in the movies – but that is rare.  There are occasional “Dewey Defeats Truman” mess-ups.

My point: Real Deadlines Exist

Real deadlines exist. When they do exist, we need a system or method in place to deal with them so we have a reasonable chance for success.  In the newspaper business they have the deadline thing figured out.  The deadline is obvious. Some people say this is where the term “deadline” was invented.  By the way, the newspaper industry has bigger problems than deadlines nowadays, or maybe it’s a different kind of “deadline”, and we can talk about that some other day.

How Newspapers Deal With So Many Deadlines

There are a number of things the newspaper publishers have found work nicely to allow for these serious deadlines.

• Create news features (stories) daily – work in daily iterations – each day, the current “most important” content is created
• Deploy daily – a whole year worth of news is delivered in small, useful, daily chunks
• Decisions are made at the last responsible moment – if a more important story comes in at the “last minute”, a less important story can be removed.
• If insufficient material is generated for a story for it to be interesting or useful, they can quit working on it at any time.
• Whatever is done by the daily deadline is what gets delivered.
• There is no “Yearly” deadline – it’s more like a continuous delivery system.
• They discover processes that allow them to work quickly – e.g.: you can buy some stories from a third party (such as… the AP)
• They can “spice things up” as needed to boost sales.  That is not really important to the point of this article.
• They ca add lines and cut lines from a story to fill the space as needed.
• If a really important story comes in, several people can work on it at the same time.
• Stories that can be worked on, are worked on.  Stories not ready to be worked on aren’t.
• Fillers and other non-news “content” can be done and ready to add as needed without effecting the output of more meaningful content.  For example, a whole weeks worth of comics can be ready each Monday.
• Reporters and photographers can be multi-purpose (they can wear more than one hat).  They can interview someone, take a picture, write a story.  Some can even do the typesetting in smaller houses.
• They only need enough good (or really, “bad”) news material to keep people happy.

News items have different schedules and different deadlines based on the nature of the content – a garden page item might take weeks to write, photograph, illustrate, layout, etc – and a hard news item often has at most about a day and sometimes as little as an hour to go from “this just in” to “press-ready”.  Almost any feature can be edited to reduce its size, increase its size, or rearranged to fit the space on a page.

Sometimes they “stop the presses” and re-set one of the plates to change or add content.  Also sometimes a “special edition” is needed to disseminate late breaking but important news.  Sometimes a flysheet can be printed on another press to add content at the last minute.  Lots of options.

In other words – there are many practices they’ve innovated over the years to be able meet those deadlines and do the job of delivering a sufficiently interesting and sell-able product.

Sometimes Deadlines Are Needed, and We Need Ways To Handle That

Well – this blog is about software development, not the newspaper business.  However, I think there are a few similarities.  What do you think?  You probably see other similarities, and a few differences between the newspaper business and computer programming.  Still, the newspaper model might have some use.

Do you have deadlines??? Learn how to deal with it.

This is a post about a trivial thing that I can estimate, and there is a non-trivial point I want to make at the end.  So you can just skip-to-the-end if that is the sort of person you are.

I can estimate how long it will take me to drive to work.

I drive to work 5 days a week.   I need to get to my workplace, but I also want to pick up my daily oatmeal and drink for breakfast at a fast-food drive-thru.  Simple stuff.

Why do I need an estimate?

I need an estimate so I can be sure to leave home early enough to get to work on time.

I like to get to work 15 minutes early, and I’d like to make sure that I am never late except in exceptional cases.  So if I can estimate a time that will get me there about 15 minutes early, but never later than 5 minutes early that would work for me.  I don’t mind if I am 20 minutes early, but I don’t really want to be 25 minutes early.  So, I’m looking for a time range that gets me to work between 7:40 and 7:55, with the ideal spot being 7:45.

I want to be on time to work, with sufficient time to not worry about being late, and still not waste too much time just sitting there tweeting about estimates.

I drive pretty much the same route every day with about 10 minor alternatives available. I can take advantage of these alternatives (turn right here, or turn right a block up, stop at this fast-food or at that fast-food, etc) to make allowances for congestion at traffic lights, schools (school days are busy, holidays are not), drive-thru lines, and stuff like that – so I make a lot of little decisions on the way. For example: I’ll turn right at a light if there are a lot of cars backed up and take a chance that the next street isn’t backed up.  That allows me adjust to get a better chance at a good drive time.

I can estimate how long this will take, and use that estimate most of the time.

Yesterday it took 40 minutes, the day before 43 minutes, the day before that 36 minutes (school holiday).  Over the last year, I’ve found that it takes about 40 minutes to drive to work on a typical day.

If I leave at 7:05, I will almost always get to work in my target time-frame.

All well and good.  And that works great for me for typical days.

I can take advantage of daily changes

I “re-estimate” daily to adjust for school holidays, weather, etc. and vary the time I leave for work to compensate.

To clarify: I re-estimate every day to adjust for daily differences.  I can “re-estimate” quickly.  The cost is about 10 seconds of my time.

On a school holiday, I can sleep in 5 minutes. If it is raining, I must leave 10 minutes early.  If it is snowing, something is really wrong because it never snows here.

Why Does This Work?

You already know:

• I have a lot of data – way more than is needed.
• I know all the variables (weather/holiday/etc)
• I know the work-arounds (alternative routes)
• It’s essentially the same thing every day
• There are almost no unknowns
• There is almost nothing new to learn
• I can trust the guy who is providing the numbers.  It’s me.

That is, it is trivial.

By the way –  I can’t control the variables to predict an exact time, so a range is sufficient.

Having the estimate is useful as it helps me optimize my sleep time and still reach work on time.

This is the Non Trivial Part: How Similar Is This To Computer Programming?

So, if it is useful to have an estimate, and we can make a meaningful estimate – then we have a good application of estimates.  That is the case with my “drive to work” example.

In my humble opinion, this is not similar to computer programming. We have the first part: We feel estimates would be useful, but we don’t have the second part – the estimates are not meaningful unless you are doing very trivial work.

With software development we don’t have much data, we don’t know the variables, we don’t know the work-arounds, each project is very different, there are lots of unknowns, there is much to learn, and I can’t trust anyone for “good numbers”, not even ME.  By the time we know enough about what we are doing to make useful estimates they are useless because we are DONE.

When we find our software development work is “easy to estimate” it is likely that it is trivial in nature.  That is, if it matches the nature of my “drive to work” example then I would question if that work is actually software development. In software development, when I find I am doing the same thing over and over, know all the variables, have few unknowns, have little to learn – then that’s the time I investigate ways to automate it and stop “programming” it.

Have fun.

And remember: This is ALL JUST MY OPINION.  Don’t do anything I say.  Don’t mention to anyone else that this makes sense to you, they will just say you are crazy.

Some other posts I’ve written on the topic of estimating:

• Estimation is Easy and Useful: Estimate a game of Chess
• Do Estimates Do What We Want Them To Do?
• No Estimate Programming Series – Intro Post
• No Estimate Approach For End-Of-Life Legacy Support
• Notes From A Conference Session On No Estimates in Software Development
• A Comment And Response from Estimate Chess Post
• Can We Code Without Estimates?

Can we write code, create software applications, without doing estimates*?  I think there are at least some cases where estimates are not needed.

In The Beginning

I bought a computer in 1982 or 83 for the purpose of managing aspects of a business I had.  My business was essentially a small custom manufacturing business of sorts, and I had very little money.  No capital, just cash flow. I would sell some work, get a deposit, buy the materials and supplies for the work, do the work, get the balance on delivery, pay some bills, pay the rent, and go on to the next job.  Every hour I had was needed to earn money,  or support the overhead of doing business.  Additionally, I would spend some time improving my capability to more effectively make money, reduce costs, or “take care of business”. Payback for that time needed to be quick, not in two weeks, but in two days, or two hours.  Every penny counted.

So I now had a computer, but none of the software I bought worked well enough to help me.  I wanted to do simple stuff – like mailing lists, simple bookkeeping, making estimates for manufacturing jobs, writing invoices –  stuff like that.  I also wanted to do some very specialized things, like controlling devices: material cutting plotters, measurement devices, and imaging equipment.  But software was expensive, and it was mostly useless in those days.

Computers can help us do bookkeeping, right?

One important reason I wanted a computer was to keep my books. I wanted to spend less time doing my bookkeeping.  I had bought an application that was supposed to do simple bookkeeping: Keep track of money spent, allocate it to varioius accounts, keep track of the checkbook, reconcile the checkbook, do income and expense reports,  profit and loss reports, year end stuff, and so on.  Trouble was – it didn’t work well at all.  It was difficult to use, made mistakes, and the data got corrupted after a couple months of using the application.  It was truly useless and worse: it wasted a lot of my time.  I tried several other applications that friends of mine were using – but none of them made things easier than doing the work by hand.  I wanted my computer and software to save time, and make it easier for me to focus on getting and doing work.  It wasn’t able to do that.

Earn as you Learn – Or At Least Try

So I decided to try writing my own “bookkeeping application”.  It’s just numbers, right?  Computers work with numbers, right?  Shouldn’t be too hard.  Before we go any further, I’ll “skip to the end” and let you know: It was not hard at all.  It turns out that computers ARE good at working with numbers, and you just have to find a reasonable way to let users interface with the computer, and some way to show stuff on a screen, and some way to send stuff to a printer, and some way to save data to a disk so you can use it the next time you want to work with it, and some way to do the calculations and other work actions.  These are all easy things.

I had no experience writing applications at that time beyond some games and little text editing apps and similar things that came from books I was learning from.  For my first project I needed something that would return back the time I spent right away.  Seemed the checkbook part of the bookkeeping app would be the place to start – you need to put expenses and income into the system before you can do much else, and it would save me some of the time it took to do that work by hand.

A Simple Checkbook Application – Find A Small Bit Of Potential Value

Balancing a checkbook is easy enough, it took me about 2 hours a week to do the hand entry of checks and deposits into the paper system my accountant had set up for me, and to update the balance.  It also took about 3 or 4 hours once a month to reconcile the checkbook.  I had always made mistakes in entry or calculation, so sometimes it would take longer.  I was spending about 11 to 14 hours (or more) each month doing the paperwork for my checkbook.  There was no Quicken in those days.

If I could write something that would allow me to enter a check into the system, enter a deposit into the system, reconcile the registry, catch mistakes, correct mistakes, and print out the details – that would save me 11 to 14 hours every month.  Well… not really: It would take some of my time to do the entry of checks and deposits, and to review the output, and correct mistakes.  So there is the value: A time savings of perhaps 8 hours a month.

I had NO IDEA how much time it would take to write that software.  I had nothing to base it on. It seemed worth a shot, but I had no way of knowing that.  The only sure things was that I’d learn a bit more about programming.  The key is: I had identified a small chunk of work with POTENTIAL value.

Learn By Doing, Decide Based on Real Time, Real Value

So, I had a vague idea about value.  I figured I could put in about an hour each night and I would soon learn if it was worth trying to write this code.  In doing the work I would learn the things I needed to learn to do the work, and I could make decisions about the value being delivered.  At any point I could decide to cancel the project or keep going.  The decision would be based on value delivered for time invested.  NOT value that MIGHT be delivered for time that MIGHT be needed.  That seems like a bad way to make decisions to me, at least in some cases. Real value, real time.  Take action, make decision, take action, make decision.  A small amount of real work delivers enough value upon which to make a decision.  Deliver early, then decide: Should we do more, or try again, or change directions, or expand or reduce… whatever.  Baby steps every step of the way.

The First Bit Of Functionality: Data Entry

The first value I could see: Ability to enter in checks (number, payee, date, amount, etc.), save as a file, and print it out on paper.  This would be exactly what I was currently doing with pen and paper, and I could do the totals by hand with a calculator just like I had been doing.  So that is where I started. Not much value, but provided a way to “amplify learning”.

Now, it seemed that this “functionality” could be “written” without writing any code.  The user (me) could just use the existing text editor to type in the data in a specific format.  How long did it take to code that?  No code, no time.  I just needed to define a format.  How robust was that?  Not very! It would be easy to make mistakes in data entry – but I needed to get real functionality quickly.  Same old same old.  That’s software development, so I’ve learned.  Once the code is in use the most painful stuff will be revealed, and we can fix that first.  Might never need to do anything more than the minimum.  Try to keep it that way.

Writing to a file was easy enough.  What to do next?

I wanted to calculate the balance of the checkbook. I would be very close to having something truly useful if I could do that. That would require that I take into consideration deposits as well. That was easy to do, of course. Deposits are positive, checks and withdrawals were negative.  Or something like that.

Again, I had only an hour a night or so to spend on this – so everything was very “bare bones”, but reading the file, reading the records, and accumulating a total was easy enough.  And essentially, the application was ready for production.  It was useful. Lame, but useful.  Value was delivered, and it showed the project was viable.  There were a number of features to add before it would be “easy to use”. I still often made data entry mistakes, but I could fix those by simply opening the file with the text editor and making the needed change to the data. Over time, I added much of that functionality, and eventually it became my bookkeeping application.  The development was paid for by the time I saved every month.

So, that was the start – No Estimates

I don’t think I did any estimates in this work.  If you think I did, please let me know and I’ll clarify the process.  Or maybe I was wrong!

The process for me: Choose something of potential value, find the simplest thing I can think of, and try to do it.  If it works, I go on to the next bit that seems to have value, if it doesn’t work I try something else. Repeat until the payback doesn’t seem worth it anymore – at which point I can move to another “project”.

This is a very minimal example. It’s real, and it is where I started.  I used this same basic pattern to write a lot of software for myself over the next 15 years.  I never had a need to estimate anything.  I didn’t even think of making estimates.   Someone once told me that necessity is the mother of invention.  I’m not sure about that, but I just haven’t had enough time to waste on inventing things that I don’t need.

I’ve used this same apporach on much larger projects, in various situations, and with a number of different projects types.  I think some form of this approach can work for just about any project.

Please don’t yell at me

Before you start yelling, and before the veins start popping out on your head, please understand: in this post I AM NOT SAYING THAT ESTIMATES ARE NOT NECESSARY FOR MANAGING SOFTWARE  DEVELOPMENT in your situation.  I am simply saying that estimates are not needed for designing, coding, testing, and delivering software into use.

The process you implement for managing the business of making software might require that you do estimates.   But that necessity has nothing to do with writing software – that necessity is imposed by people who haven’t yet invented a better way to manage their software development, their customer interactions, their collaborative abilities, etc.  Maybe you can find a better way.  Maybe there isn’t a better way.  Regardless, if there IS a better way, maybe you can take a tiny step every day that moves you to a better process that does not require that you do estimates.  That’s up to you.

Can We Code Without Estimates?

Still, I hope you can agree that we can write code without estimates.  If you don’t think we can, I’d like to hear about it – especially if I am wrong or am missing something.

Some other posts I’ve written on the topic of estimating:

• Estimation is Easy and Useful: Estimate a game of Chess
• Do Estimates Do What We Want Them To Do?
• No Estimate Programming Series – Intro Post
• No Estimate Approach For End-Of-Life Legacy Support
• Notes From A Conference Session On No Estimates in Software Development
• A Comment And Response from Estimate Chess Post

NOTES:

* For the purpose of this article, the sort of estimates I am discussing are the estimates typically asked for on many software development projects where a project, a feature, or a function, or a bug fix (or where a list of features or functions) are described and people are asked to come up with an approximate cost in time, money, or effort to do the work that will be required to provide the feature(s)/function(s)/capability(ies)/bug fix(es) being requested.

Disclaimer: There are many situations where estimates can be meaningful and useful.  This article is about situations where I don’t think they are typically meaningful or useful, and only in the realm of software development.

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!

I have noticed some Scrum teams approaching the work of a Sprint/iteration as a “mini-waterfall”.  The work is thought of as having a progression just like a typical waterfall:

requirements gathering- -> analysis- -> design- -> coding- -> testing- -> promotion to staging… etc.

or something like that, but instead of spanning a year or so, it is applied to the work of a single 2 week iteration.  Continue reading ‘The Mini Waterfall with an Agile Team’ »