SOPA/PIPA is kind of like making it illegal to buy blank T-shirts because you might put someone else’s trademarked or copyrighted image on them. Which is awesome if you’re the one with a “famous” image or brand, but sucks if you just want to publicize your mom-and-pop business or your kid’s band.

So since when is it your job and my job to make sure Disney and Comcast’s copyrights can’t possibly be infringed upon? Why the hell isn’t it their job?

The inevitable war story, because I do that:

I used to do programming work for an industrial/grunge record label. (Brush with fame: I knew Marilyn Manson’s accountant.) They actually had lawyers dedicated to suing bootleg T-shirt vendors at concert venues. It was an expensive pain in the ass, but they figured it was a cost of doing business and protecting the brand.

It wasn’t perfect, because you can’t catch and sue everyone, but it worked well enough and the label was quite profitable.

It’s not good enough for Disney though. They think their right to guaranteed profit trumps your right to run a web server. That’s the issue.

The original code was written by a physicist–let’s call him Jim–who wasn’t a professional programmer but actually did an okay job writing and maintaining this Visual Basic Classic (pre-.NET) code for several years. “As a programmer,” someone might say in a gently mocking tone, “Jim’s quite a good physicist.”

So it’s cool. The important thing was to solve the scientific problem, and that it did. When I picked up the code with a mandate to get it working on a .NET platform and add a few features, though, I found it fairly hard to follow. A lot of the operations really needed to be event-driven but simply weren’t. There were a lot of modal dialogs and there were Windows forms with a ton of overlapping controls that got shown and hidden at various steps in the process.

So it was slow going, getting the thing to build and actually run on .NET. But the thing that saved my sanity in so doing was asking one simple question over and over again:

Does this code get used at all?

In many cases, the most difficult code was unmaintainable because nobody had to maintain it anyway. I consulted with the client, was told that the code implemented a feature that nobody used or even knew about, and simply deleted it. (After! Of course! Having all the originals under version control!)

There was a mishap or two in that regard, such as code invoked by menu options that seemed to be permanently disabled, but still. I could go back to version control (Subversion in this case), pull the original code back into Visual Studio, and massage it to get it to work.

But the massive reduction in workload caused by not having to work on 30% of the system at all more than made up for the few little problems. I’m pretty sure that the most effective development optimization of all, when working on legacy code, is simply cutting out the code that is never invoked or nobody cares about.

The event is like this: You show up, hang out, grab a pair partner, and start doing test-driven development (TDD) on a specific programming problem. After forty-five minutes, you stop programming, join the big group again for a debriefing, and do it again from the beginning with a new pair partner.

And you do this like six times during the day. (I only stuck around for four iterations.)

The problem space

The actual programming problem was to mplement Conway’s Game of Life. It’s a devilishly clever assignment, partly because anyone who’s taken more than one Computer Science class thinks they’ve already solved it. But oh no.

If you don’t know about the Conway game, it’s not really a game you win or lose. You have an unlimited “board” of square cells arranged in rows and columns. Each cell is considered either “alive” or “dead.” On each “turn” every cell counts its eight immediate neighbors (including diagonals); if it has fewer than two live neighbors it “dies” of loneliness; if it has more than two live neighbors it “comes to life”; and if it has exactly two live neighbors it just stays the way it is. That is all. You just watch it go, turn after turn. It’s just cool. There is no object other than watching the patterns that “grow” from various starting configurations.

(If the above sounds like a really stupid waste of time, you are not a geek. Please find another career.)

Harder than it looks

