I haven't really posted in a long time. It's been pretty hectic at work with testing and finally rolling out the release. There are two basic points that I would like to address in this post. One, a salute to release engineers and two, my thoughts on the development process.
I was wearing one of my hats last week - release engineer. I have to say I appreciate the work that release engineers have to go through. In my naive "developer only" days - I thought that the release engineers had to take the stuff that developers give them and then package it. Well, the packaging can kill you. There are several cobinations that need to be taken care of. If your software is of any reasonable size, you have to decide how the parts go on to the CD/ CDs. You also need to think about different releases for sys admins (so that they can release it to their base via group policies) In additon, you have to deal with marketing and name changes and arrangements. Test machine creations - regular updates from developers. Getting everyone to agree on the build process. Getting a build process in place. Manage leaks so that there are no regression failures - or the cause can be easily determined and fixed. Phew! that's tiring and thankless work. So, here's a salute to the guys who do this every day - the release engineer! [applause in the background]
Anyways, lessons of the week include - talk to the marketing guys right at the beginning oft he development cycle to figure out what they want to see on the CD. Getting the technical support people in as well so that tools for them are built from the beginning and not at the end of the cycle. Plan for the next release.
After sitting through six years of college and having enough theory crammed into me, I have realized that there are two chains of thoughts in the development world. One that says you will realize all your requirements in the beginning - yeah, not happening! unless you are nostradamus and can see the future. The second thought says think in increments - relaize that you have to be flexible and start development from day one. Great, now you don't really write requirements, so developers are developing what they think you want and testers are testing what they think you want to test. No one really knows what the product is supposed to do and last minute requirements are the norm.
I have another theory that I think I am going to try out in the next release. I think that the requirements need to be agreed upon by everyone including the guys who will be doing post-sales support and implementation. Have a flexible set of requirements that you can add to, but not delete from so that developers are not wasting time. Put a hard stop on the requirements one month before release so that we don't have creep at the end.
Hopefully that will work better. I'll let you know how it goes.