Do You Make This Common Mistake When Estimating?

When estimating a project using the Planning Poker method, many developers like to use a baseline estimate for a given task. For example, many developers use CRUD, the creating, displaying, editing and deleting of a Model as their baseline estimate. Once they’ve got their baseline in mind, it makes it easier to estimate other stories that are more domain specific, or so it seems.

Baseline Estimates are Broken

When you’re using a task like CRUD as a baseline for your estimations, you can easily skew the estimations of the other stories in the project. Let’s say we’re using a 3 point baseline for CRUD stories.

  1. As a user I should be able to upload a profile photo – 2
  2. As a user I should be able to CRUD movies I’ve seen – 3
  3. As a user I should be able to send a private message to another user – 5
  4. As a user I should be able to create a trivia quiz for a movie that I’ve seen – 8

In this first example, the stories are probably estimated fairly well and compared to each other, the complexity is quite relative. What happens if we add a few more easy stories or a few more difficult stories?

  1. As a user I should be able to see a contact e-mail on the home page – 1
  2. As a user I should be able download the menu as a PDF - 1
  3. As a user I should be able to read a privacy policy – 2
  4. As a user I should be able to CRUD restaurant reviews – 3

With easier stories added, the CRUD story is definitely the most complex, but compared to the others it is significantly more complex than seeing a link on a page or viewing some text.

  1. As a user I should be able to CRUD portfolio photos – 3
  2. As a user I should be able to signup for a paid recurring account – 8
  3. As a user I should be able to make connections with other users via Facebook – 13
  4. As a user I should be able to send a rocket to the moon – !

When the other stories become much more complex, the CRUD task is again shown to be significantly different in complexity, this time in the other direction. In this group of stories its hard to imagine that managing portfolio photos is only two orders of magnitude away from a recurring payment e-commerce system.

Relative Complexity Works

Its important to estimate a group of stories so that the complexity of each story is relative to the next. In Mike Cohn’s Agile Estimating and Planning, he describes a method of estimating stories called “Analogy”.

When estimating by analogy, the estimator compares the story being estimated with one or more other stories. If the story is twice the size, it is given an estimate twice as large.

When you apply this technique to your estimation process, you will have a more coherent set of estimates. From this you will be more likely to determine an accurate estimated velocity and you will have a better overall sense for the scope of the project.

Hurdles to Estimating by Analogy

  • Estimating all of your stories one by one makes it difficult to estimate a relative complexity as you only have the previously estimated stories with which to compare your current story. A group of especially simple or complex stories could be waiting towards the end of the sessions.
  • Estimators who are new to the agile estimation process might have difficultly estimating a story without a point of reference.
  • Estimating with a baseline can be a difficult habit to break since it provides a convenience and familiarity to the estimator.
  • Two seemingly similar projects may have a greater than expected difference in total number of story points, even though their velocities are relatively the same.

Why Developers Avoid Testing

While the drive towards a culture of “always be testing” has existed for some time, the recent detour into software craftsmanship has helped to create a new style of getting the word out. What used to be, “Test driven development is a great way to approach solving a problem” has turned into “If you’re not testing you’re a shitty developer.” The testing evangelism going on in the community today is misguided and would convert more people if it addressed the real reason people aren’t testing.

It’s Like Losing Weight

To the ever testing software craftsman, it can be puzzling why people don’t write tests. The assumption much of the time is that developers are lazy, that they don’t care about the quality of their code or even that they think testing is an abject waste of time. In my experience this is almost never true.

People skip testing because, ultimately, it’s hard work. Think about what it takes to lose weight or to quit smoking:

  • Break familiar habits
  • Disrupt your personal relationships
  • Acknowledge that you’re deficient
  • Find help
  • Fail often before you succeed

As a developer working in an organization that does not maintain a culture of “always be testing”, it’s going to be difficult to:

  • Change the way you think about solving problems
  • Upset peers who are comfortable in the status quo
  • Admit that you don’t how how, what, when and why to test
  • Find a mentor willing to help you improve
  • Not give up every time you get stuck

