I value simplicity
I’ve been trying for some time to put my finger on the uneasy feeling I have when I talk with or read from good, skilled, mainstream Java programmers. I think my uneasiness comes from a fundamental, basic, philosophic difference in values. I value simplicity. Of the 5 (or 7) XP values, this is the one that for me does not even need explaining. I think “surely everybody values simplicity, don’t they?” In fact, it seems not everybody does.
It’s always difficult for me to keep my blood pressure down when we’re talking about Maven, for instance. Maven solves a difficult problem, namely the problem of mantaining a collection of Java application modules and libraries across different source code repositories and servers. As a result, Maven is extremely complex. From the complexity come the many problems that Maven has: it’s slow; it’s difficult to understand; it’s difficult to debug when things go wrong. For that matter, things often go wrong with Maven, again as a result of it being so complex; in fact, complexity leads to fragility.
Given this preamble, I think you understand why I regard Maven’s complexity as a major, show-stopping problem. But, to my unending surprise, Maven fans don’t regard this as a problem. They regard Maven’s complexity as a minor problem, if even that. A necessary evil, perhaps, which they don’t think it necessary to spend much effort to reduce.
Now Maven is just an example; a controversial one at that, since in fact many good Java programmer dislike it. But the same arguments could be made against most if not all Java major frameworks; Spring comes to mind, and Hibernate, too. They’re way more complex than necessary; they fail for reasons that require divine, or at least guru, intervention to solve.
I have different values. I value simplicity. Less parts mean less things that can go wrong, less things to understand. I like it when things work correctly from the start. I like it when the defaults allow me to use something in a basic way with no configuration at all. I like it when simple things can be done in a simple way, so that difficult things become possible.
We stand on the shoulders of giants. Me, I admire the works of the Algol patriarchs, Dijkstra, Wirth and Hoare. And I admire the works of the Unix patriarchs, Kernighan, Ritchie, Pike and McIlroy. And the works of the XP patriarchs: Beck, Jeffries, Cunningham. And the works of the Smalltalk patriarch, Kay. All of them valued simplicity.
Hoare, Wirth and Dijkstra deserted the IFIP Working Group 2.1 because they thought the specification for Algol 68 was way too complex; it ruined the beauty and simplicity of Algol 60. They produced a famous minority report about their disagreement.
Kent Beck explicitly named simplicity as one of the 4 (now 5) values of XP. The XP method is simple to explain; it does not try to write down every single detail of what I as a programmer should do. Yet it contains just enough guidance; it’s precise and clear enough.
The Unix patriarchs valued simplicity. The VMS patriarchs didn’t, and as a consequence neither did Windows NT. A clear example is the difference in the API for creating a new process. In Windows you have
BOOL WINAPI CreateProcess( __in_opt LPCTSTR lpApplicationName, __inout_opt LPTSTR lpCommandLine, __in_opt LPSECURITY_ATTRIBUTES lpProcessAttributes, __in_opt LPSECURITY_ATTRIBUTES lpThreadAttributes, __in BOOL bInheritHandles, __in DWORD dwCreationFlags, __in_opt LPVOID lpEnvironment, __in_opt LPCTSTR lpCurrentDirectory, __in LPSTARTUPINFO lpStartupInfo, __out LPPROCESS_INFORMATION lpProcessInformation );
It has 10 parameters, many of which are structures with tens of other parameters. In Unix you have
pid_t fork(void);
It has zero parameters. All the things you can do with the complex and monolithic CreateProcess, in Unix you can do with smaller, simpler, modular calls.
It’s difficult to work together when we have a disagreement on fundamental values. For this reason it’s important that we recognize what values are important to us. Let’s talk about them, put them in the open, respectfully discuss about them. At least we will know what to expect of each other, so that working together in a fruitful way becomes a possibility, in spite of our differences.
January 28th, 2009 at 21:21
Matteo, I understand your point of view, but I don’t buy it :-)
Simplicity is for simple problems/projects/companies. Of course you can build your software incrementally, piece by piece, choosing the simplest solution possible on each step.
Unfortunately in most of the big companies that’s something you simply cannot afford. Some “environments” are inherently complex, because tipically projects involve different divisions, multiple vendors, remote and co-located workers (contractors, employees) and a weekly growing number of stakeholders.
You’re right when you say that Maven, Spring and Hibernate are complex tools; in a very simple project, they would introduce complexity.
However, in a complex environment, they introduce a common language, a common understanding and a common way to simplify the development. I’ve been in situations where every group created it’s “simple and effective solution” for building, deploying, writing services and persistence; strangely enough all the solutions they came up turned out to be incomplete, inflexible and, of course, different one from the other.
January 28th, 2009 at 23:08
I really value simplicity even if recognize I am not good at. imho Matteo get the point
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!
January 29th, 2009 at 09:18
@Filippo: This is the usual defence of complex solutions. In a way you’re advocating giving up and surrendering to the status quo. In my view, my job is to find ways to simplify things. That includes simplifying the organization. I don’t necessarily succeed, but I will certainly work in that direction.
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.
January 29th, 2009 at 10:38
@Luca: there’s a quote I love from, I think, Kernighan. It says: “Debugging some code is twice as difficult as writing it. Therefore, if you are writing code in the most clever way you can, by definition you will not be able to debug it!”
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.
January 29th, 2009 at 13:38
@Matteo: sorry, that’s really naive: “…is the usual defence of complex solutions. In a way you’re advocating giving up and surrendering to the status quo. In my view, my job is to find ways to simplify things. That includes simplifying the organization. I don’t necessarily succeed, but I will certainly work in that direction…”
I may add, that’s the usual defence of the “simple solution people”: if a company/environment is too complex, it’s wrong, and I won’t give up until I fix it completely.
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.
January 29th, 2009 at 18:16
Thank you for calling me naive. I think it’s important we don’t lose the naivete of thinking that things can be improved, and that we can be a part of this change.
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”.)
January 30th, 2009 at 12:13
This is a well written article. The process creation example made me smile :-) And the last paragraph was humble and respectful.
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.
February 1st, 2009 at 21:32
@Subhash
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.
February 1st, 2009 at 21:35
@Subhash
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 :)
February 4th, 2009 at 19:02
Hi Subhash,
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.
March 31st, 2009 at 18:56
>But Matteo I would really like to have a suggestion to improve my ability with simplicity!
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