Steve Yegge (one of my favourite bloggers) recently posted about the maintenance problems exhibited by a large Java code base. I agree that software bloat is one of the biggest problems in our industry right now.
His proposed solution is to re-implement the 500,000 lines of Java code into 150,000 lines of a more concise language such as Ruby or JavaScript (ES4). This approach seems misguided to me because software complexity is not directly proportional to number of lines of code. The fact that 5 lines of Java can sometimes be compressed into 1 line of Ruby does not make the logic less complex or easier to maintain if they are essentially doing the same thing. In fact, I would argue that often 1 line of clever Ruby is actually less maintainable that 5 lines of Java because it requires a deeper understanding of what’s going on underneath the covers.
A good case study is Perl where developers seem to be a mind set of “how clever can I be” and write one liners that become indecipherable even by the author within days. You might be able to get away with this if you’re a gun developer working on your own but not if you’re working in an average team of average developers. I think Ruby has actually struck a nice balance between readability and conciseness and this is one of the reasons why its popularity has surged. Still, the thought of a 150,000 line Ruby code base scares me and would keep me up at night if it was left in the hands of average developers.
A code base with 1000 Java classes is just a complex as a code base with 1000 equivalent Ruby classes even if the number of lines per class is less. Reducing complexity and therefore increasing maintainability is all about applying good software engineering principles and frequent doses of my favourite refactoring — Delete.
December 23rd, 2007 at 2:42 am
May I humbly suggest you to think in terms of DSL’s instead on “delete” refactoring? You can make DSL easily with Ruby, see http://blog.jayfields.com/search/label/DSL
December 23rd, 2007 at 3:21 am
What evidence do you have for your assertion that a code base with 1000 Java classes is just as complex as a code base with 1000 Ruby classes but with fewer lines of code? What’s an “equivalent” class? If you’re writing 3-4 times fewer lines of code, won’t you need fewer Ruby classes (in my experience, you will)?
In my mind, Yegge is essentially asserting two things. One, that more lines of code–in an absolute sense–always causes more maintenance problems. You seem to disagree with him there; you claim that class count causes complexity, not line count. Two, that languages–like Java–without any code compression capabilities will always suffer in that regard; without closures, you cannot compress idioms, like file IO, down to their essence. Is that right?
December 23rd, 2007 at 2:41 pm
By equivalent I mean that they represent the same concept. For example, a financial application will have the concepts of Account, Transaction, Money, etc. If I follow good design principles like single responsibility per class and simplicity, there should be approximately the same number of classes representing these concepts regardless of the language used. So I don’t think I would have less Ruby classes than Java but I probably would have fewer LoC per class.
As to Yegge’s first point, I agree that more code is always a maintenance problem when comparing code bases written in the same language. My point is that LoC and complexity/maintainability are not linearly proportional when comparing across programming languages. For the same problem, a 150,000 line solution in one language is not necessarily 3 times (or 2 times, or at all) less complex than a 500,000 solution in a different language.
On his second point, maybe we have a different definition of complexity? To me a piece of code that opens a file, processes lines, handles errors and then closes the file implemented in Java with a loop and a try catch block is just a complex as the Ruby solution using closures because you still have to understand the same set to concepts. I think of complexity as the number of concepts and interaction between those concepts, not how many lines of code it takes to express them. Besides, if I really wanted to I could achieve code compression in the Java version. I guess the difference is that I would have to do it myself instead of leveraging a core language feature like closures.
December 24th, 2007 at 11:54 am
I’m not sure you do have to understand the same set of concepts. The Ruby idiom (of the form File.open()) abstracts over that stuff and gives you an 80% solution: we’re going to assume the file is there, and if it isn’t we’re going to die, and if it is we’re going to give it to you line by line. In contrast, Java forces you to make those choices each and every time you want to engage in IO, even if your answers don’t change. In languages that offer closures, rather than being a one-off, this linguistic feature has a ripple effect across your entire code base; suddenly you can abstract any idiom of the form “do this one repetitive thing, then some unique thing, then another repetitive thing” into a much cleaner representation. There’s a tremendous amount of unavoidable boilerplate code you have to write in Java simply to transform a list of one thing into a list of another that simply isn’t necessary in Ruby or Java for this very reason.
Even better, you now have a way of storing these choices in code. You don’t need to have a rule that tells programmers to always handle a certain error in a certain way; you can offer them a method that accepts a block, and it takes care of it. You’ve just made their lives simpler.
Going back to the first point, no codebase of a thousand classes is perfectly factored or a hundred percent domain-based. Suddenly you don’t need an IMoney interface or a CurrencyAdapter or a BankTransactionFactory, or the added cognitive overhead they impose.
Even if none of this were the case, it takes longer and requires more thought to visually parse through nine lines of code than it does three.