“My buddy Fitz and I have long preached about best practices in
open source software development–how one should be open and
transparent with one’s work, accept code reviews, give constructive
criticism, and generally communicate as actively as possible with
peers. One of the main community ‘anti-patterns’ we’ve talked about
is people writing ‘code bombs.’ That is, what do you do when
somebody shows up to an open source project with a gigantic new
feature that took months to write? Who has the time to review
thousands of lines of code? What if there was a bad design decision
made early in the process–does it even make sense to point it out?
Dropping code-bombs on communities is rarely good for the project:
the team is either forced to reject it outright, or accept it and
deal with a giant opaque blob that is hard to understand, change,
or maintain. It moves the project decidedly in one direction
without much discussion or consensus.“And yet over and over, I’m gathering stories that point to the
fact that programmers do not want to write code out in the
open…”