views:

224

answers:

7

I am trying to get a better idea on this as so far I have had mixed answers in person.

I am a solo dev in a 5 man IT dept for a Health Care related business. My developer machine is running Win 7 RC1 (x64) but my users are all running Win XP Pro (x86). Is this a big deal? Whan kind of pitfalls should I be aware of? Is having a VM of the user image enough?

Should my environment completely mirror my end user's?

+8  A: 

Your development environment doesn't need to mirror your user's environment, but your testing environment certainly should!

Having a VM of the users image for testing would probably be good enough.

Eric Petroelje
I disagree, esp. for client development. They need to be fairly close. For example The security issues from XP to Vista are a lot different, and having to move everything to a new environment to test is not always realistic.
eschneider
@eschneider: I would agree if development would usually be done with the developer having only the same limited permissions the typical user has. This is however rarely / never the case, so testing in a different environment is necessary anyway.
mghie
It's virtually impossible for a developer's environment to match the client's environment. Now, if you want to talk about permissions, that's a different story, but even that can be tricky (development software often demands a broadened set of permissions). I'm inclined to believe that it's a *given* that the development environment is a *superset* of the client environment, and that the test environment is expected to be identical (or nearly identical) to the client environment.
Mike Hofer
A: 

Typically you want to develop on the same OS that your user base is using for client development. But if it's a simple application, it may not be a big deal.

The bigger differences in the development environment from the users environment, more chance there will be a problem when in the test environment or deployed.

Feature sets are different on different OS. Some services may/may not be available.

For example you can't run just .NET 1.0 or 2.0 on Windows Vista you must have 3.0 >. This can cause deployment issues as installers are usually built on developer machines. I had this issue when doing some Government work. They would not allow .NET 2.0 SP2 to be installed and other clients using Vista could not install .Net 2.0.

Your hardware should be comparable also. If you user base runs older machines you application may run so slow they will complain. Also software runs differently on dual core vs. a single core. A striped raided machine will do most file system task much quicker. Some software does not work properly on 64 bit, I have video driver problems on this laptop at the moment. The Zune client will not run on XP64 (With-out major hacks)

eschneider
A: 

Is this a big deal?

Yes, it is. You have an OS 2 generations ahead of the one the users have, including you are running a non-release version.

Whan kind of pitfalls should I be aware of?

Depends on what you are developing. Some libraries may be missing that you already have, then the versions may be different etc.

Should my environment completely mirror my end user's?

Not necessarily, but you definitely need to have a testing environment that corresponds to the one the users have.

If you were developing web applications, all that would not have been an issue (well, unless you used some fancy fonts that are not present in a clean OS by default).

User
It's no big deal. A developer machine does not count as a clean OS install by far, so I wouldn't put much weight on differences in OS - even the same OS version would be sufficiently different from a typical user install. Testing needs to be done on (multiple) clean VM installs anyway.
mghie
+1  A: 

Its unreasonable to develop on exactly the same type of system as your users. If nothing else, your life is made much easier by installing all sorts of developer tools your end users have no reason to install. I hear Visual Studio in particular likes to squirrel a number of potential dependencies onto a system.

However, you do need to test on a system more inline with that of your end users. If you have access to an image of such a system, your VM approach should be sufficient. If nothing else, you should try for a staged (or better yet, beta/trial) release so as to avoid pushing a completely broken app out the door.

In short, don't fret about the development environment but put some thought into your testing one!

Kevin Montrose
+1  A: 

It's effectively impossible for any two machines to be set up the same, so development and production environments will always be different. One advantage in them being VERY different is that you will be more aware of possible deployment problems.

anon
+1  A: 

The type of environment that you need to use for testing entirely depends on what you're developing.

If you're writing web applications, having a VM with the user's standard image should be more than enough (just make sure the VM contains all the browsers your users might be using). Web development is much easier in this respect (I'm also running Windows 7 and have a couple VMs to test various environments)

If you're writing a full desktop environment, you'll probably want to ask for a second computer that you can test on (even if just to test before a final release). I say that because of differences in hardware. Just imagine if something runs fine for you, but slows down the users computer so that everything else is unusable. Opposite of that, you might spend hours trying to make something faster in the VM whereas running that on a users computer might run just fine.

Relster
+3  A: 

First and foremost, as a developer, your machine will never look like your client's machine. Just accept that.

You will have tools and utilities installed that they won't have. That will fundamentally change the configuration of your machine from the outset. You have DLLs, applications, services, and possibly drivers installed that your users have never even heard of (and likely never will).

As far as the OS is concerned, Win7 and WinXP, despite claims to the contrary, are not the same animal. Don't believe the hype. Having said that, don't believe the anti-hype, either. Just be aware, as you well should, that any piece of software developed under one version of an OS is not guaranteed to behave the same way under another.

The short of it: Yes, it's important that your environment is different. Should you panic about it? No. Should you account for it in testing? Absolutely. As rigorously as possible.

Mike Hofer