Comments on: kent beck on finding the itchy spot

By: April 27, 2010, Now Writing About Cucumbers « Rails Test Prescriptions Blog

April 27, 2010, Now Writing About Cucumbers « Rails Test Prescriptions Blog — Tue, 27 Apr 2010 11:48:17 +0000

[...] Beck would like to analogize goat farming and software development. I’ve heard [...]

By: SKMurphy » Startup Lessons Learned Conference Coverage Roundup

SKMurphy » Startup Lessons Learned Conference Coverage Roundup — Mon, 26 Apr 2010 06:43:06 +0000

[...] Sarah Allen “Beyond Agile Development” and “Finding the Itchy Spot“ [...]

By: John Sundman

John Sundman — Sun, 25 Apr 2010 13:27:29 +0000

I’m thinking about this post not in the context of creating code, but in the context of the overhaul of my website (a redesign & port to a new blogging platform; recruiting new writers), nearly complete– a process which took months.

I write & sell novels that generally appeal to hardcore geeks & hackers. I’m trying to sell more of them. My website is my main vehicle for making these books known to the world. But right now, the book-promotion parts of the site are not even implemented yet. There was too much other work to do first.

But let’s assume that I’ll have some kind landing pages and shopping cart done soon, within the next few days.

What then? What itch am I trying to scratch? What problem am I trying to solve for Wetmachine’s readers? And what connection is there, if any, between the value readers get from interacting with my site and the value they would get from buying one of my books?

And now that I have a nifty site with 8 quality writers and a big backlog of articles, many of them still relevant, and more new ones coming virtually every day, what other opportunities lie before me, beyond just selling books?

I’m thinking. . . where’s the itchy spot? I dunno. I’m going to keep looking for it. . .

By: Sarah

Sarah — Sun, 25 Apr 2010 04:09:04 +0000

The point is to have a hypothesis that you are trying to prove with your code. Anyone who does TDD without a vision of what the software should do is missing the point. There was a lot of talk at the conference about having a big idea and how to find the right expression of it. If a feature needs to be fast, you need to do the engineering to make it so, but I’ve often seen (or been) an engineer who adds detailed options because someone might need them when something else (like performance or a different feature entirely) is actually what is needed.

The key thing is to keep asking the high level question — *sometimes* the answer is a hack or a paper mockup or simply a phone call to a customer to understand what is really needed before creating a complete, robust, performant implementation.

By: Adam Wolff

Adam Wolff — Sun, 25 Apr 2010 03:58:39 +0000

Gosh, I don’t know about this Sarah. This attitude is similar to the hardcore TDD stance, which I also struggle with. I guess I agree that sometimes rapid, hacky iteration is the best thing, but I think there are certain problems that are worth solving correctly, even if it takes more time.

I think TDD often produces verbose, paradoxically bug laden software, precisely because the process encourages myopia. Similarly, I think that there a lot of questions that can’t really be answered until you’ve developed a proper solution for them. People say they don’t like the new feature, but is that because it’s buggy and slow?