Advantages/Disadvantages of Heterogenous/Homogenous Developer Workstations

Question

What arguments are there for and against homogeneous and heterogeneous development environments, especially for a Java dev shop. Is your shop and most of the shops you know about heterogeneous or homogeneous?

---

Extended explanation.

I just had a long discussion with my Manager regarding our development environment.

I work at a small Java dev shop (I'm on a team of 3) and we're developing our first Java Web App. Our stack at the moment is Spring WebMVC, Hibernate, DB2, Windows (XP Dev|2003 Server Production), Java EE 6, Eclipse, Hudson, Findbugs, Doxygen, JUnit, etc. The primary reason we chose Windows was because it was forced on us by the higher ups who don't want to have to train IT to admin and secure Linux. The oddity of it all is that they also don't trust our abilities to create something secure so they put us on a private network that is not connected to the Intranet in any way and also has no connection to the Internet. The hope, however, is that after we prove ourselves we'll get let out of the dog house and get back on the Intranet. In order to do that (get back on the Intranet), we basically have to be on Windows.

I have this impression, however, that developers work better when they get to choose their own tools. For instance, if I like Emacs or Netbeans more than Eclipse, I should be able to use Netbeans as it will increase my productivity, in theory. Developers seem to be, as a rule, obstinate, habit forming, curmudgeonly people who prefer to do things their way. Making them do it some other way seems to bite into that image I have of them and just ends up shooting the team in the foot.

My manager, on the other hand, said that he sees the inherent impedance mismatches that would happen between developer machines (possibly Linux and Windows on developer boxes) and production arising from differences in tools and platforms as far outweighing the relatively small cost of changing habits and tools.

My Question boils down to asking for anecdotal information or hard statistics that point to whether or not shops in general are homogeneous or heterogeneous and why they are that way. I get the impression that a company like Google or Amazon or Microsoft imposes no tool requirements on their developers and just lets them do their own thing. My manager doesn't have that impression at all and thinks that even if different parts of a corporation have different platforms, within a team the company will always choose to be homogeneous as it presents less opportunity for pain.

As a caveat, I'd like to hear about this specifically for a Java shop. My overall impression is that Java tooling tends to work best on a *nix stack as that's where it was primarily developed. Obviously, if you're a .NET shop, it probably makes far more sense to be on the Microsoft stack. Even though Java is supposed to be platform independent, the tooling around it seems to be more *nix centric (for instance, I've had trouble getting Hudson to run on our Windows CI Server but when I ran it out of Cygwin, it worked fine).

Thanks for your thoughts.

Answer 1

I would tend to agree with your argument that letting developers choose the most productive environment for them is a good thing. It can sometimes make help sessions with developers at each others editors/computers more challenging, but I'd err on the side of allowing people to be happy with their tools.

I'd probably start running VMs on the host OSes to be productive.

Not having access to the internets sounds really awful to me. There is a problem there. If they have IT people who don;t know what they are doing maybe it is better to train them or hire the right people rather than hamper the development team...

As long as there is a well-defined "Standard" platform that is the one that is built on and tested against, I'd say that heterogeneous environments make for more stable and better vetted products.

Most places I was at the teams had one basic environment - but some had additional tools, etc that they used. This freedom allowed developers to help each other improve productivity.

In a case like yours I would probably say you should eventually migrate toward some subset of tools, but allowing ANYTHING or dictating ONE thing seems like a bad idea.

Answer 2

I'd have to say that Homogenous is the simplest and probably more productive approach in the long term. It means that all developers are in the same environments with the same features and constraints. The language between them will be more consistent and the sharing of code/documentation/automation will be simpler.

A simple analogy would be something I've seen in practice where one engineer liked to work in metric units and the other preferred imperial. Someone read the imperial diagrams for a building as metric and ordered the desks... strangely enough they didn't all fit in the building. Consistency is sorely under-rated at times.

Answer 3

Your development boxes should match your production environment. If production is only Windows, then every developer should use Windows as their primary machine. If production is only Linux, then every developer should use Linux. If production is a mix, then you should have a mix of machines.

And you should certainly have access to all the OSs/browsers your users might have, so you can reproduce and debug issues that only happen on, for instance, Safari 3. :)

Answer 4

The main advantage of a homogeneous environment is probably that it is easier to manage. That's good for the admins.

The main advantage of a heterogeneous environment is probably that the code is exposed to a wider range of platforms, tools, etc. That's good for the product. If you make a web app, which might be used from any platform, this seems to be especially important.

And, as you say, giving developers what they are mostly used to and like best is another plus for heterogeneous. It's good for the code.

Note that these are principal considerations. In a concrete case there might be more to consider.

Answer 5

My team works in Java, on Windows boxes, but deploys to Linux boxes, with very little problems arising from the difference between those platforms.

Within the team, I would prefer a homogeneous use of configuration and IDE, since this makes it easier to get new developers started, and easier to make sure any changes in architecture or configuration get rolled out to everyone with as little pain as possible (especially since I am the one responsible for the configuration).

