Cathedral and the Bazaar reflections
It is a well-known fact in the software development community that adding more people to a project that’s already running late, will only cause it to be delivered later. That’s caused some people to live by what some call a “cathedral” way of building software, which is a shorter, easier way to refer to a project in which only a small group of highly focused people does all the work of developing, debugging and maintaining all aspects of an application. This method can be really stressing and time consuming for developers, given that they need to do everything at the same time in order to maintain software updated and secure.
However, there’s another way of doing this that’s proven to be more efficient in most cases. We’re talking about the “bazaar” way of building software, which refers to a whole community of not-so-focused people who all contribute to find bugs and sometimes even submit their ideas of a fix. Although I mentioned that the bazaar way is often more efficient, there’s a specific way to implement it in order to really get an advantage using this method.
First off, you don’t build an application from the ground up with a bazaar mentality. If that was the case, you’d be in big trouble. A large community trying to work in the same application at the same time would bring chaos, since communication between individuals and different teams would prove quite difficult, and as a result you’d probably get sloppy, buggy, probably-not-finished software that would kind of work, but not always, because most bugs appear in the interfaces between different developers’ codes and implementations.
You begin a project with a cathedral mindset: a small group of highly focused people working to solve a specific problem. Preferably, you’ll try to solve a personal problem, since necessity is the mother of invention. If you’re trying to solve a problem you don’t fully understand, then you probably won’t do a good job, because you’re not familiar with it, and have no idea of how it should be solved.
Once you have a platform to work on (you could think of this as the first iteration of your software), you need to know what to remove, what to add, but most importantly, what to rewrite. You need to be able to admit that there will be parts of your code that will need restructuring. It’s really unusual for an implementation to be perfect from the very beginning, so you might as well become friends with change, since it’s the only certain thing in a project. If it helps you come to terms with change, don’t think of it as having to restructure something that already works. Think of it as starting halfway towards a bigger goal, which is to make your software better and more robust.
Next to being able to identify what you should rewrite, the second most important thing might be being able to recognize when to start again. You need to be ready to start all over at least once. Not because your first implementation was a flop, or because it’s not good enough, but because problems evolve, solutions do too, and your first, second or even third implementation might not be able to cut it anymore and revisiting and rewriting the whole code would be much more time consuming than just starting over. Also, starting over gives you an opportunity to do things better from the very start, so think of it as a blank canvas to create a masterpiece.
Once you have a nice first implementation of a solution to your problem, you’re free to make it public and allow other people that might share the same problem use your solution. In fact, this is encouraged in the bazaar mindset, since a big part of it is treating your users as co-developers. This way, debugging becomes less tedious and more efficient, since you have hundreds, even thousands of users debugging parallel to each other, finding bugs faster, and sometimes even coming up with their own solutions, allowing you and your team to focus on really improving the program, instead of wasting hours recreating multiple use scenarios in order to find bugs.
Once you’ve really started to see your user base as co-developers, be sure to give them something to work on. Release early, and release as often as you can. This way, your testers can give you valuable feedback on your implementation, allowing you to fix bugs as fast as possible. With many beta-testers and co-developers, problems will become really easy to spot, since you have lots of people using your software in different ways and getting different results and experiences. With enough eyes looking at the same image, problems and bugs become way easier to spot, and by consequence, easier to fix. Many people looking at the same thing means having multiple points of view, and this proves valuable because while some might be too zoomed-in to be able to get a complete sense of what’s going on, someone else might be able to complement this with their broader sight, thus coming to a solution faster.
For this to really work though, you need to really listen to your customers, because what’s the point of having them test your software if you’re not going to listen to their complaints and suggestions? The whole point of this is to allow everyone to contribute towards building a better implementation. When you understand this and treat your beta-testers as your most valuable resource, they will eventually become it. They’ll be able to provide with valuable bug reports, fix suggestions, and most importantly: good ideas for additions to your code. The next best thing next to having good ideas on your own, is recognizing great ideas from your community, since the real users are often the ones that come up with the best ideas.
Now, some older members of the software development community might already know this, but for those who don’t: data structures really are one of the most important aspects of software. That’s why it’s so important to understand and know how and when to implement them. If you’re majoring in Computer Science, Software Engineering, or something else along these lines, one of your teachers might’ve already told you this, and it’s really important that you don’t underestimate this subject when becoming a software engineer. In most, if not all cases, smart data structures coupled with dumb code works way better than the other way around, so be sure to implement the correct data structures in your code from the very beginning; it’ll help you later down the road.
But sometimes, even if you’ve done everything correctly and everything works fine with your program, you’ll find out that there’s a radically different approach that provides a better solution to your problem, and it all comes when you realise that your whole concept of the problem was wrong. Seeing a problem with a brand new set of eyes can often be the enlightening you’ve been looking for this whole time. That being said, this connects with being able to recognize when you need to start again. If you see that your new point of view collides with your previous way of seeing the problem, you might have no other alternative than starting over to really tackle the problem from a different angle.
Perfection is rarely achieved, but when it is, there’s a special way of recognizing it. Some people think that something that’s perfect is something to which you can’t add anything else, but the real secret to perfection is not being able to take anything else away. Once you know you’ve got all the features you want/need in your program, you start to take away what’s not essential, what doesn’t serve any utility anymore. You may be able to see it as a purge, in order to have clean, efficient, non-redundant code that works just the way it should. Once there’s nothing more to add or take away, you know you’ve got your perfect solution.
Another trait of a perfect solution is that it not only works in the way you expect it to work, but it also lends itself to new uses that you might’ve not contemplated, and it’ll still be able to do the job. When your tool is able to do that, then you’ve created a truly great tool that will be able to help thousands, or even millions of users, even if they don’t use it the way you intended it to be used.
However, just like kids with toys, there comes a time when you simply start to lose interest. When you lose interest in a program, your life slowly starts to become dull and boring because you’re no longer passionate about solving the problem that once troubled you. You start to release new versions less frequently, you no longer pay attention to your user base, and everything just slowly turns to grey. That’s the moment you need to start thinking about a successor. If you no longer have the need to continue updating your software, find someone else who’ll do it for you. This someone needs to remind you of the younger version of yourself that was really passionate about solving a problem, so you need to find a competent successor that’ll live up to expectations from the community.
After that, you can start this process all over again. If you have the right attitude, interesting problems will eventually find you, and once a problem catches your eye and seems worthy of your attention, you’ll have found a new thing you’re passionate about, and this new project might bring a solution to another couple hundred or thousand of people who have the same problems you do. After all, software development community is all about sharing with and helping each other, so don’t hesitate to find people you can work with towards a certain goal. With a community like this, I can assure you we’re on our way to creating really amazing things in the future.
Update: Totally forgot, here’s a link if you want to read the Cathedral and the Bazaar. Totally recommended. http://www.catb.org/esr/writings/cathedral-bazaar/
