Reading07: A Code Divided

 

The first question that comes to mind: why not both? I'm assuming this is probably a popular take, as each model is appropriate for different scenarios, but I think it's healthy to understand and respect both concepts  and where their application is most effective.

"It may well turn out that one of the most important effects of open source's success will be to teach us that play is the most economically efficient mode of creative work."

Over my past two internships (same company) I worked with a small team of about four developers, including myself. Our work was very bazaar-style: code being passed around with no real structure. We followed the Agile methodology, but relatively loosely. It was the perfect situation for our team. Since there were only a few of us working on a much larger project, it would not have made sense to implement a top-down approach. Especially since our Project Manager had no real development experience (a former IT employee internally promoted), all oversight on code architecture would have fallen on one or both of our senior developers. This would have left me and our QA guy (EE grad, just happened to fall into that role after a rotational program) to write most of the new stuff.

While most real software teams are not this small, the bazaar model worked perfectly and allowed us to maximize efficiency. I was able to work on larger projects without much direction until I created a PR and inevitably got a ton of feedback. I would also review PRs as they came in and, surprisingly enough, found a few issues on my own. This experience definitely helped me to become a better developer, allowing me to learn and work on multiple parts of the system without any fear of following a 'standard.'

"A happy programmer is one who is neither underutilized nor weighed down with ill-formulated goals and stressful process friction."

Now to focus on the other side--the cathedral. If I were working at a Google office in CA and was tasked to add a feature to a service written by the NY team, I would hope that they took a cathedral approach--the same as my team, and every other software team at the company. As teams grow and split, it's important to have a common language through which they can communicate. Maybe uber-small groups within these teams can take a bazaar-style approach to development, but it better follow the architecture and style of the cathedral when it's pushed. If code is poorly written, it only hurts the next person, as their responsibility is now to fix your mistakes before they can even think of building on top. Pay it forward, it shouldn't be that hard.

Now, I've never worked for FAANG. I've never even worked on a real software team at a company with groups all across the nation. This is solely my assumption of a scenario in which the bazaar might be a net negative and overcomplicate development. From what I've heard, I can understand why entry-level developers at these companies are so restricted with what they can do--not only because of potential bugs and the scale at which they'd be released, but also the (likely) possibility that someone else will have to touch your code at a later date. If everything follows the same standard, the world is better off.

Let's just look at the universe--order is born through chaos. One model isn't 'better' or 'worse' than the other. Sometimes it takes a bazaar to figure out how to build a cathedral. Understanding and appreciating both approaches is necessary in a hacker's development (no pun intended).