
Classic Mistakes in Software Development - soundsop
http://www.stevemcconnell.com.nyud.net/rdenum.htm
======
mnemonik
_> "#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.

~~~
bdr
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.

~~~
philwelch
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.

------
russell
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.

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

~~~
pxlpshr
How millennial of you. It's from 1996.

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

