Ola Bini is a Swedish developer working for ThoughtWorks. His daily job includes working on JRuby, starting up a Swedish ThoughtWorks office and mucking around with Java and Ruby. In his spare time he spends most time on his language Ioke, working on one of several other open source projects or reading science fiction. Ola has presented at numerous conferences, such as JavaOne, Javapolis, JAOO, RailsConf, TheServerSide Java Symposium and more. He is the author of APress book Practical JRuby on Rails Ola is a DZone MVB and is not an employee of DZone and has posted 45 posts at DZone. You can read more from them at their website. View Full User Profile

The Maintenance Myth

10.15.2008
| 5750 views |
  • submit to reddit

Being a language geek, I tend to get into lots of discussions about the differences between languages, what’s good and what’s bad. And being a Ruby guy that hangs out in Java crowds, I end up having the static-vs-dynamic conversation way too often. And it’s interesting, the number one question everyone from the static “camp” has, the one thing that worries them the most is maintenance.

The question is basically - not having types at compile time, won’t it be really hard to maintain your system when it grows to a few millions of lines of code? Don’t you need the static type hierarchy to organize your project? Don’t you need an IDE that can use the static information to give you intellisense? All of these questions, and many more, boil down to the same basic idea: that dynamic languages aren’t as maintainable as static ones.

And what’s even more curious, in these kind of discussions I find people in the dynamic camp generally agrees, that yes, maintenance can be a problem. I’ve found myself doing the same thing, because it’s such a well established fact that maintenance suffers in a dynamic system. Or wait… Is it that well established?

I’ve asked some people about this lately, and most of the answers invariably beings “but obviously it’s harder to maintain a dynamic system”. Things that are “obvious” like that really worries me.

Now, Java systems can be hard to maintain. We know that. There are lots of documentation and talk about hard to maintain systems with millions of lines of code. But I really can’t come up with anything I’ve read about people in dynamic languages talking about what a maintenance nightmare their projects are. I know several people who are responsible for quite large code bases written in Ruby and Python (very large code bases is 50K-100K lines of code in these languages). And they are not talking about how they wish they had static typing. Not at all. Of course, this is totally anecdotal, and maybe these guys are above your average developer. But in that case, shouldn’t we hear these rumblings from all those Java developers who switched to Ruby? I haven’t heard anyone say they wish they had static typing in Ruby. And not all of those who migrated could have been better than average.

So where does that leave us? With a big “I don’t know”. Thinking about this issue some more, I came up with two examples where I’ve heard about someone leaving a dynamic language because of issues like this. And I’m not sure how closely tied they are to maintenance problem, not really, but these were the only ones I came up with. Reddit and CDBaby. Reddit switched from Lisp to Python, and CDBaby switched from Ruby to PHP. Funny, they switched away from a dynamic language - but not to a static language. Instead they switched to another dynamic language, so the problem was probably not something static typing would have solved (at least not in the eyes of the teams responsible for these switches, at least).

I’m not saying I know this is true, because I have no real, hard evidence one way or another, but to me the “obvious” claim that dynamic languages are harder to maintain smells a bit fishy. I’m going to work under the hypothesis that this claim is mostly myth. And if it’s not a myth, it’s still a red herring - it takes the focus away from more important concerns with regard to the difference between static and dynamic typing.

I did a quick round of shouted questions to some of my colleagues at ThoughtWorks I know and respect - and who was online on IM at the mime. The general message was that it depends on the team. The people writing the code, and how they are writing it, is much more important than static or dynamic typing. If you make the assumption that the team is good and the code is treated well from day 0, static or dynamic typing doesn’t make difference for maintainability.

Rebecca Parsons, our CTO said this:

I think right now the tooling is still better in static languages. I think the code is shorter generally speaking in dynamic languages which makes it easier to support.

I think maintenance is improved when the cognitive distance between the language and the app is reduced, which is often easier in dynamic languages.

In the end, I’m just worried that everyone seems to take the maintainability story as fact. Has there been any research done in this area? Smalltalk and Lisp has been around forever, there should be something out there about how good or bad maintenance of these systems have been. There are three reasons I haven’t seen it:

  • It’s out there, but I haven’t looked in the right places.
  • There are maintenance problems in all of these languages, but people using dynamic languages aren’t as keen on whining as Java developers.
  • There are no real maintenance problems with dynamic languages.

