I am a huge fan of the comical version of “bug-driven development”, which I earlier called “bug driven design”. Today, I want to propose a new methodology: folder-driven development. I cannot take credit for inventing it, a colleague of mine suggested it earlier this week. I found the idea a useful subset of the “divide to conquer” rule, and felt the need to put a bit of structure around it.
The basic idea behind folders is to reduce complexity. Before creating a folder, consider the following rules of thumb.
- Create a folder that is meaningful
- Make folders effective and productive
- Be proud of your folders
- Feel the need to create more folders.
Let’s examine one good and one bad example.
Java: Four Wrongs
The worst offender of the principles of folder-driven development is Java. By default, it forces you to organize classes in namespaces and namespaces into folders. This is the simple folder structure of the JNA project:
There’s no value in having the three top-level folders src, com and sun. Let’s put this to the test against our rules of thumb.
- Create a folder that is meaningful: both com, and sun folders are completely useless and contain nothing else than one subfolder
- Make folders effective and productive: every time I have to find source I must either cd three too-many times or make several clicks to expand in the IDE; it’s all busy work
- Be proud of your folders: since Sun sold to Oracle we have a bit less to be proud of; I’d love to delete the sun folder, but it’s the kind of refactoring that is likely to create a fist fight on the JNA mailing list
- Feel the need to create more folders: adding 1-3 I want to delete a few, not create more.
Rails: All Better
Rails looks like a substantial improvement. The top of the default structure created by rails new app looks like this:
- Create a folder that is meaningful: since Rails does MVC, folders like models, views and controllers make sense
- Make folders effective and productive: it’s easy to find a model and easy to find a controller
- Be proud of your folders: the helpers folder is often used as the garbage bin of functions, but a bit of discipline promotes refactoring of utility classes into clear models that one can be proud of
- Feel the need to create more folders: when unrelated models start filling the models folder, consider adding subfolders.
Happy folder refactoring!