If you’re reading this blog, chances are you have looked at a challenge spec or two (or a thousand). You’ve also probably noticed every challenge is different. Sure, it is pretty obvious and expected that the requirements change by project and by technology, but you’ve probably noticed that the writing styles change too.
Why is this? Well, writing a challenge spec is a very human task taken on in a very technical world. Who writes these challenges? Copilots, challenge sponsors, challenge architects, and partners are just a few possibilities of who actually writes out what you read on topcoder every day. I myself fall into that challenge architect bucket, where I spend a lot of time working directly with challenge sponsors to identify what they want to build, and then translate it into the challenge that you register for (and hopefully submit to)!
Thus, I figured it would be nice to share my methods for creating challenges to help give an inside look on how I operate when putting them together.
Everyone has their own tricks and methods, so keep in mind this is just one perspective.
1. What are we building!?
At the beginning of every project, there is a lot of front-loaded effort to identify what exactly a challenge sponsor is looking for. It usually takes multiple challenges, and we will spend our time in meetings mapping out functional and technical requirements for the project as a whole.
After this comes a phase where we break the big project into multiple challenges. We’ll figure out what services we think we will need, and what designs need to be crafted.
2. Inputs and Outputs
Now that I know the overall plan, and know the next step to be taken, I can start working on the actual spec. To me, this involves identifying the inputs necessary for a challenge, and the desired outputs. Usually the inputs are the toughest part here – it can involve getting technical dependencies from the sponsor, researching open source libraries, or creating fancy flowcharts. Sometimes, I’ll take prototype screenshots and mark them up, pointing out how various features are expected to behave.
Those inputs aren’t always attachments, they’re also the requirements. Sometimes, it can be as simple as a bulleted list. Sometimes, I write a wall of text (which I usually delete and replace with bullet points). Also, there will be some sort of context for the project so you’ll understand where your efforts fit in.
The outputs tend to be what you’ll see listed in the submission deliverables – I need to make sure it is 100% clear what we expect to see come back. Sometimes it is standard, sometimes we have unique requirements. I do always try and make sure each input I provide maps to something that is required in the submission.
3. Put on your blinders
Now I reread the spec and try to take on the perspective of someone who has literally no idea what is going on. It is amazing how often you take for granted the context and features of the applications from all your interactions with the challenge sponsors. The community members reading this do not have that benefit, so I need to make sure I explain the specs very clearly.
Putting on the blinders is when I read the spec and try to imagine what could be confusing without the knowledge I already have. Sometimes I end up throwing away a spec and restarting since I realize I made all kinds of crazy assumptions about what the community would know.
It helps to share the spec with a colleague or copilot as well, since usually they don’t have that context and can point out to me when I’m asking for something totally crazy.
4. Brace for the storm
Now that I’m confident the spec should make sense to just about anyone, whether they’re involved in the project or not, I can go ahead and launch it. If all goes well, I will be bombarded with questions in the forum.
This is a healthy process! I’m sure there is no such thing as a perfect spec and generating meaningful discussion in the challenge forum is critical to ensure the challenge is a success for both the sponsor and the participants.
It is my goal to ensure all participants in challenges I post fully understand the request and are equipped with the tools they need to be successful. If you’re reading this, please take this advice: POST IN THE CHALLENGE FORUMS! It keeps us engaged with you, and we genuinely value the chance to help and to get to know you.
This is a brief glimpse into my brain when I craft a challenge for the community to dig into. I’d love to hear thoughts from the community itself about the methods and what you think works best in challenge specs. Tell me your favorite challenge specs, and tell me some of your least favorite. You can all help contribute to better challenge specs by providing feedback.
Hit me up on twitter with your thoughts: @will_price