Fog Creek Software
Discussion Board




Rearranging Furniture

Argh. I'm in that stage of development/delivery, where the customer is saying "add this header" or "change that text"

The problem is that early on in the project when the client asks for minor/cosmetic changes, it's so incredibly easy to just make the tweak while you're working on bugs or doing development.

But when you're in approval stages, every little "nudge" translates to hours of implementation, testing, and deployment time.

I just laid down the law to the client, in pretty much those terms - I'm giving them one more wishlist of minor changes, and that's it, but they have to give them to me all at once.

Fingers crossed that they accept said ultimatum in the spirit in which it was intended.

Philo

Philo
Monday, June 23, 2003

I'm afraid I don't quite understand this, Philo; how does a request for a trivial change like this translate to hours of work?

Brent P. Newhall
Monday, June 23, 2003

I can get this one: "What is Full Regression Test, Alex?".

Anonymous Coward
Monday, June 23, 2003

You've got to remember that it is not until your app has been used a fair number of times that its shortcomings come to light.

Also. as Brent says, distinguish between changes that require a load of testing and those that don't

Stephen Jones
Monday, June 23, 2003

Lesson: Spend some time early on templating everything, even if it means increased overhead for the app.

www.MarkTAW.com
Monday, June 23, 2003

Brent - AC got it right.
During development, the client had access to the app (a website & portal) on the development server, and we had periodic reviews. Things like "Can you change this font" or "Make that window pop up in a new browser" could be done while we were on the phone.

Now that we're going live in ten days, there's a dev server, test server, and two production servers. Any change to *anything* I implement on dev, regression test, move to test, regression test, then move to the production servers (during the midnight-4am maintenance window).

