How many of you have actually asked for requirements for a project, been given some, and then all of a sudden new requirements come up while you're in the middle of coding?
It's annoying, frustrating, and we can feel our deadlines compressing every day. We're professional, trying to get things done and delivered when we promised, but it's so hard to get things done and properly planned or architected when the requirements keep changing.
It might be deliberate, it might be laziness, but often I think it's just that someone else is too busy with their job. Their job, at least as they see it, isn't to work on your requirements. It's to get something done. They've got x amount of papers or tasks in their inbox and at least y need to get done so they can go some on time. Or keep production moving. They don't want to invest in your project to make their life easier, especially after a few decades of software products that don't necessarily do that.
Not that it's an excuse, but it helps to just understand how other people view IT. We're a resource for them, we provide a computer, get it hooked to the Internet, give them applications, etc. However just like the phone company, they don't want us messing up their day with some type of testing or changes to the phone system. It's never convenient, and they just want to get their work done.
Many of us feel the same way. How many IT workers resist a new system or technology in their own areas because they have something that works well, they understand the bugs, and it will require more work from them to get up to speed. I know I've felt that way more than a few times, and often it's with each new version of Windows 🙂
There is some sort of balance here that a good manager or leader will strive for. They won't willy-nily push out new things for the sake of change or because they think it's more efficient. Instead they'll pick and choose those items which show promise, maybe institute pilots and they'll understand productivity will drop and not penalize workers with just more work.
Developers and designers should do the same thing. Attack the problems in little does, practice agile or rapid development with regular feedback, and most importantly, make the end user a stakeholder. Get them involved and make them think it's their project as much as yours.
The important thing for people building new software to remember is that you'll never get it 100% right the first time. There will be bugs, there will be requests for change and users will have new ideas once they see how things work. Expect there to be changes and embrace them.
Maybe this is why new products or features from Microsoft are only about 80% done. They know the requirements will change as people use the product.
Steve Jones
The Voice of the DBA Podcasts
The podcast feeds are now available at sqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.
or now on iTunes!
- Windows Media Podcast - 36MB WMV
- iPod Video Podcast - 28.6MB MP4
- MP3 Audio Podcast - 5.9MB
Today's podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.
I really appreciate and value feedback on the podcasts. Let us know what you like, don't like, or even send in ideas for the show. If you'd like to comment, post something here. The boss will be sure to read it.