1 Reduce
2 Organize
3 Time
4 Learn
5 Differences
6 Context
7 Emotion
8 Trust
9 Failure
10 The One

“The Laws of Simplicity”, John Maeda, MIT Press 2006
http://lawsofsimplicity.com/

I think 1-4 are a great start

I know many good developer find that Maven is a good and useful tool. I resolve to not speak again about it until I’ve read the Sonatype book. It has arrived today.

Obviously I don’t know if this is the point for Matteo.

Your post just give me the opportunity to clarify my point of view :)

These words catch my attention

> Yesterday night

> I re-organized

How it will be when the team working on that code will grow to say 15 developers?

And when the code-base will grow to hundreds thousand lines of code?

And in 5-10 years when many different technologies will have emerged and used in the code-base?

Some project have these constraint, especially enterprise software, while others don’t. When is the case, simplicity should scale with them.

In that same humble tone, let me put down my differences:

Yesterday night I re-organized my project code (http://code.google.com/p/rest-client/) into a more modular structure, and all the while I was admiring Maven so much! It made my work so much easier. If I had done something similar, say in Ant, it would have taken considerably more time and effort. I understand that Maven is not without its own short-comings, but from my evaluation of the current set of build tools, I find it most useful for me.

I don’t know about your situation and I will not certainly presume to tell you what you should do. The thing I know is that local optimizations are not optimal. I don’t believe in “I do my job and I don’t make waves.” I will respectfully ask to collaborate with other parts of the organizations I’m in so that we can work together towards a *global* optimum.

There’s little to gain in improving my productivity as a programmer by 10% (not easy to do) when 90% of what I do is useless. That would result at best in a 1% overall gain. There’s a lot more to be gained in focusing on the real needs of the organization and of the customer; on reducing waste; on improving communication.

All of these important activities have little to do with *tools* and a lot to do with *individuals and interactions*.

http://flickr.com/photos/freedomtoast/280930261/
“Criticize shortcomings at a workplace without fear and hesitation!” (I would add “respectfully”.)

I value simplicity as much as you do, but I am also conscious of the environment where I work. There are reasons why big companies are structured as they are (usually related to the ability of scaling to thousand of employees, dealing with employee turnover, new hires, not being to tied to a single vendors…), and it’s not my job as software engineer/project manager to question that and fix the company itself.
I work in this environment, and try to find small optimization in the mess (isn’t kaizen, after all?); I don’t try to propose/impose radical treatments because that’s not what they are looking for.
With this perspective in mind, as I wrote before, a lot of tools you consider complicated, are actually big improvements. In these environments, they’re exactly the simplicity you’re talking about.
So I don’t mind having to study them, or mentoring people to understand them, since it’s a step ahead towards simplicity.

I think it extends to architectures. If we barely understand it *now*, it will be impossible to understand when things get more complicated! So yes, we agree.

As for how to become good at simplifying things: good question! Let me know the answer when you find it :) So far my recipe is to think hard, apply small incremental improvements, and try experiments.

Problems are inherently complex, but our job is to invent ways to look at them that manages, breaks down, controls the complexity. If I’m really good, I will show that the problem was not so difficult after all, when you explain it well. Think of teachers; the very same topic can seem obscure, or crystal clear, depending on how good the teacher is at explaining.

I agree that common tools and practices are good; it would be even better if those tools were simpler. I know that such tools can exist; just look at the Ruby/Python world for that; they’re light years ahead in my view. They value simplicity.

So I will certainly learn the tools of the trade of the organization I work with; I learn my Hibernate, my Spring, my Maven too. But I point out, to the Mavenites, that I was effective with humble old Ant without reading a big manual. Simplify your architecture, learn to not depend on so many frameworks and libraries, and the case for Maven disappears.

maybe because I’m good in dealing with very complicate problems that I’ve never get used with simplicity.

Maybe here lie the paradox:

when the problems get more and more and more complicated, says complex, the ability to deal with complicated problems do not work anymore. Here work the ability to imagine simple solutions.

So to me (and to Filippo and team members) when a complicated solution come out then I would ask this: “we know that this solution will work, now imagine that because it the sw will be be successful and will dramatically grow (x10 users, x1000 features, x1000 loc, x10 years, x100 developers) how can improve this solution to make it scalable ?

But Matteo I would really like to have a suggestion to improve my ability with simplicity!