Does your IDE choice influence the way you organize your code base?
While working on open-sourcing a couple of components I was musing about the fact that I am doing similar work as some friends over at another company. However, there is one big difference: While I firmly believe that building a couple of small, independently developed and released components that can move at different development speeds and at different degrees of stability is a good thing, they have one giant source tree for everything.
They do release it in many separate pieces but the actual code base is one source tree. And everything gets released together with the same version.
When I joined my current company a little over a year ago, we were in a similar situation. And we made the conscious decision to split our code base up. Making it possible to take little pieces, isolate them, create a charter around them and then be able to say “this functionality or this piece of code belongs there”. Or, what is way more important, to be able to say “no, this should not go here”. Therefore giving the developers that are less familiar with the code base guidelines on how the can organize their code.
Looking around on the Internet and chatting with friends, there are many reasons why you want to do that. People call it “the google method” or want to keep “the code base squeaky clean because you have to compile all the code all the time” and others feel that it is necessary to be able to “re-factor every piece all the time”, which in component land, obviously would break any notion of backwards compatibility of APIs between pieces.
While both ways of organizing source code have valid reasons, my personal experience (which is admittedly Java/JVM language skewed) shows an interesting and a bit disturbing pattern:
See, there is the one true IDE. And the one true IDE only allows you to open only one project at a time. If you want to switch to another project, you either must close your current project or must open multiple windows (one per project). This is inconvenient, and you need to context switch and yadda yadda yadda. When using the one true IDE, having one big source tree is the natural way to organize your code because that is how it was ultimately designed to work..
Compare that to the other true IDE. It can open an almost arbitrary number of projects at the same time in the same window. And when using maven, projects that reference each other, automatically get tied together. There is also an often overlooked feature called “Working Sets” which groups the projects that you are working on into a small and easily navigable sets.
At my current day job, most people use the other true IDE. And the choice of using separate, small code bases worked very well for us. The only people that have so far given significant resistance or tried to overthrow this decision, were the ones that use the one true IDE. Obviously, none of them have ever raised the argument “Well, it is MORE CONVENIENT WITH MY TOOL CHAIN”, but if you read just a little between the lines, it is clear that this is an important reason for them.
As a software architect, tools are important but the more important question is: “What is the best choice for the organization?” And should a personal preference for a tool chain not only influence but drive the way an organization builds its code base?
Is it better to have a few really large source code trees or is a larger number of smaller repositories the more sustainable way in the long run?
For Ness, we made the choice of going with the larger number of small pieces. It has turned out to be a good decision and we can move fast because of this. And we made the decision after carefully thinking about the pros and cons of both approaches and revisiting it even a few times since then. We rationalized that decision away from personal preferences but because as a team, we decided that this is the best approach for long term sustainability of our code base. We did not allow a tool preference to drive this decision.
If you find yourself in the situation where have to make a similar call, ask yourself whether you drive it or your tool chain. And what would the call look like if you took your personal preferences out of the equation.
