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.