Lines Of Code - Dispelling The Myths
You see stuff related to Lines Of Code (LOC) everywhere on programming blogs. People discussing it as a metric of project size, or of programmer productivity, often drawing conclusions in absolutist tones such as “fewer lines of code means less bugs”. I’m writing today to dispute the idea that anything related to LOC is absolute. And I’m going to do it one myth at a time.
LOC As A Metric of Accomplishment or Project Size
This one is old, and most experienced programmers now officially reject it outright. But still, I feel it worth repeating: The number of LOC you write in a single day is worthless as a metric of what you accomplished that day. After all- If someone wrote a 1000 line class in a single day, and you wrote the same class in 500 lines (and maybe tossed in a little extra functionality while you were at it), who was more productive?
As a metric of project size, it makes a little more sense, but just barely- The Wikipedia article on LOC mentions that “Many useful comparisons involve only the order of magnitude of lines of code in a project.” That at least makes a little sense. One can reasonably assume that the same set of programmers, using the same language, will be able to accomplish more with 10000 lines of code than with 1000.
Ambiguity: Too Many Ways To Count
The next issue is this: How do you COUNT lines of code? That same Wikipedia article linked above has an interesting example:
for (i=0; i < 100; ++i) printf("hello"); /* How many lines of code is this? */
How many lines is that? One for the line? Two for logical seperation of forloop and print statement? What if you wrap the line in curly braces, one on each line, and move the comment to it’s own line, so it looks more like
for (i=0; i < 100; ++i) { /* How many lines of code is this? */ printf("hello"); }
Did you see that? I just took one line of code, and turned it into 5! Things get so much more confusing than stylistic issues like this, though. What about libraries? What about frameworks? Jeff Atwood wrote a post a couple of months ago wherein he mentioned that the original version of Basecamp had been written in only 600 lines of code. Given that Basecamp was written using Ruby on Rails, which handles all sorts of crazy things for you, I think the more honest metric would have to be the 600 lines of basecamp, plus however large the RoR framework is, plus the code RoR generated for them when they started the project. Money says it’s more than 600 lines.
I’ll give you another example. Currently, the amount of code I’ve written for Migratr is 5000 lines and change. However, Migratr uses FlickrNet, a popular .NET library for interacting with the Flickr API. FlickrNet, if you download the source, is more than 12,371 lines of code (according to the unix util “wc”). I’ve also incorporated a few other libraries, all of which are linked in Migratr’s “about” page. Why? Because I didn’t want to write those 12,000 lines. Someone already had, and they did a fantastic job of it, and I didn’t see any point in re-inventing the wheel. So the total code involved in Migratr is, at this point, more than 17,000 lines. I’ve written 5,000 of them, and I’m the sole developer of Migratr. But I wouldn’t dream of saying “I built this application that interacts with a whole slew of online photo services and migrates all your photos and does all this neat stuff, and it was only 5,000 lines!” No. MY contribution was 5000 lines, but Migratr depends on a lot more than that.
The point being, where do you draw the line? Is Migratr a 5000+ LOC project? or 17,000+? Do you only count LOC if you have access to the source of the library you’re using? Do you only count the code written for your specific project? Could I export Migratr’s backend as a library and let someone write
public void migrate(String filepath) { ImportFromSource(Services.Flickr, filepath); exportToDestination(Services.SmugMug, filepath); }
Did you see that? My whole project was just replaced! Some twerp in a garage somewhere just re-wrote Migratr in 5 lines of code! It doesn’t matter that it depended on my 5,000 line library, which depends on (among others) 12,000 lines of the Flickrnet library. You only saw 5 lines. It was only 5 lines.
But clearly, since 5,000 is more than 5, I can at least say that I was more productive.
The relationship between line count and bug count only goes so far
The idea that “Less lines of code mean less bugs” is some sort of universal absolute is the biggest of all the LOC myths. In a desperate effort to nullify your “oh snap, time for a flamewar” reflex, I’m going to add a couple of disclaimers before I get into this. Any reference I make to a programming language is not an attack on that programming language, just an attack on the abuse of that language. Also, I realize that reducing the amount of code required for a specific task can help reduce the bug count, but only so far. I’m saying there’s a limit to this. Here’s the line I want to draw for you.
Reducing the code involved in a task will only help reduce the bug count IF THE PROCESS MAKES THE CODE MORE READABLE. Past that, you’re probably creating lines of code that do more than one thing per line, and thus increasing the number of bugs possible per line of code.
Perl programmers are especially frightening in this regard. I really love PERL and use it instead of shell scripting languages such as BASH whenever possible, but there’s something in the PERL culture that demands it’s programmers to try and do something in the fewest number of characters possible. There’s even a name for this as a sport- It’s referred to as “Perl Golf”.
Really quick, can you tell me what this is?
-pl s!.!y$IVCXL426(-:$XLMCDIVX$dfor$$_.=5x$&*8%29628;$$$_=$_!egfor-4e3..y/iul-}/-$+ /%s''$';*_=eval
I’ll give you a hint- It’s not a cat walking across my keyboard. If that was your first guess, though, we’re at least on the same page. This was the winning entry in a game of Perl Golf: The problem was to write a Roman Numeral Calculator in the fewest characters possible. Submissions can be found here. Now, this is an amazing piece of code. The person who wrote it is clearly very skilled. The fact that Perl makes code like that possible is pretty impressive. The problem here is that people write code like this outside of PERL golf, and think to themselves, “it’s only one line, so it must have fewer bugs than a 50 line solution”. Really? Because if I had to debug one, I’d have definitely gone with the 50 line solution. And don’t tell me that that one line of code worked on the first, second, or 5th try. The 50+ line solutions might have, but not that catwalk.
Writing unmaintanable code does not reduce the bug count for a project. A friend of mine coined a term for code like that- “Write-Only Code”- a takeoff on the permissions you can set with chmod. Think about it: Readable, writeable, and executable. Shouldn’t code be all three?
Another quick example:
(0/:l)(_+_)
The first time I saw this snippet, I thought someone was, via emoticons, trying to re-enact the facial expression one wore when seeing “Goatse” for the first time. It’s not actually a story told by emoticon. It’s a piece of scala code that sums the elements in a list. And I just don’t see it as having been easier to write than a forloop. It’s definitely not as maintainable. This piece of code, actually, prompted a conversation with a friend about holding a “code or emoticon” contest, but we really couldn’t come up with any serious contenders to this one. Maybe some Perl Golfers could throw their hat in the ring?
I want to state too, that for this section, I’m well aware that I didn’t provide buggy one-liners. I provided working one-liners. This is because I was trying to emphasize, the point isn’t if it works or not- The point is if you can tell by looking at it what it should do. If you can’t, it’s unmaintainable. If it’s unmaintanable, then even if it works the first time, it’ll produce a slew of bugs as soon as anyone tries to modify it.
So, in essence- Stop paying attention to Lines of Code. They’re impossible to count in any useful way. They’re a crappy metric of project size or personal accomplishment. And they don’t control how many bugs your code has. You do.
-Alex
0.9.91 - Minor Bugfix for Zenfolio
Quick release to fix a small bug. Migratr couldn’t download photos in a private data set from Zenfolio, even though you were the owner. It was something I wasn’t implementing correctly in the API.
Thankfully, an astute forum member brought it to my attention. Special thanks to MSPhotog!
To download the fix, just click the ever-popular “big giant download button”.
Downloaded a total of 14827 times
The Software Approach to Flyswatters.
Adam: in other words it’s a sledgehammer for swatting flies. A sledgehammer with lots of knobs and dials on it that all must be set for its user’s height and weight, and the age in hours and zodiac sign of the fly you’re swatting.
Adam: This seems to be common in microsoft tools and APIs.
Alex: With random pitfalls. “I’m sorry, but you’re exactly 2^8 - 1 pounds and the fly is a gemini. Please update your sledgehammer for compatibility.”
Adam: hahah
Adam: yeah
Adam: or worse, “Yeah that’s a known issue, but we’ll have it fixed for the next version and you can buy that.”
Alex: Months later Linus Torvalds posts an essay on his new project, a normal-sized hammer for swatting flies, which can easily be modified for swatting mosquitos, provided the mosquitos astrological sign has a compatible license, therefor sledgehammers are evil.
Adam: There’s also question of whether or not the normal-sized hammer infringes on one or more hammer-related patents, but nobody will talk about what those patents are. Flames fly, large businesses invest in the continued future of the normal-sized hammer. Meanwhile users and developers alike still don’t have what they need: a flyswatter.
Alex: lol
Adam: Bloggers claim the normal-sized hammer isn’t ready for the workshop.
Alex: Usability questions arise. The normal-hammer camp will cry that theirs is a “More lightweight solution”, and while normal users don’t have nearly the level of accuracy required to use it effectively without smashing their thumbs, evangelists will claim that “Well, they just need to bite the bullet and learn to swing a hammer effectively.” The sledgehammer camp will point out the greater surface area and imply that if you can’t swing it, you need to work out more until you have the necessary muscle mass to swing the sledgehammer effectively. At which point, as an added feature, you’ll be able to smash everything around you into oblivion.
Alex: They will also point out that flyswatters do not have this property.
Alex: And, through clever marketing, imply that all walls need smashing, and thus flyswatters simply don’t fulfill the user’s needs.
Adam: Plus, as everyone currently uses sledgehammers, they become frustrated when the normal-sized hammer doesn’t work quite the same way, yet they constantly complain about their sledgehammers holding their hands too much.
Adam: Sledgehammer “power users” are known for circumventing the thumb-smashing protections because they think it makes them work more effectively.
Adam: They complain that the thumb-protections are included at all because they don’t use them and things like that are why the sledgehammer is so bloated.
Alex: Apple will release homes outfitted with mosquito nets. Elitists will smugly claim that the problem has been solved. Both hammer camps will roll their eyes at the idea that buying a new house is the solution to a fly problem
Adam: The mosquito-net houses aren’t compatible with the new sledgehammer addon. Mosquito-net house owners don’t care because they don’t need it, but hammer aficionados continue to cite this incompatibility as a reason why mosquito-net houses are, and always have been toys.
Alex: Eventually a small independant developer releases a flyswatter. Panic-stricken, the sledgehammer company purchases the flyswatter IP from the developer, and adds the flyswatter mesh to the handle of the hammer. Evangelists rejoice, competitors once again roll their eyes. Users wonder what the hell just happened.
Adam: Meanwhile some guy in his basement publishes blueprints of how to build a normal-hammer modification making it compatible with the new sledgehammer accessory. Normal-hammer users rejoice and claim this as a strength of their platform. Sledgehammer users scoff and say, “you have to build it yourself?? Not ready for workshop!”
Adam: Mosquito-net house owners have been in their houses watching fly-free movies this whole time, but nobody listens to those elitist pricks anyway.
Alex: Normal hammer users ask the honest question of how the hammer head flying lose from the handle when swung can possibly be classified as “ready for workshop” in the first place. They are immediately dismissed as trolls
Adam: Because after all, if the hammer head flies loose from the handle you’re clearly an idiot for not knowing that you had to hold the third switch from the bottom with your pinky finger as you swing in order to make the hammer head stay in place.
Adam: Because come on, you’d have to be a total hammer n00b to not know that.
Alex: The normal-hammer camp announces that their hammer has no buttons. The sledgehammer camp cites this as a missing feature
Alex: After all, how do you keep the head on the handle without that button?
Adam: The button by the way is a third-party addon. Usually there’s a trial button shipped with new sledgehammers, but you have to pay a yearly subscription to keep it working right. The sledgehammer manufacturer would include the button to begin with if it weren’t for the fact that the third party would sue for abusing monopoly power.
Adam: Many sledgehammer users in practice don’t know this and continue to use their trial buttons past the expiration date, blaming the sledgehammer manufacturer when the hammer head flies off.
Adam: Sledgehammer power users dismiss them as idiots and say it’s not the sledgehammer’s fault.
Alex: The modding community releases an intriguing solution involving duct tape and industrial strength rubber bands. This leads to the sledgehammer company suing rubber band manufacturers
Alex: The duct tape community, on the other hand, is purchased. A layer of duct tape now covers the flyswatter mesh in the sledgehammer handle, or will once you upgrade to the next version.
Alex: The mosquito net manufacturer, to everyone’s surprise, releases a flyswatter. Unfortunately, you can only use it in a mosquito-net home.
Adam: Someone comes out of the woodwork claiming that he has a patent on wooden handles. The sledgehammer has long used wooden handles and faces a problem. The normal-hammer camp releases instructions the next day about how to replace your wooden handle with a piece of steel pipe from home depot, and all new normal-hammers will use this new method. Normal-hammer users complain that the slick metal gets sweaty and is hard to hold, but these claims are dismissed with, “if you want a hand grip, make it yourself.”
Alex: Everyone, the normal-camp-hammer users decide, either has the proper machining in their garage to make a decent rubber grip, or shouldn’t be using normal-hammers in the first place.
Alex: This is in direct conflict with “Everyone needs to bite the bullet and switch over to normal hammers because they’re free.”
Adam: Somehow normal-hammer users don’t see these two things as being mutually exclusive though and don’t see what the big deal is.
Alex: Cost-analysis by several third parties takes place, as a result of curiosity as to if, at this point, normal hammers are still a cost effective solution.
Alex: Everyone looks to the flyswatters that can only be used in mosquito-netted homes. Crumbling under public pressure, the license is reconsidered. You can now use the flyswatter in non-mosquito-net homes, but only three designated homes per flyswatter.
Adam: Cost analysis is later made even more muddled by the fact that the sledgehammer manufacturer has been selling “upgrade insurance”, promising ‘free’ upgrades to your sledgehammer for the life of the policy. Sledgehammer manufacturer then proceeds to release no new sledgehammer revisions for the life of a policy cycle.
Alex: Mosquito-net-home users rejoice and evangelize this as the perfect solution, because having no social lives (as a tragic side effect of being elitist wankers), they’ve never been to more than three homes.
Alex: Hammer optimization continues.
Migratr 0.9.9 - Gallery2 Supported!
Hello there friends!
A few new things in this version:
1. Support has been added for Gallery 2. This has been tested on 2.2.3, but should work with all 2.x versions. As a sidenote, this requires that you have the “Remote” module installed in your Gallery 2 installation (since Migratr uses the same API as the Gallery Remote client). If you get authentication errors, try downloading the Gallery Remote, and testing with that to make sure your Gallery installation is set up to work with desktop clients.
2. Updated to the newest version of the FlickrNet library. This means some bugfixes, performance enhancements, and most importantly, the ability to disable the cache! Resuming a migration from Flickr & 23HQ should run a little smoother now. This also means that we have all been liberated from having that “Flush Cache” button sitting there in the import screen, generally looking smug and not making any sense. Since there is no longer a cache to flush, it has been removed.
3. I changed the “You tried to export to the same service you imported from” message from an error message to a confirmation (Yes/No) dialog box. Being that Migratr was designed with the intention of moving photos between services, it had honestly never occurred to me that someone would want to import from one service, and then export to that same service. To that end, I wanted to make sure that nobody accidentally went on “autopilot” and accidentally created doubles of every photo in an account. However, several of you in the forums have mentioned using it to move between accounts on the same service. To that end, Migratr will now simply pop up a dialog as a gentle reminder to make sure that you’re selecting the same service intentionally, and then let you proceed as you wish.
And now, for a the traditional “Big Giant Download Button”
Downloaded a total of 14827 times
Enjoy the release!
-Alex
Takin’ a crack at ImageStation
Hello again, loyal fans!
A fellow developer gave me some pointers on how I might be able to accomplish migration of data from one of the latest additions to the Photo-Sharing Deadpool, ImageStation. I consider closing sites to be of the highest priority, however, since they’re not allowing new accounts (And while this might indicate why they’re closing, I never heard of them before they actually announced the service was shutting down), I have no way to code against their website.
So I’m asking you guys for a favor. If you have an active ImageStation account with photos on it (preferably with at least SOME metadata… tags, album, description, etc), and are willing to let me use your account as a guinnea pig, I would GREATLY appreciate if you emailed me the login/pass information for your account. My personal email address is callingshotgun@gmail.com. Of course, I will treat this information with the utmost confidence.
What will you be getting out of this, you might ask? Fair question. After all, I’m asking you for LOGIN INFORMATION. That’s kind of ridiculous, and it’s not something I normally like to do. But here’s the deal… You’ll be helping me help you (and countless other stranded users) move your photos to wherever you want- Not roach-motelling them into Shutterfly, which offers no API, and not having to pay them money to burn a DVD and mail it to you. Your choices as of the current version of Migratr will include moving to SmugMug, Phanfare, Flickr, PicasaWeb, Zenfolio, and 23HQ. Or heck, letting migratr just download all the photos and all your metadata to your hard drive, and letting you do whatever you want from there.
So, there it is. I’m asking you. I’m begging you.
Help me set your photos free.
-Alex