There is a distinct possibility I’ll get lots of anecdotal evidence in the comments on this post. I would definitely prefer fact, if there is any to get.

From http://olabini.com/blog

Published at DZone with permission of Ola Bini, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Cristian Vasile... replied on Wed, 2008/10/15 - 5:18am

"But in that case, shouldn’t we hear these rumblings from all those Java developers who switched to Ruby?"

From all 3 of them? :)

Joking aside, my point is that there are a LOT more java projets than JRuby projects out there. Old ones too (5+ years).

Ruby is pretty young and only recently started attracting developers. I'm sure we'll hear of maintainance problems with projects written completely in dynamic languages when/if there will be enough such projects.

Some thoughts on why you might have more problems maintaining a system written in a dynamic language:

  • tool support: no dynamic language will ever be properly supported in an IDE. Forget most of automatic refactorings. IDEs will have problems with even the basic ones like rename (including usages). And yes, you have the same problem with reflection in java, that's why I avoid it if I can.
  • many compile-time errors are moved at runtime. This is very bad in my opinion. The counter I often hear is "write unit tests". But that's a bad answer. I write unit tests anyway but I don't want to write additional unit tests for stuff which compiler can check automatically.
  • statically typed code is more self-explaining that dynamic code. Yes it doesn't replace comments, but it surely helps.
  • I'm sure there are others I didn't think of.

I have to say I like static languages very much, java in particular. The way I see it, dynamic languages are usefull for PARTS of an application, where it makes sense (easy custom DSLs, business rules, scripting etc.). I wouldn't write my whole application in a dynamic language.

Cristian Vasile Mocanu

Yo Tu replied on Wed, 2008/10/15 - 6:05am

Maybe it's not that hard for someone that has grown with the system and has seen it evolve. But for the new guy, it's easier to understand static code. You have more visual feedback about it.

I've never worked with ruby, but some time ago i needed to change a menu written in javascript. When i told my boss what i needed (he wrote that code), i received a sound "better don't touch that". Too much effort in understanding the code for the benefit of the change.

Harald Krake replied on Wed, 2008/10/15 - 7:31am

@cvmocanu: couldn't agree more.

Just want to add another aspect:

As a long-time Java developer I also did some smaller Rails web-projects (Ruby and JRuby) and I must admit that it is a highly productive environment! But ... because of the lack of compile-time checking, refactoring will become a big problem for dynamic "legacy"-applications in the future. All applications become legacy some day and all applications need permanent refactoring -- except those not in use anymore ;)

Dynamic languages are great for applications with a relatively short half-time, mostly web-related stuff, which is notoriously changing from one day to another (-> scripting, dsl, as already mentioned). For hard-core enterprise applications I would always prefer static languages like Java.

But maybe with better tools, I'll probably change my mind some day? ;)

 

Ivan Lazarte replied on Wed, 2008/10/15 - 10:32am

In my area (DC) I hear a lot more about Java guys being brought in to rewrite the Ruby apps.  I also hear about Java guys who stay away from Ruby specifically because of things like IDE support and the fact that it's Yet Another Scripting Language.  People seem to equate it to Perl in in its heyday.  

So this implies local Ruby apps don't reach maintainability issues because they are

1. completely rewritten

2. not the first choice for the average app

 Ultimatley it's kind of like saying there are no viruses on Macs.  Who would bother writing a virus for 3% of the population of computing?  Similarly, how can we get stories of legacy apps for Ruby when there appears to be a small number of these apps to begin with? 

 FWIW I'm huge on server-side Javascript.

 

Brendon replied on Wed, 2008/10/15 - 2:28pm

I think there may be a fourth reason why you haven't seen any compelling evidence-based argument "debunking the maintainability myth".  Perhaps there are no applications written in dynamic languages of the same scale as in Java?  That's not a fact, just a hypothesis.

I've worked on a system that over two years reached 120k lines of Java code written by 4 developers.  A project of this size could easily have been written in a dynamic language (at a quarter of the size), especially considering most of it was written from scratch a small team.  But after the project's initial success, another team was merged into our team and our code had to talk to their code of 281k lines of code.  One year later, we merged with yet another team and took on another 42k lines.

