|Postcard from Software Development (1)|
A recent discussion over coffee quickly got more interesting than usual. A developer who felt he was under more pressure than usual commented on the difficulty of meeting what often appears to be an arbitrary deadline. In my experience, a lot of deadlines are arbitrary, but they're still important, so how can you minimise their impact on a piece of software?
I'm going to make a few assumptions -
There's no way round it, you have to perform triage on your requirements. You need to identify what must be done for the application to have traction, and don't let your manager or architect say "everything" . Work on what must be done for the first production release and make sure you have enough time to test before it's released. And this includes all the content that will be visible to the user. Grammar and spelling have to be right, interactions must be easy to see and understand.
After release, version 1.1 will be patches and bug fixes. Additional functionality will come in as version 2 (and probably version 3 after that). Users will be more likely to forgive an initial limited release with staged upgrades to follow than the full meal with lots of errors and obviously incomplete chunks of code.
It's important that someone takes repsonsibility for the quality of the released product, and as the programmer, you need to have a voice.
The other thing to mention is the importance of making your design and implementation extensible. Remember, version 1 will be the base for creating the second version, and you shouldn't have to do a rewrite to achieve that. It means that code layout should be taken seriously. Everything you write should be maintainable by someone other than you, and that's said from experience. I've painted (coded?) myself into that particular corner a few times before I learned.