Sometimes you get a spec
It can happen (I've seen two of them). It could be anything from a broad description of the project scope to a detailed functional spec. You've pored over it, scribbled on it, tutted at it, spilt coffee on it and emailed the salesman / project manager / client to clarify it, and now you're about to start work. Where do you start?
If you haven't already asked yourself this question and the rest of the world is already tuned out (doubtful, since you're reading this) and you're slouched, caffeinated and cutting code... stop. There's a thing or two you need to ask that spec before you go anywhere near the editor.
What are the risks? What little traps are there lurking in those carefully bulleted paragraphs primed to spring and derail your project a week before the deadline?
Do you need to track down any other documentation? Perhaps there's a bar code you'll need to scan which conforms to some standard. It could be an external standard or in-house, but you need to get that document now. You might not have intended to design the bar code reading module until you had a working database or a UI framework in place, but it might take days to track that standard down (perhaps longer if it originated at your own company).
The database and the UI are things you can probably do in your sleep, but you've never seen that standards document before and it might be incomplete. It could be the wrong one entirely. Make sure one of your first tasks (after acquiring the standard) is to prototype that scanning module.
Does the spec. call for any interfacing work with external systems? They will most likely have some kind of SDK or API and you need to know what is involved in getting them to work. Is the SDK / API in the same language as your project or are you going to need some kind of interop code? Get access to those external systems, hardware or software, as soon as you can and prototype the interfaces.
Does the spec. require something that is going to place undue strain on your target platform? There are still active technologies that don't have gigs of memory and broadband internet access and the authors of specifications are not always as geeky as you so they might not be aware that sending six Jpegs over GPRS is a lot different to sending three.
If you haven't already asked yourself this question and the rest of the world is already tuned out (doubtful, since you're reading this) and you're slouched, caffeinated and cutting code... stop. There's a thing or two you need to ask that spec before you go anywhere near the editor.
What are the risks? What little traps are there lurking in those carefully bulleted paragraphs primed to spring and derail your project a week before the deadline?
Do you need to track down any other documentation? Perhaps there's a bar code you'll need to scan which conforms to some standard. It could be an external standard or in-house, but you need to get that document now. You might not have intended to design the bar code reading module until you had a working database or a UI framework in place, but it might take days to track that standard down (perhaps longer if it originated at your own company).
The database and the UI are things you can probably do in your sleep, but you've never seen that standards document before and it might be incomplete. It could be the wrong one entirely. Make sure one of your first tasks (after acquiring the standard) is to prototype that scanning module.
Does the spec. call for any interfacing work with external systems? They will most likely have some kind of SDK or API and you need to know what is involved in getting them to work. Is the SDK / API in the same language as your project or are you going to need some kind of interop code? Get access to those external systems, hardware or software, as soon as you can and prototype the interfaces.
Does the spec. require something that is going to place undue strain on your target platform? There are still active technologies that don't have gigs of memory and broadband internet access and the authors of specifications are not always as geeky as you so they might not be aware that sending six Jpegs over GPRS is a lot different to sending three.
- Read the spec. like you wish users would read the screen.
- Identify and prioritise external risk.
- Prototype early.
Comments