Classic Mistakes in Software Development | Hacker News Reader

Classic Mistakes in Software Development

stevemcconnell.com.nyud.net

23 pointssoundsop9 comments

>"#6: Noisy, crowded offices. Most developers rate their working conditions as unsatisfactory. About 60 percent report that they are neither sufficiently quiet nor sufficiently private (DeMarco and Lister 1987). Workers who occupy quiet, private offices tend to perform significantly better than workers who occupy noisy, crowded work bays or cubicles. Noisy, crowded work environments lengthen development schedules."

The problem with private offices for developers, which is how I read #6 as advocating, is that it separates developers and cuts down communication. If you're a developer you're generally working with a team, and this has no team component. Joel got it right IMO: http://www.joelonsoftware.com/items/2008/12/29.html

EDIT: Something came up and I didn't get to finish my thoughts on this topic. You need to be able to strike a compromise between privacy and for focus, and openness for communication and making sure that the team has a single, unified vision. Joel does that well by giving each developer an office with glass walls. Everyone is approachable, and you can see what they are doing, pop in and ask a question, etc... But the distractions of office noise and chatter are cut out.

Communication between developers should happen asynchronously, because synchronous communication destroys mental state. That means IMs, not speech, should be the preferred mode of developer communication. That can happen just as well in private offices.

IM's are too synchronous if the developer doesn't manage them properly, or if the software makes itself obnoxious enough. Email is a better example of asynchronous communication.

Incoming instant messages almost always fall into the "urgent, but not important" category. This is a tripple whammy: a single IM can simultaneously destroy a developer's mental context, give him/her a "reason" to procrastinate, and accomplish nothing in the process.

The proper way to use IM at work is to set it up so that you notice you have queued messages, but this doesn't distract you enough to leave the zone.

This needs to be coupled with a policy that truly urgent AND important requests or questions come via phone or in person, and that there should be no expectation of an immediate response to an IM even if the person's status is "available".

But, as usual, the good programmers have already figured this out for themselves. The rest of your programmers (the ones you need to worry about), aren't going to figure this out for themselves and probably won't follow the policy when no one is looking.

I'm not saying "down with IM", but it can be a REAL time-waster.

I agree with the general discussion here. Asynchronicity seems reasonable.

The word that first popped into my mind was "flexible". Developers should be free to utilize open, collaborative spaces when necessary (by communication with each other about that), as well as take time in the office or elsewhere to dig deep into a focused design or implementation project.

It depends on the work, of course.

In defense of the link it does give a point by point summary of all the points in the book. However, most of the problem are those you encounter in a large company with poorly managed development. Even there a lot has changed since 1996. If you find a company with heavy front end requirements and no source control, just walk away.

I did find #16: Contractor Failure to be relevant in HN land. I have personally dealt with several startups started by business types who contracted all of the product development offshore, only to receive a product that just didn't quite make it, particularly in infrastructure. If you are going to do offshore work, you need a resident expert to manage it.

Nothing new here. Looks like some guy trying to promote his book.

How millennial of you. It's from 1996.

And it's actually a pretty good book if you are going into software development.

Reply on news.ycombinator.com