

 10 Programming Proverbs Every Developer Should Know  - reazalun
http://www.kevinwilliampang.com/post/Programming-Proverbs.aspx

======
clarkdever
Whenever I read articles like this, it makes me wonder why half of it even
needs to be stated; then I go and look at the code base for some of the
companies that I do development for. At that point I realize that, planning,
documentation, and "fixing broken windows", are all activities that you need
to build into the core values of your company from the start. They need to be
so ingrained in the culture, that people participate in them on an intuitive
level, instead of it being a after-thought. The time spent working around
"known bugs" far (exponentially) exceeds the time it would have taken to fix
them before they were part of the current stable release.

------
randomwalker
I like the "bus factor" discussion. It's #3 in the article. In the projects
I've been a lead on, the bus factor is in a sense 1: each hacker is
responsible for their own module, and while others might read their code, they
don't contribute (except report bugs).

However, the modules are set up so that there is a clean separation between
them, with all interaction being through well defined API's. In fact, each
hacker typically uses their own server unless/until efficiency constraints
force us to do otherwise. So far it's worked well. If one person goes away,
the project can continue until they come back or one of the others can
learn/duplicate their module.

This allows us to dramatically increase prototyping speed, but may not be
sustainable as project size increases.

I'm fairly inexperienced, so I'd like to know what you guys think about this
practice, since it's something I think about a lot.

~~~
jwilliams
#3 - Seems to indicate that everyone in your team must be replaceable. This is
good from a management and operational perspective.

...but you can't stop people who are just damn good. In fact, often this
hampers them - i.e. You're too good at X, so you have to train a whole bunch
of people who are bad at it otherwise it's a risk. This is often applied
irrespective of the skill/talent of the person involved and the rest of the
team respectively.

Sometimes people just are irreplaceable. What you don't want are people who
are irreplaceable because of systemic issues.

~~~
chriskelley
Bridging the gap is always a pain. As a freelancer, I find that often I need
to steer clear of "better" (though perhaps technically complex) solutions at
times because I know it may create a panic when I leave. It's frustrating to
"play to the crowd" but I have also found it can be just as bad to leave
companies with elements their in-house employees can't figure out.

------
tjmc
Architecture astronauts should take careful note of points 7 and 9. I've read
some obsessive-compulsive discusions regarding RESTful design around here
lately. You don't see much focus on the customer.

