I’m one of the beta testers for Stack Overflow, and I love it.
Stack Overflow is a community for programmers to ask and answer questions. So simple, yet so elegant. You can vote up questions and answers. You gain reputation points for having your questions/answers voted up. Gaining reputation points gives you more options – the ability to vote down, to retag others’ posts, and edit others’ posts. You can earn badges for your contributions to the community. It’s a lot of fun.
Jeff Atwood first described Stack Overflow in this post. He and Joel Spolsky are the creators – you can read Joel’s thoughts and sign up for the beta here. You can also read what Robert Scoble has to say.
If you’re even remotely interested, I’d recommend signing up for the beta – it gives you the chance to check it out and make suggestions for improving the site. It’s already really cool, and it can only get better – I can’t wait till it goes live.
As Josh mentioned in his last post, he’s been reading The Mythical Man Month by Frederick Brooks. One of the things I remembered best from the book was that projects commonly fail because of bad requirements. As a developer this point is very important to me – it means that when a project fails it’s somebody else’s fault.
The entire team is responsible. This should be true for all aspects of a project – everyone owns everything.
In many organizations only one or a couple business analysts are responsible for writing the entire requirements document. The rest of the team does not get involved with requirements and no one asks many questions when they get them. The developers use their own assumptions when a concept is not clear or an edge case is not covered. The testers also make their own assumptions about how things should work and then argue with the developers whether or not something is a bug.
It’s no wonder that projects with smart people can produce utter crap.
Bad requirements can kill a project, so there’s a lot of pressure to get them right. That’s not a very good motivator for getting your BAs to start producing requirements. Even for the agile teams there’s another major demotivator: an entire team of brilliant people are going to point out everything done wrong in the requirements. Being corrected is very humbling, especially so when the person being corrected is supposed to be an expert.
There have been times where I, a developer, wrote requirements and handed them off to the BA when it seemed that fear or anlysis paralysis was stagnating progress. I made sure to clarify to the BA that what I did probably wasn’t perfect and their expertise was needed to correct it. The response was practically immediate and we had our first set of solid requirements in no time. Life Lesson: It’s a lot more fun to be the corrector than the corrected. I don’t mind being the guy that gets corrected if it means we get our work done faster and my teammate gains more pride and statisfaction in their work.
If everyone is responsible, when should everyone get involved?
Here’s a question I’ve been meaning to ask more in interviews: When is the right time to bring your developers and testers onto a project?
The right answer: It depends.
Just kidding. It depends is the expert’s answer for everything. I’m looking for something along the lines of: Get them on board right away.
This is important, so let me say it again. Bring your developers and testers on board as soon as possible.
Why even a great BA shouldn’t be expected to take on requirements gathering alone
Well, your BA should be someone that understands the problem domain extremely well. Either one of the superstar users or their supervisor are great picks. They know all the important problems and they have a very personal stake in creating the best tool possible.
Unfortunately, these BA folks typically doesn’t think like a geek. I’m not saying that they aren’t technically savy. No, I simply mean that they don’t obsess over what could go wrong.
If you have designated professional BAs in your organization, you’re getting a slight hybrid – someone who can learn some of the problem domain and sometimes thinks like a geek. And sometimes you have to go this route because you simply can’t afford to free up a user/supervisor who knows the problem domain well because they’re too swamped with their regular everyday work. Consider this when you are filling future BA job positions – prefer to promote your internal superstars rather than hire someone external. It might be a huge pay jump from a Customer Service or Data Entry role, but these kinds of folks often know the business as well as or better than anyone else.
Anyway, I was saying we need some what-could-go-wrong thinkers to help mold the requirements into a masterpiece. Throw the geeky developers and testers into the mix and you’ll have most everything covered. They’ll ask questions like:
“What happens if the user accidentally submits a form before they’ve finished filling it out? Can they correct it after that point?”
“What if a user tries to edit the same account that another user is already working with? Would it be helpful to let the user know who else is working on the account so they don’t step on each other’s toes?”
These are the things a geek personality thinks about. These kinds of what-might-go-wrong thoughts make geeks miserable at dinner parties but absolutely critical for outlining project requirements.
(Side Note: I’ve twice gotten to work with BAs that were supervisor types that could think thoroughly in what-might-go-wrong mode along with the developers. These people do exist but are extremely rare and their names always begin with an ‘L’ and end in an ‘a’.)
Don’t do the wrong thing for the project and excuse it as “saving money”
Speaking of what-might-go-wrong thoughts… some of you might be wondering how in the world a tight project budget could afford bringing on developers and testers so early. After all, requirements can’t possibly consume everyone’s time. Management will never approve paying everyone to sit on their thumbs all day!
Your developers and testers can keep busy as soon as they know a small subset of requirements. The developers can start coding and testers can start writing test scripts. But also think about how much wasted effort is saved by having better requirements. Your developers and testers will also better understand the value of what they’re delivering and, if they are creative and motivated, can add a lot of innovation to the product.
I’ve seen the altervative and it still gives me nightmares. The worst is when after development the testers are handed the requirements document and told “OK, you’ve got two weeks to test this thing!” It will take at least two weeks for a normal human to understand a project let alone be familiar enough with it to test the dark corners of the UI.
In closing, don’t forget: Great requirements are the first step toward a great project. Take ownership in them and do your part to make the team successful.
From The Mythical Man-Month (emphasis mine):
A baseball manager recognizes a nonphysical talent, hustle, as an essential gift of great players and great teams. It is the characteristic of running faster than necessary, moving sooner than necessary, trying harder than necessary. It is essential for great programming teams, too.
Why is this so important? To paraphrase Brooks, it’s what makes a project meet its deadlines. When developers work harder than necessary, they create some padding in the schedule for the setbacks that will inevitably occur.
I always just assumed that the great programming teams had very intelligent developers with lots of knowledge and experience. I had never considered hustle to be an essential characteristic of a great team. But now that it’s been brought to my attention, I couldn’t agree more, and can’t see what could be more valuable. I’d pick a team with average experience who knows how to hustle over a team with lots of experience that doesn’t.
This has inspired me to hustle while I’m working. I want to be a great programmer. I’m going to work faster than necessary, move sooner than necessary, and try harder than necessary. And that’s not enough – I want to inspire the others on my team to do the same.