This method is called when a user taps a button inside a table cell. The purpose of the method is to find the table cell that the button belongs to, and then call didSelectRowAtIndexPath on that table cell.

Disregarding the fact that this methods purpose makes didSelectRowAtIndexPath one very bloated method, there are a few other improvements we can make to it.

First, this method uses a C-style for loop. Objective-C 2.0 supports fast enumeration. Fast enumeration is faster, looks better, and throws an exception if you attempt to modify the collection while it is being enumerated.

Because NSArray has a well defined order, and enumeration proceeds in that order, we can simply count the index.

We now have more lines of code than the original, but the intent is somewhat clearer. The implementation of this method however, still relies on a string comparison to find the correct table cell, which is not ideal.

Using our knowledge of the view hierarchy we can re-implement this method to forgo enumeration altogether.

Knowing that our button is inside a table cell we can ask it for its superview. Once we have the table cell, we can ask for its indexPath. We can then call didSelectRowAtIndexPath directly using the indexPath.

# TODO – Make this work properly for all cases.

At some point in time this comment made sense. Someone, somewhere had every intention of fixing this and removing the comment.

It’s quite possible that someone was you, but you don’t remember anymore.

todos are irrelevant

todos live in no-mans land. Stuck in a time warp for all eternity. Don’t kid yourself, you’re never going to re-visit a todo. They’re irrelevant.

They fly under the radar because they have no visibility. Out of sight, out of mind. If you’re not working on the code with the todo, then you don’t know it’s there, and you don’t care.

Other than doing a project wide search, you’re never going to find them all. Even if you do, you’re not going to understand the meaning of them all.

They’re irrelevant.

making todos relevant again

What’s the point of a todo list if nobody knows about it?

Take control of your todos and enshrine them in code that everyone sees every day. Write them into your test suite as pending tests.

Failing tests are bad. Passing tests are good. Pending tests are just plain annoying.

They clearly indicate that something hasn’t been finished properly. They’re visible every time you run your test suite. This means they annoy everyone until they’re fixed.

They define todos better than any other mechanism at your disposal.

Sprinkle in a touch of guilt

While a quick flick through svn blame will find the culprit, it’s not visible and it means work on your behalf.

Sprinkle in a touch of guilt by mandating all pending tests be created with the Authors name and todays date in the pending message.

That’ll ensure they don’t hang around like a bad smell for too long.

But how many developers apply it to their software engineering practices?

Stories

Agile developers work with the concept of stories. Essentially these are short explanations of what someone should be able to do with the software once the story is implemented.

A user should be able to manage their account.

This story is vague, open ended and typical of client feature requests.

Before estimating this story, you’re going to need to get some fine grained detail into it. After talking with your client you might end up with the following:

Managing their account consists of changing their name, updating their contact details, changing their profile picture, resetting their password and swapping between username/password and open-id for authentication.

Now you have enough information to estimate this story, you know what the client means by “manage their account”.

You might come up with an estimate of say 100 points.

This example is contrived but if every story your client sends you follows this same process you’re heading straight for a world of pain.

The Effect of Large Stories on Iterations

So you start work on your iteration with 10 large stories with your team and half way through you’re looking at the number of stories you’ve sent to your client for testing.

That number is zero and you’re starting to feel a bit stressed out. It’s ok though because by the end of the day 5 stories have moved into the testing phase.

You move on to the rest of the stories in the iteration and your client gets started testing the stories you’ve completed. Some of them pass and others get sent back because something is not quite right.

The cumulative effect of multiple large stories is an exponential story completeness graph.

The Effect of Large Stories on Developers

Working on the same story for a long period of time is painful. As a developer you feel like you’re climbing a mountain that just keeps getting bigger.

You’re not sure where the top is, and sometimes you think you’ve reached it, but as it turns out you’ve forgotten something and you’re not quite at the top.

The effect on the team is that everyone goes through this same journey every iteration.

Your client experiences the same in reverse. They sit around waiting to climb the mountain, and they wait, and then bang, they’re expected to be half way up the mountain almost instantly.

Divide and Conquer for Happiness

Large stories can often be broken down into smaller stories. In fact you already did this when estimating your stories. But you finished one step before you should have.

You should have split the original story into multiple smaller ones:

A user should be able to change their name.

A user should be able to change their contact details.

A user should be able to change their profile picture.

A user should be able to change their password.

A user should be able to switch between username/password and openid for authentication.

Each one of these stories is smaller, has easier to meet acceptance criteria and will be finished earlier.

Your client will love you because they don’t spend half their time sitting around and waiting for stories to test.

The developers in your team will love you because instead of climbing one massive mountain, they are climbing 5 mounds.

Everyone feels like they are constantly moving forwards through the iteration.

The story completeness graph moves from being exponential to linear.

That’s a much more positive graph to have hanging on your office wall.