I’m always amused when I hear “our system has one million lines of code” bandied about as a point of pride. All that says to me is that most likely you’ve inherited a big ball of mud because when a single system gets that big, well, chances are it’s a Byzantine nightmare.
Starting from green fields, and with new approaches, I’d incline toward keeping your KLOCs low. That is, it’s great to see the first few thousand lines of tested code come on board quickly, but when a system tips 5-10,000? To me that’s a good time to start looking for ways to partition into separate modules, assemblies, packages whatnot. Mind you, I’m not saying that lines of code shouldn’t be the signal, pain in finding stuff and in maintaining should drive your decision and I think that coincides with an increase in lines of code.
Martin Fowler makes a couple nice points about the relative meaningless of KLOCs as a measure of productivity:
- A high KLOC count says nothing about the quality of the design.
- A high KLOC count says nothing about business value delivered.
So are fewer lines of code better?
One of the many appealing things about Ruby culture is that the LOC measure is a sort of golf score: lower is better. It’s a bragging right for the Rubyist that they can express things in not only a more readable form but in a smaller space.
Granted an important consideration for the Rails developer is that they’ve got a framework that’s amplifying their efforts and keeping their application code brief. As of this post Rails has just south of 100,000 lines of code a good chunk of which are tests.
Sidebar: Now let’s take a look at something from the .NET world. Let’s take NHibernate. You know it, you use it, you love it, right? Well there’s over 400,000 Lines of Code! Still interested in writing your own, full-featured ORM? So with rails you get an ORM and the View/Controller framework (and a bunch of other stuff) for 1/4 the price. Wow. To be fair language choice probably has a lot to do with total lines of code and comparing NHibernate with ActiveRecord is really an apple-orange situation.
What should be important to all of us, as application developers, is choosing the right stuff from the community or vendors (if you have to) that can cut down on the code we have to write to get a job done. When your codebase gets unwieldy evolve your design by looking for pieces you can replace with community or by introducing partitions in the form of subsystems, modules, packages, etc.