So, I have a set of recommended tools (I use IntelliJ IDEA). If other developers want to use something else (some prefer Eclipse), I let them know that they will be responsible for maintaining their own configuration and build process, and making sure that changes they make are usable by the rest of us. This works, by letting each developer choose whether they would rather deal with the pain of using a non-standard tool themselves, or deal with not being able to use their favorite tool.

Answer 6

"Developers seem to be, as a rule, obstinate, habit forming, curmudgeonly people who prefer to do things their way. Making them do it some other way seems to bite into that image I have of them"

Yeah, when you put it like that you really make me want to enable that bad behaviour ;-)

Choosing your own tools is good, provided that the productivity benefit to the individual outweighs any loss of productivity to the team as a whole. Usually I think it does, and I hate when someone announces I have to use Outlook or whatever. But sometimes it just doesn't - if someone wants the web-based bug-tracking software to work well with lynx, so that they can stick to the browser that makes them most productive, then they might have to forget about it. Development tools and services can only be interoperable up to a point.

Sometimes making us do it some other way teaches us (a) a wider range of skills, and (b) that it's easier than we thought to step outside our comfort zone. I think programmers, myself included, can be excessively precious about our favourite ways of doing things, and sometimes do just need to snap out of it. If all else fails, and you really can't be productive with Eclipse, you can at least compile emacs for Windows. It'd be worse if you were the other way round and needed some Windows-based tool in a linux-only shop.

Answer 7

Where we work, we have taken the line that we employ smart people and smart people make good judgements. We allow a lot of flexibility in both tools and technologies: if one developer wants to go and use iBatis then that is fine. If another wants to use Spring DAO, that's fine too.

We are smart enough to be able to debug each others' code although this may be because, as a small shop (<20 devs, in teams <5), the proliferation of technologies is eminently manageable.

The idea of working somewhere where everything is foisted on me, regardless of whether I think there are better solutions out there and irrespective of whether I think I can be more productive using some other tool (always allow a developer a choice of IDE) is anathema to me.

That said, for much larger companies, several points in my argument begin to creak a little!

EDIT: my colleagues have informed me that we give them the choice of iBatis only if they don't mind me complaining at them, and we let them use Eclipse so long as they don't mind daily reminders of how much better IDEA is. Rofls

Answer 8

I can't speak for shops in general, nor can I speak for Java but I can speak from my own developer standpoint having worked for large corporations and for myself using my own machine. I've worked in shops where we've basically hot desked and I've worked in shops where I was expected to maintain my own machine (not including the hardware) and I've spied advantages and disadvantages in each:

Firstly, in a shop where I've been provided set tools and had no flexibility on what those tools are I have to say - shame on them for not providing their developers enough flexibility but at the same time I understand their reasons for the way they are. Their I.T. support team is only so large and there are only so many pieces of software they can adequately test and approve for a software build on a corporate machine. I much prefer being able to have the software that I'm used to and enjoy using than been tooled up by someone else using generic tools that aren't customized to my own idosyncratic ways.

However, in this scenario, I have the luxurious advantage that if my machine goes down for whatever reason and I can't work - it's not my problem, that becomes the problem of the I.T. support staff and if I'm not working, they'll have to suffer the wrath of my manager. I just pick up the phone, call I.T. support and tell them my machine is hooped. When they ask what the problem is I feign idiocy like the other 99% of the staff and they come and fix it. It's great, I never have to worry about the stability of my machine or the software on it as that's not my problem which is actually quite liberating. If it does go down, I can hop on someone else's computer and carry on where I left off - using the exact same toolset as we all have the same until my computer is fixed and I don't have to waste time fixing it myself.

Secondly, the scenario where I build and maintain my own system and it's completely customized to every need/want I have, right from the O/S all the way up to the development IDEs, diff tools, debuggers, hex editors, graphic editors, office tools, you name it. That machine is mine and mine alone. If anyone else touches it, I feel really protective and get this feeling like "get the hell of my goddamn computer!". In this environment, of course, I can work at my peak rates and be the most productive I can be - when it works. If however the system goes down, I'm left with the problem of "what the hell do I do now?". At best, I've gotta waste time debugging the problem, finding a fix, updating it. At worst I've gotta re-image the damn thing - assuming I have an image that's up-to-date with all my software and profile.

All in all, I think I would prefer a blend of the two - I want my custom software build tested and approved and I.T. to support it for me. I know that's unreasonable though, heck, they've not heard of half of the software that I use every day - how on earth could I expect them to support it? So I settle on the other side of the compromise - as long as the tools provided in the standard build are "good enough for my purposes" and I can use them comfortably, even if I have to jump through some hoops occasionally, I'd rather have I.T. support my system than support it myself.

I have to say though - a software developer without internet access is like a sniper with no eyes; How on earth they expect you to be productive without access to information is beyond me - unless you carry a bookcase full of books around with you. That's retarded!