Dev Anti Pattern: Unworkable Machine

Summary: 

 A developer in your team always has problems with their machine, to the point where they are less productive, and always trying to fix something before they can get things done. Usually this gets noticed during stressful times in the project's life.

Common Phrases:

• "It's happening again"
• "Yeah I'm just waiting for my editor to stop hanging"
• "I think [software] doesn't like me anymore"
• "Have you seen this cool thing?"
• "Ever come across this error?"

Possible Reasons:

• Boredom. The developer keeps installing weird f&$ing s$%t on their machine that has nothing to do with their work, that may have one or more collisions with the software they actually need to get things done with. Usually common with developers that have a very low threshold for boredom, who always seek things to install on their machine.
• Bug Recreation. The developer, in their attempt to recreate a hard to find bug, have turned their machine into a testing machine, so as to bring it to just the right circumstances for that bug to appear. 
• Multiple developers using the same machine (even with different users). Developers will f&$ck up a machine to fit just their needs. with no concern for any other user on that machine.

How to fix it:

Take them aside an explain the problem in productivity. Ask them to come up with a way where they will not screw up their machine due to this way of working.

possibilities are endless, and may include among others:

• Using a virtual machine
• having a secondary trial machine
• dual booting the machine 
• etc.

Comments

[Mark Dykun]

In general the possible reasons of this post site really non intentive destruction. I think you have to add another possiblity to the the list. When someone puts their machine into such a state, they need to get it out of that state. That alone is a make work project and will detract from getting the development tasks finished. You always should assume the best from people, but lets be honest there is the possiblity that these make work projects can be used to pad a consultants pocket or consume valuable company project $$s.

[Dave Nicolette]

It seems to me the suggested fixes are all pain-killers; that is, measures intended to mitigate the pain caused by an underlying problem that is not addressed directly. In an "ideal" agile team room, the collaborative work area ought to be equipped with development workstations that are all configured identically. Individual developers ought to be able to sit at any of these stations and pair with any teammate at any time. Additional process smells may be noted when this problem occurs, such as people leaving code checked out on the various development machines at the end of the work day. The machines in the collaborative work area need not be the same ones individual team members use in their respective private work spaces. People can configure their personal machines in any way they want, but the machines used for pairing in the collaborative space should be configured identically. When one of them gets messed up in the way described in the post, the "cure" is to reinitialize that machine with the team's standard image.

[Travis Illig]

I think there are two huge "possible reasons" missing:

First - Insufficient hardware/software to perform the required development. The post sort of makes the assumption (without stating it) that the developer isn't working on a machine not powerful enough to develop the product they're working on; that they don't have to do something crazy like develop for Windows Server 2008 on a Windows XP workstation; and so on. That assumption is continued when the possible "solutions" include hosting a virtual machine - a VM on a slow host is going to be even more slow and unbearable - or dual-booting - another non-starter if the hardware is insufficient.

Second - Development of a large system. If the product you're developing is large enough (for example, several hundred MB of source), chances are you're going to see some weird things crop up when you try to run and debug that system, particularly if there are a lot of developers across a lot of teams working in the same code base. It may just be that in project "crunch time" other developers on other teams become less disciplined about ensuring their changes don't break other people and it affects the person with the "unworkable machine." Granted, not many folks work on this sort of project, but the notion shouldn't be excluded.

I would say that before a team lead or manager jumps to any conclusions about why problems are cropping up, it'd be good to do some analysis.

[Alan]

There's another possible reason: Incompetence

It may be that the developer just isn't qualified or interested in managing their own development environment. An unstable development environment may be a sign that the developer is lacking the organizational skills, troubleshooting persistence, or self-confidence they really need to be successful.

[Zing]

Installing Windows is another common cause in our organisation. :-)