End the FUD!

Think about what it means to start testing when you never have before. Not only do you have to come to terms with not knowing what you’re doing, you eventually realize that you’ve been “doing it wrong” until now. This is fearful self-doubt territory for a lot of people.

If you’re serious about getting more of your industry peers to start testing, stop:

  • Going on about craftsmanship; people don’t strive for mediocrity.
  • Playing the doomsday “If you don’t test…” game.
  • Talking about how testing makes you so much faster; their personal experience points to the contrary.
  • Overlooking their perception of testing.
  • Forgetting when you were in their shoes.

Instead, ask questions, get to the root of the problem, don’t settle for “testing makes me slow” or “that’s not my job”, dig deeper.

I believe that as an industry we should strive for increasing code quality, robust test suites and better problem solving. As the minority who are practicing TDD/BDD/test-first/TATFT etc., we need to change our tune. Let’s stop preaching the benefits and start addressing the fear, uncertainty and doubt that keeps smart, capable and dedicated developers from enjoying these benefits.

Do You Make This Common Debugging Mistake?

Hi, my name is Clayton and I use ruby-debug. There, I said it. As a matter of fact, I use ruby-debug a lot, I use it too much. I’m not even solving complex problems or debugging nitty gritty internals, I’m just being lazy. Sure, ruby-debug is a really awesome tool, but we abuse the hell out of it. If you’re reading this and thinking “hey, that’s what I do” then you’re making a mistake, a mistake that’s hurting your code.

How Debuggers are Abused

Marking breakpoints and stepping through your code, evaluating each line and variable is a pretty typical practice. There are some developers who literally figuratively could not live without their debugger. I suspect this is most common in languages where IDEs are prevalent, but lets not forget about the modify-refresh-repeat paradigm in the PHP world.

Sometimes, when I come across some unexpected result or outcome, I will immediately add my debugger statement and start stepping through the code line-by-line echoing variables, assignments and conditionals to the terminal trying to track down my problem. Recently, I had a colleague scoff at the idea of not having ruby-debug for their rails project. The idea that we need this tool for day-to-day development is absurd.

Our One Step Program

When you’re testing the logic and/or output of your code with a debugger you’re making the mistake of not writing automated tests.

There are few problems that are solved via the manual and time-consuming process of a debugger that cannot be solved with an automated test. If you’re confused about the output of a calculation or method, write a quick unit test for that method. When the logic of your application doesn’t appear correct based on the input, maybe an integration test is in order to evaluate the flow of your program.

Not only do you get rid of the debugger baggage, you gain all of the other benefits that go along with testing.

BONUS: Excuse Resolution Table

If you’re getting ready to excuse your debugging behavior, check this list of resolutions first:

But excuse, I need a debugger…

Write more tests. Don’t have tests? Quit your job.

Quit Being Comfortable

If you’re heading towards that dip, or feel like you’ve been stuck there for a while, fear not, it’s easy to shake yourself out of it. Put yourself on the line and increase your expectations.

It’s easy to fall into comfortable relationships, comfortable careers, comfortable routines and lead a comfortable lifestyle. However, once you’re in that position you start to wonder where the magic went. You can recall a time when you were excited and things sparked your interest, now, they’re just boring old routines.

Imagine those exciting times. That time you spent dating, forging that good friendship, interviewing for jobs, meeting the new team, notice a pattern? They were all challenging times when you had to push yourself and risk something.

Risk being ignored, risked be disliked, risked being rejected, risked failing. You had to work hard and make things happen. Look where you are now, no risk, no challenge, no real effort.

Do yourself a favor:

  • Join a local industry group
  • Give a public presentation
  • Attend a local lunch gathering
  • Update your resume
  • Start a new project
  • Learn a new skill
  • Make a new friend

Put yourself on the line, risk something, challenge yourself, flirt with the possibility of failure. The feeling you’ll get from all of this will tear that comfy blanket to shreds.