Add in a lack of faith in the client - they gave us a design for a complex report (late), then completely changed the design. We ate the change out of good faith. Then came "Oh, we forgot to add several subheadings" (okay, minor change, we'll do it). Now it's "no, wait, we want those to be major headings, not subheadings"

Well that's the point where I dug in my heels and sent the "rearranging furniture" note - I will NOT support randomly moving things around just because they didn't think of it last time or they don't like the way it looks. They get one more aesthetic change list, and even that is a good faith cost-eating.

For those that are wondering "why wasn't there a spec" - well, there was. But it wasn't specified to the nth degree; that kind of spec could've eaten the project budget in and of itself. In addition, this project is a loss leader to keep us in the game between major (six figure) projects with the client.

Philo

Philo
Monday, June 23, 2003


If the customer always accompanies their requests for changes with an extension to the deadline, then let them go ahead with their furniture re-arrangement.

If not, you're doing the right thing.

DingBat
Monday, June 23, 2003

I guess I'm used to Extreme Programming, where Full Regression Testing is done automatically all the time for all changes.

Brent P. Newhall
Monday, June 23, 2003

You're talking about "unit tests", Brent, not "acceptance tests". Acceptance tests are not trivial, automatic, or cheap.

Brad Wilson (dotnetguy.techieswithcats.com)
Monday, June 23, 2003

Blast - posted just as Philo was posting.

Question:  Have you told the customer the impact of each of these little changes on the deadline?  Something like, "Okay, we can do that.  However, we're already working full-time to get the server ready for deadline.  If we make this change, in order to test it, that will push out the deadline by a day.  Is that all right with you?"

Brent P. Newhall
Monday, June 23, 2003

Brad: according to what I've read of XP, acceptance tests *are* automatic.  They're not necessarily trivial or cheap, but they are part of the process.

Brent P. Newhall
Monday, June 23, 2003

"Lesson: Spend some time early on templating everything, even if it means increased overhead for the app."

Templating everything is a good idea, but it doesn't eliminate the need for more testing when changes occur.


Just because your code works with one set of text doesn't mean it will work with another.  Different template input can trigger previously unnoticed bugs in the template handling code, the presentation layer or the persistence layer.  (Anyone who has ever dealt with quoting/escaping issues in SQL code can probably give you a horror story or fifty on this subject.)

Mister Fancypants
Monday, June 23, 2003

"Full Regression Testing is done automatically all the time for all changes"


HAHAHAHAHAHA, if the program has any kind of ui, you are full of it!

Daniel Shchyokin
Tuesday, June 24, 2003

Indeed, let me rebuild this entire house because I painted the window green.

Simon Lucy
Tuesday, June 24, 2003

> Now that we're going live in ten days, there's a dev
> server, test server, and two production servers. Any
> change to *anything* I implement on dev, regression
> test, move to test, regression test, then move to the
> production servers (during the midnight-4am maintenance
> window).

On the times that I worked in this mode, nothing went to the production server before the release date, unless deployment issues were involved (e.g., app needs some lib/component, and we want to test the accesibility); and even then, the production server only got the minimal testing necessary.

Our cycles tended to be
- develop in the dev env
- move to test env (or "quality" env, as we called it)
- Users test on test env, and say "yay" or "nay"

No moving to the production server unless it was absolutely necessary.

At my present company, we'll be adopting this scheme soon, but for now our dev env & test env are on the same machine, in different instances of the app server. Deployment to the production server doesn't occur with each new version. Rather, it occurs only when there's something that needs testing in the production machine, such as:
- Are all libs accessible?
- Are all the necessary machines accessible?
- Are there timeout/refresh problems with the resource pools?

Why am I mentioning this? Well, I don't know about you, but, in my case, putting something on the production server is a heavy process, both in paperwork and people involved.

Paulo Caetano
Tuesday, June 24, 2003

I'm surprised that noone here is taking the client's side.

Remember when I said "The client doesn't know what they want... stop expecting the client to know what they want?"

Plan for clients to have lots of wording and aesthetic changes. They want their thing that you're building to look great. They're not doing it to cause pain. It is YOUR job to plan for these changes, give the client plenty of warnings, and give them printouts to edit when it's still early enough in the process to make changes. Clients don't understand that changes are expensive later in the process. It was your job to plan a series of approvals and edits early on.

Now, if you did do that, and they had plenty of chances during which they were told "This will be your last chance to change anything," then SOCK IT TO THEM! Building contractors make most of their profits off of change orders, you can do the same.

Joel Spolsky
Tuesday, June 24, 2003

I may have come across like a righteous jerk in this thread, and I apologize if I have.  I don't mean to sound like a holier-than-thou developer who thinks he's found the One True Way.

But I'm a big believer in developing everything test-first, as I've done it both ways and I realize how good test-first is.

Daniel Shchyokin raises the point that the UI can complicate test-first.  Yes, it can, but when you write test-first you separate your UI layer from your functionality.  If all your functionality is coded in your UI callbacks, then sure, you won't be able to test it, but that's bad code.

Regarding Simon Lucy's comment, a house is not the same as a piece of software.  I *can* rebuild my application in fifteen minutes.  Software is a heck of a lot more malleable.  Why not take advantage of that to make your code that robust?

Brent P. Newhall
Tuesday, June 24, 2003

The Rearranging Furniture metaphor is a good one...

Why should I know where I want my furniture to be when I hire the architect to design my house? If I want to add a television to the bedroom it should be trivial. I'm not changing the paramaters of the building, just the locations of some of - what I consider to be - minor elements.

It becomes a problem if the architect only put two outlets in the bedroom - for the alarm clocks - and now the constructoin manager is telling me he can't add an outlet on the other side for some esoteric reason and I'll just have to run an extention cord across the room.

Which gets back to my "template everything" statement, which, oddly enough gets back to the usability of MS Word - should you be able to move around the buttons or not?

Like literature, there are really only 7 main JoS forum threads that get recycled.

www.MarkTAW.com
Tuesday, June 24, 2003

Simon -
"Indeed, let me rebuild this entire house because I painted the window green."

Okay, let's not.
Window.Paint(green)

No testing, fiddle with other stuff.
Final walk-through on house.
Client asks "how come I can't see through this window? It's painted completely green! I'm not closing on this until it's fixed!"

Heh.

Seriously, I *have* been burned by things that seem like completely trivial changes. Not necessarily changing a label on a web form, but other "minor" changes have turned out to be not so minor.

For a simple example, change "Joes Garage" to "Joe's Garage" and find out where the developer hasn't escaped all the quotes...  Or the modern example - change a metadata field from "Mom And Pop" to "Mom & Pop" and watch the XML rendering engine explode.

Philo

Philo
Tuesday, June 24, 2003

Mark, absolutely you should be able to do that. When I had the basement finished, the builder had me come down just before the drywall went up to verify I had all the electrical sockets I wanted.

The reason I used the phrase "rearranging furniture" wasn't so much for the "where do you plan to put the bed when you move in" image, but rather "put the couch over there.... no... let's try it over there.... no... how about there... move it six inches to the left.... no... how about over against that wall..." to which most reasonable people will eventually react "okay, you get to move it one more time, then you're on your own"

Which is exactly what I did.

Philo

Philo
Tuesday, June 24, 2003

Philo - if you template everything - the language, the pages, it increases the overhead, but changes become more trivial. Sure you're referencing $storename everywhere, but changing "Mom & Pop" to "Mom and Pop" takes two seconds.

Of course, I'm not a developer - I'm an end user and I'm speaking out of my ass, but the products I've seen that are customizable seem to go over better than the non-customizable ones, and the "shrinkwrapped" applications that do this seem to do better than the ones that can't.

Besides, sometimes my ass has some interesting stuff to say.

www.MarkTAW.com
Tuesday, June 24, 2003

... though if this goes deeper than furniture moving and goes further in to process flow changing then that's a somewhat different story.

Who was the guy who made changes trivially because he had spent a lot of time setting things up right in the first place? There was a post about that a month or two ago.

www.MarkTAW.com
Tuesday, June 24, 2003

Does anyone here also have the experience that (internal) clients never realy test a system >before< it goes in production?

Just me (Sir to you)
Wednesday, June 25, 2003

*  Recent Topics

*  Fog Creek Home