In the end we had a project of 433k lines of code, using 180 JAR files (I kid you not).   It's not as bad as it sounds; the project is fairly modular and no-one on the team has to know the entire code-base to be effective.  But you are still dealing with fairly large percentages of code which you didn't write, which doesn't have documentation and where the author has left the company.  In this case, CTRL-Click is your best friend.

I'm pretty sure that this particular project is simply unfathomable without the fail-fast, self-documenting aspects of the type system.  At this level, a dynamic language's only hope is a gargantuan army of unit tests.  But I'm also pretty sure that most projects won't (and shouldn't) get to be this big.

As an aside, I'm not convinced that the productivity boosting claims of Ruby, Python, etal have all that much to do with their lack of a type-system.  It's just that creating a typed language is so much more difficult.  But that's another argument

Brendon.

replied on Wed, 2008/10/15 - 11:30pm

In the case of Ruby, IDE options are getting better all the time - Netbeans coming to the forefront of my mind. Even with Ruby's dynamic nature, Netbeans relies on heiuristics to determine variable classes based on usage, context, etc, and present intelligent methods to extend them (even derived methods). Also, Netbeans offers as-you-type compilation checking, as well as "Ctl + Click" linking, and inline-documentation. Within a few years, as the algorithms improve, the dynamic vs. static debate might be just personal preference.

Dmitry Leskov replied on Thu, 2008/10/16 - 2:17am

I think that enforcement of good coding standards, whether through peer reviews or tools can replace static typing to a considerable extent. This overhead can save you lots of resources in the long run as the project grows and matures, new people join it, etc.

Harald Krake replied on Thu, 2008/10/16 - 2:39am in response to: Brendon

[quote=Brendon]

But you are still dealing with fairly large percentages of code which you didn't write, which doesn't have documentation and where the author has left the company.  In this case, CTRL-Click is your best friend.

[/quote]

Even for code you wrote yourself Ctrl-click is your best friend ;)

[quote=thehoagie]

Within a few years, as the algorithms improve, the dynamic vs. static debate might be just personal preference.

[/quote]

Ctrl-Click on dynamically generated methods such as find_by_name ?

I'm curious how this is going to be implemented. Such "intelligence" doesn't even work today for stoneage Java reflection, nor does it work for bytecode instrumentation. When programming with Rails, I always get the feeling of a blind flight. But may be, I'm just too old for such kind of magic...

I'm also in doubt about the concept of duck typing. The notion of what comprises a duck might change during the application's life cycle (changed, new, obsolete requirements). How will an IDE support this kind of refactoring?

But again... time will tell.

Harald

Ignacio Coloma replied on Thu, 2008/10/16 - 2:42am

"I think maintenance is improved when the cognitive distance between the language and the app is reduced, which is often easier in dynamic languages."

This is a theoretical point that contradicts Brooks' Mythical Man-Month: dynamic languages attack the 'accident' of software development, not the 'essence'. I still have to resolve the business problem, and that's what takes most of the time (meetings with the customer, testing, debugging, testing again, understanding the business model, rewrite and test again). I write new code only 25% of my better days.

To my taste, Rails penalize the debugging process and improves the writing of new code, which just doesn't suit my use case.

Dave Newton replied on Thu, 2008/10/16 - 7:10am in response to: Yo Tu

some time ago i needed to change a menu written in javascript. When i told my boss what i needed (he wrote that code), i received a sound "better don't touch that".

 I don't understand how some bad code your boss wrote is an argument against dynamic languages.

 

Yo Tu replied on Thu, 2008/10/16 - 10:09am in response to: Dave Newton

No one said it was a bad code ;)

The bottom line is that the effort involved in understanding the code is higher in dynamic vs in static. The quote would have had more sense if you didn't strip the following sentence...

"Too much effort in understanding the code for the benefit of the change."

Dave Newton replied on Thu, 2008/10/16 - 11:01am in response to: Yo Tu

The bottom line is that the effort involved in understanding the code is higher in dynamic vs in static

You're stating a conclusion to the discussion in question as fact. This defeats the purpose of the discussion.

You're not offering any argument to back up your belief, just an anecdote about some brittle (which, IMO, means bad) JavaScript. That's fine, I just don't see that it contributes to a deeper understanding.

