Tuesday, September 13, 2011

Overstructuring


Today is 0xFF day of the year, meaning a holiday for anybody who can read in HEX. Therefore I'm going to present a little essay on directory structures and their overcomplication.


There is something magical about complicated structures. They seem to have lives on their own, attracting people attention like magnets. Their existence is predefined by the problems they are trying to solve. Some problems are really that complex and can't be simplified. But often engineers keep building complicated structures where the simple ones will do.

I will take Maven as an example, since I mentioned it in my latest posts. But you can find many other examples throughout the industry and beyond.

Maven Standard Directory Layout is stupid. It is an example of unnecessary complication. It is too deep with too many subcategories. I agree that the structure is smart and it fits well... For a big project. But the fact is that most of projects are not that big at all. Some of them are small, some are bigger, but none of these would really require the layout offered by Maven. What you end up with is a bunch of directories containing only a single subdirectory inside. And if this is the case, there was no point in the subcategory in the first place. The layout is overstructured.

Yes, I know that you can redefine the layout if needed. But the fact that this is the default layout and Maven "strongly recommends" using it for your projects makes it de facto standard, as most developers prefer to stick to it.

Just look over several Maven projects to find out that most of them have overstructured directory layouts. Actually, I can assume that 95% of them do. And only 3% will be able to fill that structure for real. Maybe somebody is wondering where is the missing 2%? These are the projects so complicated, that the directory layout offered by Maven is to primitive.

So basically Maven Standard Directory Layout fits only the small selection of real projects. Bad work in selecting your target audience, Maven guys! No wonder it took so much time for Maven to get into the mainstream since it's introduction in 2001.

Their layout is a classical design-by-committee example. Who said it is the right structure? It is claimed that number of industry experts are participated in defining that layout. I have no doubts on that account. Probably it was like:

"...we need source files and tests."

"Yep. And also place to store configuration files..."

"What about filters?"

"...and don't forget webapps!...".

Everybody tried to include their own vision of the structure. And the result of a compromise is an overcomplicated layout - with one folder for each expert!


Now, somebody could argue that common layout is necessary for developers to feel familiar with any Maven project, it requires less configuration and it also makes tool integration easier. All these things are true, but that is not an excuse for a complicated layout.

Most projects require only folders for source files, tests, configs and optionally for scripts and resources. It is logical to provide a simple layout which fits the majority of projects(95%) and at the same time give means to redefine it for complicated ones. It is possible to provide several layout profiles for different kind of projects. But the simplest one must be the default choice. Sure it would complicate tool development, but we are not in the business of making tool developers life easier.

Right now I'm promoting Gradle as the best integration tool for Java projects. No XML and clarity of DSL makes it a joyride. To my disappointment Gradle also inherited the Maven layout instead of rethinking it. Committee has prevailed over common sense and even Gradle couldn't resist the magic of overstructuring. C'est dommage :(

KISS! And happy 0xFF day! We're still controlling the power of machines... Are they able to control us?

1 comment: