Folder-Driven Development: when to create a folder?

rails | ruby | architecture | testing

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.

Guiding Principles

The basic idea behind folders is to reduce complexity. Before creating a folder, consider the following rules of thumb.

1. Create a folder that is meaningful
2. Make folders effective and productive
3. Be proud of your folders
4. 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.

1. Create a folder that is meaningful: both com, and sun folders are completely useless and contain nothing else than one subfolder
2. 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
3. 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
4. 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:

1. Create a folder that is meaningful: since Rails does MVC, folders like models, views and controllers make sense
2. Make folders effective and productive: it’s easy to find a model and easy to find a controller
3. 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
4. Feel the need to create more folders: when unrelated models start filling the models folder, consider adding subfolders.

Happy folder refactoring!