This is actually kind of hard to implement in a real object-oriented way. How do you design your classes? Is there a Board that contains (“has-many”) an infinte number of Cell objects? That won’t work quite the way I made it sound, will it? How about keeping a collection (like a C# generic) of just the live Cells? (It’s a lot easier if you get to assume a limited playing field. But alas.)

What I learned

Somewhat importantly, Corey didn’t expect us to use any particular programming language. He encouraged us to pair with colleagues who were using languages we might not even know yet.

I learned a bit about object-oriented design, if by “learn” you mean “find things to argue with.” Briefly, master crafters like Corey seem to prefer a lot more abstraction in class design than I feel like wrapping my head around. I usually like a one-to-one relationship between code space and problem space; so to me an object is “a thing that does things,” and a class is the idea of what that object looks like and does. If I can’t think of it as a thing, it’s not an object– it’s a method. Maybe.

I didn’t get very far with my pair partners on any of the iterations. We kept getting hung up on the TDD cycle, confused with the problem space, or stuck on mundane tactical issues. In that way it was frustrating.

On the good side, I got to hang out and pair with Angela Harms on an iteration. There was a mutual aha moment when I said out loud, “A cell knows if it’s going to live or die.” Angela thought it was some Zen kind of cool. I thought I was having fun anthropomorphizing the code. We’re both right.

My man Chris Sanyk was there too. He wrote about it, and wrote about it again, and wrote about it yet one more time. Our favorite insight occurred when Corey said something about running unit tests only on public methods, which annoys me because sometimes all the interesting logic is in private methods. I was launching into a “rant” on this topic, according to Chris, when Chris simply said, “So write the test method inside your class.”

I was stunned for a moment, then opened my mouth to argue, realized what I was about to say would be wrong, then started to say something else that was wrong, and finally looked at Chris and went “aaaaaaah.”

Is that the right answer? Beats me. It’s not mainstream as far as I know. But it turned my idea of unit testing on its side.

But here’s something new! At the end of the day yesterday I spent some time in conference with the organizing team for this year’s Cleveland GiveCamp. We already have bunches of eager volunteers, a floating venue, some early sponsorship interest, and a decently clear idea of what’s going to happen next.

What you need to know

GiveCamp is a bunch of designers, admins, software developers, and business people who pitch in for a weekend to create websites and software applications for free for nonprofit organizations.

This year in Cleveland it’s the last weekend in July, starting the evening of Friday the 29th and rolling through the afternoon of the 31st.

We haven’t decided which agencies and organizations are going to get new websites and software applications this year, but we will probably start accepting applications around May 1st.

We are already taking volunteer commitments! If you can design web graphics, or can lead a project, or know something about content management systems (especially WordPress), or write software, or are good at organizing, or if you just want to help–please sign up now!

We are also working on a sponsor packet, for companies and individuals who might consider donating money, materials, food, T-shirts, or services. That should be available within a couple of weeks. GiveCamp runs cheaply, but we still need a lot of food, caffeine, and supplies to keep it going all weekend.

Last year

Cleveland GiveCamp was a huge hit. We used all of the LeanDog boat plus half of Burke Lakefront Airport (thanks everyone!), had about 110 volunteers who worked on 21 projects, and left charged up to do even more this year! I personally know three people who got hooked up with new jobs as a result of the connections they made at GiveCamp, and everyone had fun. Also, the food was far better than at most tech conferences.

So.

If you’re going to be anywhere near Cleveland at the end of July, here’s what you can do:

• Volunteer for the big GiveCamp weekend of July 29-31.
• Start planting some mental seeds for sponsorship at the places where you eat out, work, or shop.
• Talk to your friends and associates in nonprofit organizations–do their current websites suck? Are they looking for some kind of new software program that doesn’t already exist?
• Watch this space, and ClevelandGiveCamp.org, for more in coming months!
• Are you in for this year? Were you there last year? Drop a comment and tell us how it went.

I promise hard work, nice people, and lots of fun. See you in July!

Specifically, I love the way Rails lets you do database access. The simplest way to hit a database table with Rails is to run a generate scaffold command that creates the table for you and writes all the code for a super-basic CRUD (create, update, delete) web application. You can edit the generated “scaffold” to make it prettier or to add functionality.

When you go just a little farther, you find that the ActiveRecord class does most of the boring database work for you. Every table (“Model” in MVC parlance) is set up to inherit from ActiveRecord, and you don’t have to write out (in your code) what columns it contains because ActiveRecord figures it out for you at runtime.

Better still, you can add lines to your Model code such as :has_many x or :belongs_to y to indicate relationships (joins) with other tables. Again, Rails works out the details. You really don’t even have to know what database software is being used; ActiveRecord takes care of the vendor-specific differences.

Those are some specific things that make Rails so nice for web and database development. One of the hardest things for some people is getting used to NOT writing so much repetitive code.

That’s at the top of my list. What do you love about Ruby and Rails? Comments are open.

This client doesn’t currently follow any Agile practices, and my project will probably be over with in a few weeks, and the rest of my team is in India. It doesn’t seem practical to try to change the way they work in such a short time, and quite honestly they seem to be doing pretty well with ordinary project management.

So I simply implemented a little KanBan for myself and pondered the interface to my teammates on the other side of the world. Here’s what I came up with.

To:	Client Technical Director
From:	me

Last week you suggested getting some subset of the Quux Project into a testable form so we don’t save all the testing for the end of the project. I am totally with you on this. The earlier we spot defects the better.

If we had a tester right here, I’d say that person can just pull cards from my “QA” chart (column on the KanBan) and verify that those micro-features work, one at a time. But that only works when you have a really small feedback loop. It’s not so good when the tester’s in India. We need to work in bigger chunks.

Milestones

I figured a good milestone would be something like this story:

• I can log into Foo Bar and see the Quux menu option
• I get the prompt to choose a Quux type.
• When I choose a Quux type I will get the corresponding legal verbage.
• I can click “Continue” and get prompted for begin and end dates.
• If I enter no dates here I’ll get an error message.
• If I enter bogus dates here I’ll get an error message.
• If I enter real dates then the “Continue” button will get me to the configuration page.
• On the configuration page…
  • …I can enter or not enter explanation and/or comments.
  • …I can select a titration caliber.
  • …I can click the “kick me” checkbox on or off.
  • …I can drop a Quux by clicking on “Remove.”
• When I click on “Complete and Submit” my Quux will be queued for processing.
• And by the way this all works without JavaScript, so it’s good on mobile devices and security-paranoid environments.

Another good milestone would be to demonstrate the stuff above with JavaScript turned on, seeing the dynamic calendar, and so on.

Another good milestone would be something like this:

• I can log into Foo Bar and see the Quux Management menu option.
• I can see the Quux I just entered in the previous story.
• I can see the Validation Track that has been set up for me and that Quux type (as you and I discussed on Friday).
• Ditto the Verification Track.
• I can see the comment/explanation I entered with the original Quux.
• I can see the “kick me” checkoff I entered when requesting the Quux.

Likewise for admin, approval, and verification tasks.

How to make the testing work

I was thinking of sending Sarai (the tester) the first story, in “I can do such-and-so” form. I’d tell her that if someone there pulls current source out of TFS and builds it on the testing system, she should be able to follow the story step by step and simply check off for each item: YES, NO with explanation, or COULDN’T TEST. Then the next morning I can follow up and fix the NO and COULDN’T TEST items.

The board

I’ve already designated the first story as the “Diamond Story.” Every card that is required to implement the Diamond Story has a little diamond on it. I’ll move the Diamond cards through to QA as soon as possible, then let Sarai know to try following the Diamond Story.

Next one will the the Club Story, and so on.

It’s the Simplest Thing

The mistake a lot of people make when they try to “do Agile” is… well, they kind of work too hard at it. The idea is to cut down on things that don’t get the project done and build up things that do get the project done. Spending a disproportionate amount of time setting up the perfect Agile process is itself not Agile. And it doesn’t make sense.

Don’t get me wrong, that guy deserved the slam on Twitter, seriously, but slamming isn’t my game. It’s not my whole game anyway.

So let me go answer some of Naomi’s questions here. Go ahead and fire back in the comments.

Q. What’s your game? What do you do?

A. Short answer: I take software projects that suck and make them not suck.

Real answer: Look, life is really hard. I’ve been working on one thing and the next, in about fifty organizations over the last fifteen years, and the same freakin’ things come up over and over again:

• Everyone’s tired.
• Everyone’s afraid for their job.
• Everyone’s wasting time spinning wheels on stuff that doesn’t work.
• Every software project is running late and pissing off the boss.
• Every boss feels betrayed.
• Every developer feels oppressed.
• Software projects suck.

And I’m going huh. That shouldn’t be happening. I mean, this is ostensibly a “first world” country with tons of resources and lots of educated people who can do stuff. Software itself is complicated, but it shouldn’t be as hard as everyone is making it. Very often, we really do know how to make it better but for any of a thousand reasons doing the right thing seems to be beyond us.

And that’s my calling. It’s really quite simple. I take the things that are already actually known about making software projects go well and apply them to real life, so regular people can solve problems, live better, and maintain a certain level of sanity at work.

Q. Why do you do it? Do you love it, or do you just have one of those creepy knacks?

A. That’s a weird question, Naomi.

I happen to love having knacks for certain things. Is that creepy?

Also, I am in it for the love and the hugs. It’s so cool when I can help decrease the project suck factor so much they’re sad to see me go.

Q. Who are your customers? What kind of people would need or want what you offer?

A. If you manage, pay for, specify, benefit from, or try to oversee a software development project, and it sucks, we should totally talk.

Things that make you much more likely to benefit from working with me:

• sense of adventure
• willingness to be surprised
• reasonable level of vulnerability

Things that make it very unlikely that you will benefit from working with me:

• rather be comfortable than successful
• like to be in control
• quick to make up your mind about things
• quite certain it’s not you

Not to go all New-Agey on you here, but Making Software Projects Not Suck is rarely just a matter of plugging away at code. I’ve had a few of those, but most of the time the problems are way deeper than that. Sometimes the things that Make Your Project Suck are the exact same things you love about the project: drama! action! involvement! Then you have to choose: would you rather have the drama or the success? Because having both is not an option.

I’ve even dealt with projects that, when you cut through the crap, are supposed to suck. Like one in which the lead developer was under the impression his job would end when the project did. Or one in which the project manager seriously couldn’t figure out how to live without the angst and panic. And there was the time–I’m not real sure about this one–but there was this kind of indentured-programmer setup and the boss kind of liked it that way. It was power.

So number one, the thing that totally stands out as the most important distinction, is that you have to want your project to not suck and you have to be willing to change. Okay, that’s actually two things.

Does that sound like therapy?

I guess it does. I’ve got people you can work with if what you want is real head-shrinking. That’s not my bag.

What is my bag is showing you the truth. Things like:

• control isn’t progress
• action isn’t accomplishment
• progress isn’t a deliverable

If you’re up for that kind of challenge, let’s do it. If that scares you, then we should definitely do it. Buck up.

Q. What’s your marketing USP? Why should I buy from you instead of the other losers?

A. Losers? There are no losers in this.

But here are a few things that make my services unique:

1. I help you get started using Agile practices (and feeling the Agile principles) at the tactical level. You can try one thing at a time–such as starting with pair programming–without having to commit to some big revolutionary cultural shift. It’s fine to experiment first.
2. I’m attracted to, and effective with, the high-stress projects that make people crazy. I tone down the hype and make it easy to keep working  instead of panicking. I’m anti-drama.
3. Unlike a lot of shops that offer “Agile coaching,” you can see my terms and fees up front, like here and here. I just think it would be weird to hide things like that in the sales cycle when so much of what I do is make your practices transparent. I’m asking you to open your shop and your mind. The least I can do is be upfront about my side of the exchange.
4. I still write software myself most days. It’s not theory.
5. There is homemade Indian food on Fridays, even though some purists object to the hot reddish-orange cast of my special aloogobi recipe. (It’s traditionally a yellow curry, and mild.)

Q. What’s next for you? What’s the big plan?

A. So glad you asked! I’m doing two things to make Project Desuckification more accessible even when I’m not.

The first thing

The first thing is that I’m documenting my processes a lot more diligently than I used to.

For example: before, I’d ask a few dozen questions before doing anything else with a new client. Now I write down a few dozen questions before asking. In a very recent meeting, I planned the whole interview, then diverged from the plan to follow some tangents, then got back to the plan so I could finish (almost) all of the questions.

That accomplished two things:

1. I remembered to ask about some less-immediately obvious things that would have flown out of my head in the give and take of the conversation.
2. I have a handy list as a jumping-off point for the next such initial meeting.

I’ll refine and augment the list in using it a few more times on successive projects. Before long it will be easy to turn that set of questions into a checklist, an article, a NOTACON presentation, or maybe even a Prfessor course.

So it goes with the other artifacts of Desucking: the emails that explain pair programming, my notes from debriefings, a particularly amusing burndown chart, bits of open source code. They’re resources for the next gig, but they’re also inputs for the next consolidated offering. Their specificity is what makes them so valuable; their universality is what makes them so useful.

At this point you’re probably wondering how I get away with ripping off all this stuff from clients who pay me to keep things private. I don’t do that! In fact, depending on the assignment, I ask them to join in my famous “Disclosure Agreement.” It protects their proprietary and confidential information, but makes clear that I can talk, blog, and publish everything else about the project. It’s like compost for desucking: useless where it came from, but invaluable for the next cycle.

The other thing

The other thing is simple timeline planning. Sure, I’m thrilled to death to help when your project already sucks. That’s my Thing. But unfortunately, projects reach the ultimate sucking point at unpredictable times, and there’s only one of me. They tend to pile up, and I have to turn someone down, and then their project still sucks.

So now I’m developing ways to make your project not suck before it even starts to suck. They’re principles and techniques that work at any time, are easy to implement, don’t require a lot of overhead, and make everyone more productive with less hassle.

That way I can plan ahead a little, and the potential clients can relax if I’m not right on the spot when things start to sink.

Most importantly and immediately, I’m developing some resources to help your team learn pair programming relatively quickly and get the most benefit from it. So far I’ve found that pairing is a very low-cost and simple way to get started with the Agile concept.

My research question: The managers who resist pair programming the most are the ones who just can’t wrap their heads around Agility. True or false?

So…

There it is. That’s my game. Wanna play? It’s easy (and free) to start. Just dive into the comments, and if my way intrigues you, take a nice swim in the “Contrarian Guide to Making Software Projects Not Suck,” even though it’s an opt-in link. Because the weekly emails are even more fun than what’s on the blog.

Good thing I that Making It Not Suck isn’t the immediate task. My job now is Figuring Out How It Might Potentially Be Made To Not Suck. In other words, it’s a pre-desucking evaluation. The deliverables: one report with a recommended technical process, and one report with business recommendations.

The client is on board with my famous Disclosure Agreement, so I can give a lot of details, but I don’t feel like identifying them too closely. I’ll just say it’s kind of a matchup site for third-party transactions in a niche vertical market. It matches buyers and sellers of highly specific machine parts.

There’s been a single developer on this website for five years now. It’s PHP4 or maybe PHP5. I think they said it’s maybe 120,000 lines of code or so.

It’s a membership business model. You don’t pay for listings or transactions. You just pay a monthly membership fee. Considering the value this thing will deliver, and the size of the realistic potential market for membership, I don’t think the client is crazy to think there is substantial profit potential here.

The site is technically online and operational now. By that I mean that there are a few members, who are not yet required to pay the membership fee because it’s all kind of pre-pre-beta.

It’s just that so many things on the site either don’t work at all, or work in really clunky ways. Some of the dropdowns don’t, the search function kind of works some of the time, and the pagination seems to do a SELECT * every time you click Next.

I don’t know. This could be an absolute nightmare to fix. It looks like a nightmare of Technical Debt. Maybe not. Hard to say.

Here are some of the things I want to ask first when I hang with the developer:

1. Where’s your version control repository? (I’m afraid I know the answer to this.)
2. How do you unit test? (I’m sure he doesn’t in the sense of actual TDD, but is there any repeatable process at all?)
3. Is there a backup you can “build” and run from?
4. How do you know when a feature is done?
5. How do you know when a feature is requested?
6. Can we describe this project in terms of Minimum Marketable Features?
7. Who is doing acceptance testing?
8. …and how?
9. I don’t suppose you have anyone besides me to review code with?

This may become another not-quite-Agile project. Maybe the right answer is to pair with this guy for a while to fill in skills gaps and create a rhythm of progress, set up a KanBan to regulate the feature flow, and work with the actual customer to nail down a very specific set of Minimum Marketable Features.

Also, I’d be really shocked if they have version control. That’s got to happen before anything else!

Business-wise, who knows?  There may not be funding to do this right, or even to do it wrong.

Among the Eight Reasons Why Software Projects Suck, I bet we’ll hit about six. I’ll let you know how it goes.

Problem: Not everybody sees that. Especially (perhaps) your boss or project sponsor.

So I threw this question out on LinkedIn earlier this year:

How much Agile have you been able to get away with? How?

One response in particular stood out for me. Lou Storiale wrote:

Sometimes Scrum can be implemented without anyone knowing it…. At first, I asked my staff (2 others) if they could meet 3 times per week for 15 minutes or so? They of course said yes. So we began meeting, I didn’t keep a specific regimented routine of “what did you do, what can you do, what is getting in your way,” I asked what’s on your plate for today, how much do you think you can do by “Friday” – anything going on (meetings) that might keep you from doing that?

That’s not a true Scrum, but it embraces the essentials of the standup meeting concept. The boss came along quite a bit later, says Lou, and asked what was going on. Lou (the project manager at the time) admitted he was doing what I call “Stealth Scrum.” The boss–not a big innovator or early adopter type–rolled her eyes and said, “Uh, okay.” And that was it.

“It works,”

Lou said. “That is what matters.”

Why?

This sort of thing, the bottom-up movement towards adopting happier development practices, happens all the time.

After my presentation on “Why Your Software Project Sucks (and how to make it not suck)” at NOTACON7 a couple of months ago, several participants hung around to ask more questions. One of them was really interested in Test-Driven Development, but he was looking at a million-line “big ball of mud” legacy system to start with. I pointed him at Working Effectively With Legacy Code, a book I blogged about in the past. At last report he’s awaiting shipment on the book. Rah!

Along those lines, one of the nice things about test-driven development is that you can sometimes (not always) just start doing it without permission from anyone. In a .NET environment, it means you have to download (for free!) NUnit and add a reference to your Visual Studio project. (Everyone who maintains the same project will have to do the same in order for their builds to work.)

Back to Why Stealth Scrum Works

Stealth Scrum works because, like many of the most effective Agile practices, it’s just a slight formalization of the things smart people are already doing to be as effective as possible. Whatever your formal methodology, or even if you don’t have a methodology at all, you probably check in periodically to find out what everyone is working on and whether they have any obstacles. If you don’t, why not?

Stealth TDD works because smart developers do unit testing anyway. The only difference is when you write the tests.

Stealth Pair Programming works because the best developers review each other’s code anyway. The only difference is that a pair does code review constantly, not just once a day or at week’s end.

What’s in a name?

Just as there are many shops that call themselves “Agile” but insist on top-down control of everything, there are shops that would never call themselves “Agile” but are actually doing a decent job of implementing the principles of maximizing the amount of work not done, adjusting and tuning, and making frequent iterations.

So if management won’t let you do Agile, don’t fight it. Just say “We’re gonna hang out and code in the same cube for a couple of hours.” Or say, “I’ve got this code written that will test our new features before the integration steps.” You might even get to deliver working code every couple of weeks as long as you don’t say the word “sprint.”

The Agile Principles are important. What you call your technique is not.

Have you tried Stealth Agile? How well has it worked for you? What are your suggestions?

Stakeholders weren’t really sure how ratings would work, but at least for now they were okay with saying an item’s rating could be based on the total of the ratings of all descendant records.

I’m not positive that’s the best idea, but it’s a reasonable one anyway. If your comment spawns a tree of comments-upon-comments that overall garner some high ratings, that may suggest your comment was pretty interesting. By the way, in this application you can have Comments, Questions, and Answers, as well as uploads of PDFs, video, and the like. They’re all interspersed in the Conversation tree. They can all get ratings.

The glaringly obvious solution

Well, you’d read a main record, then all its child records, then all of those records’ children, and so on. “But,” said our star Ruby guy, “that’s not gonna work.”

Rather, he went on,  what if we cached some intermediate results along with something like a cache timestamp, and (if I recall correctly, and I’m sorry if I don’t) feed some of the ratings up a level or two as kind of a precalculation. Posting the comment might be a little slower, but at least the ratings display gets a lot quicker in the bargain.

Trying to pull rank and be Mr. Super Agile, I said something like, “Dude, Do The Simplest Thing That Could Possibly Work. DTSTTCPW!” And I suggested we just skip the caching and pull all those rating records on demand–because a tree scan is drop-dead easy to code and doesn’t require a lot of deep thinking.

Also, I have to admit that the other part of my skepticism had to do with my faith in modern database engines. We hadn’t even chosen a production platform, but something like Oracle can optimize the heck out of a massive self-join operation. Why optimize it in Ruby code if the database knows best?

Our developer shot back: “But that can’t possibly work! You’re forgetting the W part!”

It’s not “Do The Simplest Thing,” full stop.

It has to be the simplest thing that could actually possibly work. And our guy was saying my admittedly oversimplified implementation concept couldn’t. Which brought me back to the idea of iterative releases.

Remember I said this isn’t a Scrum shop?

Well, it’s not. That means we don’t have Scrum Planning meetings, we don’t have Scrum Retrospective meetings, and we don’t have a true Scrum-style product backlog. And we don’t have a release at the end of each sprint, because there are no sprints.

There are intermediate development milestones though. When the star Ruby guy brought up the definition of “working” I went “Aha!” because he was thinking in terms of a completed, rolled-out, popular, busy website. When you have thousands of active users, caching queries can be important. I, on the contrary, was thinking in terms of iterations, and this iteration was going to be used by… like four people maybe. And query speed wasn’t their main momentary concern. And they might have come up with a totally different rating algorithm that would invalidate the caching strategy.

I don’t know. I’m not saying that throwing together something slow and crummy is “good enough” just because it’s a limited demo situation. On the other hand, I’m nervous about anything that smacks of premature optimization. But when you’re trying to do the simplest thing that could possibly work, it’s important to know what you mean by “working.” And I guess it’s important to guage how much the project is likely to change after the next iteration.

Where do you draw the line between slapdash and overkill? Is it an iteration thing? What do you consider “working” when doing the simplest thing?