Maintainable Programmers

Note: this was written for and posted at lesscode.org. See over there for a number of excellent comments.

I thought it unfortunate that the controversy kicked up by a few (now retracted) passages in Brian Fioca’s article about WASP detracted from a proper discussion of the article’s real flaw. I addressed the controversial, less interesting sentiments in comment over there, but wanted to take a few moments for a longer commentary. It took a while, but here we go.

The true failing in that article is a terminal case of corporate-management world view. Let me quote a little out of order to highlight this:

Sure, you can write spagetti code in PHP 5, but if you have a well designed framework that keeps PHP code outside of your HTML and in tightly structured classes, you’re more likely to end up with code that looks and works and feels like Java.

The implication appears to be that anyone in the real world, if only they’re using Java, writes well structured and maintainable code.

I think the real world has a few surprises in store for people who think that way. As the saying goes, real programmers can write Fortran in any language.

Deemed “hacker” languages, scripting languages can be quick to write, but since they do not have many of the advanced features of compiled languages like C++ and Java, they have been prone to lax design practices, leading to code that isn’t efficient, stable, or maintainable enough for large solutions. With the correct mindset and help from structured frameworks like WASP, this no longer has to be the case.

This claim is a crock. PHP has a very low barrier to entry; consequently, a lot of eye-wateringly bad programmers are writing code in it; hence, a lot of code written in PHP is awful. This is arguably a good thing: a lot of people who have small needs are empowered to meet them on their own despite having little skill, which would never happen if Java were the only option available.

To conclude that if these programmers did learn Java, they would suddenly turn out maintainable code, or that if a good programmer changed camps from Java to PHP, the quality of his code would suddenly degrade, is fallacious.

Again, you can write pretzel logic in any language.

Until recently, platforms like Java were more likely to provide a stable, proven foundation to design and build well designed code, however by their nature they introduce a level of complexity that takes extra time to overcome.

The entire “more likely” clause is a myth, perpetuated by a middle management population that has absolutely no clue whatsoever what makes code good.

Using scripting languages like PHP tended to produce code in a faster time frame, but it was often impossible to maintain the architectural integrity necessary for building maintainable, extendable applications.

This is true – in an extremely local sense.

The overall design of large Java systems will tend to be more convoluted than that of almost any system written in a dynamic language, simply because the contortions forced by Java require larger overall designs.

Java buries the intention of code under a thick layer of implementation details and typing bureaucracy. Programmers are drilled to execute the requisite gruntwork in repeatable, predictable ways. Moreover, doing so conditions them to design their own system to cater to these reflexes. A maintainance programmer who comes in later will therefore easily be able to make changes to the mortar of an application. Unfortunately, that does not ensure good high-level designs nor does it translate to easy refactoring of convoluted architecture.

Dynamic languages abstract away huge swathes of gruntwork and require less structure. This means small systems have small implementations, which directly translates to better maintainability. The price is a loss of exemplary structure and of conditioning, which requires better innate architectural skills and stronger discipline when building larger designs; neither are strong points of the average programmer. However, designs in such languages aren’t frequently large, because the language does not require large architecture for modestly sized systems – which the majority are.

I have seen as many examples of truly terrible designs in Java as I have seen examples of completely unreadable code in Perl. Maintenance problems may manifest in apparently different ways, but their cost does not degrade appreciably when they afflict a system written in a “more maintainable” language. The only objectively measurable difference is in the amount of required code.

Why would you want to stick with PHP even in situations when you can use Python, Ruby, or anything else?

Simple. Because it’s cheaper to hire programmers that can write code in PHP. And if you have a good technical lead and a well implemented framework, your cheap programmers are going to pick it up and run and write good (and maybe even less) code.

(Brian writes this in a response in the comments, not in the article.)

This is a fear-based middle-management hiring strategy. Good developers know that “cheap programmers” will never hit the high notes. You can hire 100,000 code monkeys and they will never produce the same quality as 5 stellar programmers.

All these quotations are pervaded by a disregard for the fact that programmers are craftsmen; for the fact that that the language, framework, and whatever else they use in the course of their work is a tool. Good tools matter, but the stated opinions read as if the programming language is the principal factor in the quality of the result, when the truth is that it’s the programmers who ultimately matter.

If you hire good programmers, maintainability won’t intrinsically be affected by whether your in-house software development has standardised on Java, PHP, Perl, Ruby, Lisp, Smalltalk, Haskell, or Self. Good programmers can appreciate and can create good design regardless of language, and they can absorb a new language easily enough. Or as Joel Spolsky says:

I have never met anyone who can do Scheme, Haskell, and C pointers who can’t pick up Java in two days, and create better Java code than people with five years of experience in Java, but try explaining that to the average HR drone.

But whether your system is written in Java or an exotic programming language, every single programmer you hire will have to get acquainted with its architecture – which is hence the major factor in its maintainability. Comparatively, the chosen language is barely more than a neglibility, assuming it has a good impedance match with the type of application being written.

In thinking about this issue, I am in fact tempted to recommend that you hire programmers who are unfamiliar with the language your system is written in – because if they still struggle with the basics of a new language after a month, you might want to reconsider their future with your company. But that may be too bold a claim. Even if, in lesser form, it has been made before.

The bottom line is that you need people capable of producing a clean, flexible and only-as-complex-as-necessary architecture for the problem they were tasked with solving. And you won’t get that from an army of code monkeys, even if you hire 1,000,000 of them.