We'll think about what we want

We've been wokring away on this project for a little over a month. It's due in 2 days. Just this second, the users came to me and as a result of playing with a beta version, asked if they could make just a couple of changes. These turned out to be major structural changes that would take 2 weeks to implement. But we can't slip the date. Ok, we'll put the changes into version n+1. No, can't you slip them in now?

Mind you, these are not bug fixes; the application behaves in the way the specs specified. The users just decided that they didn't want to work the way they thought they did.

I throw something over the wall to get my team leads' attention and he scurries over to fend off the stupidity (at least he tries).

The end result, they're going to spend a few days thinking about what they want to do. I mention that they can't come to me at 4PM and ask that it be done by 5PM. They seemed surprised.

And this, my friends, is why you never, EVER let non-technical people tell you how to build software. They can specify what it should look like and do, but NEVER how it should work.

And now I am going to get paid, again, to do the same work, again, because these folks won't let us walk through their designs with them to find these sorts of problems up front.

That's not garanteed though. I once had someone change their mind for the second time in the same day, after I had started quickly rewriting the interface from scratch.

And this sort of client behaviour is why I tended not to change things in front of them at my last job, even if it was only a 30 second job. If the clients didn't figure out how easy it was to change some things, they were then unlikely to subsequently ask for Ponies. On Sticks.

The first thing I usually do is build mock screens. These folks have had the alpha version for 2 weeks with daily builds as features were implemented. They just don't think things through. Edge cases? They don't exist. Special processing? We won't need it. Can you bring it in on budget? Not if you want all these changes.

We just got bought out and the new owners have decreed that any release that requires more than one QA cycle shall be deemed a colossal failure. While I usually beat my deadlines (by a fair amount), I now refuse to take on extra development (can you also slip this in?) because I now need to spend a lot more time bullet proofing my code. Naturally, the users and BAs aren't happy because now their utter lack of planning is costing them.

Exactly one year ago, we moved into spacious new quarters. Lots of extra desks, offices and conference rooms. Fast forward one year. All the senior managers (except the new owners) have been moved out of their offices into cubicles so that they can shove 5 desks for more consultants into the big rooms. Now they're talking about shrinking our 5 foot cubicles to 4.5 feet in order to get an extra 10 on the floor.

Idiots blindly following the clueless. There are a few of us who can think for ourselves, but it's like watching lemmings marching near a cliff.

That's not garanteed though. I once had someone change their mind for the second time in the same day, after I had started quickly rewriting the interface from scratch.

And this sort of client behaviour is why I tended not to change things in front of them at my last job, even if it was only a 30 second job. If the clients didn't figure out how easy it was to change some things, they were then unlikely to subsequently ask for Ponies. On Sticks.

In this case I didn't change anything in front of them (we were talking by phone). They changed their mind out of their own.

To be fair, they were dealing with changing requirements. To be fairer, they should have finished freezing requirements before asking me to start implementation.

I'm usually paranoid when it comes to business requirements. I always take in consideration that they may change at any time in the future, and try to make my code as flexible as possible - which is a good thing.

But with that client I had to verify requirements in the present. Stuff like, "an account is always in either in one database or another. The case where our clients have accounts in both databases never happens.". Or, "this field always has one of two values". Then I checked the database and see they were clearly wrong. That was probably the project where I put the most hardcoded assertions, just to remind me of all the places implementation broke whenever the ground shifted.

This, of course, is nothing new, and must have happened to all of us is varying degrees.

I see your edge cases and raise you simple human error. The craptastic winforms application I'm maintaining right now follows user specification to the letter. There is for example a form with 4 fields that have to be filled in to insert a new record. If any of them is left empty the application crashes.

You lucky bastard that you have a database. But yes, fact of life, business users are usually wrong.

I remember ages ago when I worked in a bookstore and we finally got a system that could tell us what the stock was and how often we'd sold a book - and how wrong we'd always been. That was pretty sobering.

The first thing I usually do is build mock screens. These folks have had the alpha version for 2 weeks with daily builds as features were implemented. They just don't think things through. Edge cases? They don't exist. Special processing? We won't need it. Can you bring it in on budget? Not if you want all these changes.

We just got bought out and the new owners have decreed that any release that requires more than one QA cycle shall be deemed a colossal failure. While I usually beat my deadlines (by a fair amount), I now refuse to take on extra development (can you also slip this in?) because I now need to spend a lot more time bullet proofing my code. Naturally, the users and BAs aren't happy because now their utter lack of planning is costing them.

Exactly one year ago, we moved into spacious new quarters. Lots of extra desks, offices and conference rooms. Fast forward one year. All the senior managers (except the new owners) have been moved out of their offices into cubicles so that they can shove 5 desks for more consultants into the big rooms. Now they're talking about shrinking our 5 foot cubicles to 4.5 feet in order to get an extra 10 on the floor.

Idiots blindly following the clueless. There are a few of us who can think for ourselves, but it's like watching lemmings marching near a cliff.

This happens a lot here. Often times I find that the managers who request applications, and who i meet with, often either don't truly understand what they are requesting or they request functionality that is far different from what the users actually need. As far as changing constantly changing requirements it would be nice if we could implement an agile development style. However this would be nigh impossible here given all the red tape. Not only do the managers here have to review everything but then we have to send it off to the state. It took them 2.5 years to approve a spanish language version of some content for a website, never mind the fact that some apps written 5 years ago are still awaiting approval. Basically we develop all these apps for the state and about 50% never get into any sort of production environment. Our internal apps have a much quicker turnaround thankfully, but still run into a metric ton of red tape and politics. Everyone in management wants to put their "mark" on them.

As for a 4.5 ft cube, I would love that. I literally have a desk in a hallway. And its right next to the restroom. Its a plus or minus depending what folks eat for lunch that day. I used to have a rather nice cube until we subleased one of our offices and moved all those folks over here. In the middle of that mess, I had a corner office for about a month before moving into the hallway.

Raymond Chen has a blog article about finding a number of errors like that being reported in Windows Error Reporter. They did a survey, and found it was due to overclocking-- usually local computer makers overclocking crappy CPUs to squeeze more money from clients.