Ignacio Coloma replied on Thu, 2008/10/16 - 12:02pm in response to: Dave Newton

You're not offering any argument to back up your belief, just an anecdote about some brittle (which, IMO, means bad) JavaScript. That's fine, I just don't see that it contributes to a deeper understanding.

I think the point has been explained by others in this thread already, but I will mention a real-world example that happened to me last week.

I wanted to use Ant's filterchain from Gradle. That is done through AntBuilder, which is a Groovy class.  Now, if you look in their docs, including javadocs, there is no example about how to do such a thing, which is fine (it happens a lot in my world). I went to the code, and found it almost empty. No hint about where I should look to find the magic that transforms ant tasks into groovy.

Would that have happened if I was looking through a java class? Ant is the easiest framework I have to deal with. If I was inspecting something serious (say, a transaction that is going sour in some Hibernate guts) I would be much more comfortable if it was java. I like ctrl+clicking to find things, and I love seeing what the method is doing, written in code.

I do not have any doubt that developing AntBuilder was an awesome experience, but using it was hellish. I don't want magic in my code if it harms readability.

Yo Tu replied on Thu, 2008/10/16 - 1:42pm in response to: Dave Newton

[quote=newton_dave]

You're stating a conclusion to the discussion in question as fact. This defeats the purpose of the discussion.

You're not offering any argument to back up your belief, just an anecdote about some brittle (which, IMO, means bad) JavaScript. That's fine, I just don't see that it contributes to a deeper understanding.

[/quote]

That's fair. Let's be concise then.

But first, please remember that i don't have ruby experience, so i'm taking javascript as a dynamic language example. Also, i'm sure IDEs and tools can be better for ruby than for js, and that may invalidate my arguments.

Lately, i've been working in a small local firm, doing java consulting services in nearly everywhere my boss could put me in. I've been thrown in the middle of already-in-production projects a lot of times and i've gone through the learning curve the same times. When you sit down the first day and start reading code, your mind has to create a lot of small pieces and start connecting them to make a bigger picture of the system. In this process, your brain uses every hint it can gather, be it variable names or type info.

Of course, code quality matters. When someone names a variable "a", there's not much to be done. But one thing that helps is that "a" may be a string or an int, or whatever, but it provides a hint in the end. IDEs use the available hints to autocomplete, provide ctrl+click and so on. Dynamic code is harder to grab for this reason, you have less hints to help you understand what was the dev thinking when he wrote that mess.

I can feel it everytime i start again. Taking a peek at a new .js makes me shudder.

Conclusion: for the new guy, the extra hints of a statically typed language help him understand the code better or faster than a dynamic language (at least for the Average Joe).

Dave Newton replied on Thu, 2008/10/16 - 7:59pm in response to: Ignacio Coloma

Seems like a great example of poor documentation. The Hibernate example?You said it precisely correctly: *you* would be more comfortable if it was written in Java--and again, this isn't an indictment of the maintenance of dynamic language code.

You don't want "magic" in your code if it "harms readability"? That's fine--but again, a different issue. 

Dave Newton replied on Thu, 2008/10/16 - 8:00pm in response to: Yo Tu

That's one way of dealing with unfamiliar code; there are others.

Harald Krake replied on Fri, 2008/10/17 - 2:47am

I don't think that dynamically typed languages are harder to read than statically typed. Imho, this is just a matter of carefully chosen names and some extra comments.

The issue is dynamic code! In this respect, dynamic languages like Ruby are fundamentally different from Java. In Java, all code is static. The IDEs can parse it and therefore provide a lot of hints to the developer (used where?, overwritten where?, ...). In Ruby, code is generated at runtime! For example, you can modify classes by "sending" some code to them. Just dive into Rails code and try to understand how active record works. At least as it is now, there is zero support by the IDEs for that. It is like programming Java with vi.

Java Script cannot be compared to Ruby, because very few JS-developers make use of dynamic code. It's mainly used to tweak browsers (sorry for the JS geeks ;)). In Ruby dynamic code is a core feature and -- as a fan of generative programming -- I can say that it is pure fun. However, your code becomes harder to understand for others, because of WYSINWBE (what you see is not what's being executed ;)

 

Yo Tu replied on Fri, 2008/10/17 - 3:36am in response to: Dave Newton

Follow your own rantings and give examples...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.