AurosBlog

You see posts 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.

Editors’ note: The lines below may be wrapped and on more than the lines stated due to our template.

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. cheers Aurobindo

My father worked for the United States Postal Service for thirty years. He received incremental pay raises, a steady paycheck, a pension, rarely worked a day of overtime, and even received an award for never taking a sick day in fifteen years. He was in at 8:30am and home by 5:30pm, and I never heard him complain once about his job. Without asking, you would presume he was happy with his work.

In the last ten years I have held a total of seven “career” positions, and I have been in business for myself. I have been a copywriter, design technologist, Web developer, creative consultant, interface developer and I am currently employed as a software engineer. I have worked anywhere from eight- to twenty-hour days, and my pay grade has varied by as much as $50k. Without asking, you would presume I am never happy with my work.
Contrasting opinions

There are several explanations for the contrast after taking a longer look at our situations. The first of which involves the economic uncertainty that appears to plague my generation. Guaranteed pensions and stock options are a thing of the past, and if the economy in the US (at the time of writing this) tells us anything, no one can even promise you a steady paycheck. The reality is that the marketplace, no matter the market, is simply different now than it was forty years ago. The fact that two of the positions I formerly held were lost due to bankruptcy and downsizing are testimonies to that fact.

The second view is that the generation gap is significant enough to warrant the difference. Our attitudes regarding career accomplishments are vastly at odds because there is almost forty years between us. A sense of entitlement is much more prevalent in the workforce today, and there is no room for growth at a company that will not meet certain demands. So many have received untold wealth with little effort, that it is now becoming an intrinsic ideal among all employees. Without that get-rich-quick potential, is it worth it to invest a lifetime at any corporation?

The third view is that I am simply different than my father. My aspirations, my view on family and friends, what I consider achievement, how I arrive at success — all of these cause me to pursue career interests with a unique perspective. It might be that my happiness is directly related to each of these personality traits, and there is nothing by anyone else’s doing other than my own that will cause me to be happy. Because these beliefs and values shift, it may cause a shift in how I view each employer.
The complexity is daunting

When you begin to understand the complexity of the problem, you realize how difficult it can be for an employer to make the vast majority of employees happy. Being in the business of information technology, I can tell you that there is also a cultural rift between this field and any other, which creates an even more complex (and at times volatile) atmosphere. Employee happiness is the coup de grâce for management and HR, so much so that outlandish attempts are made to find the perfect non-compensatory benefit.

I find it interesting that there are so many possibilities, and I thought it would be helpful to list just a few I have stumbled across in my day. You can get on-site daycare, sales kickers, game rooms, chair massages, dual (or triple) monitors, exercise machines and showers, retail discounts, paid training, free lunches, concierge service, access to on-staff nutritionists, accountants, and computer technicians, after-work socials, holiday parties, shuttle service, and the list continues.

This begs the question, why are all those now necessary to employee happiness? Could it be that each and every one of those is quite possibly smoke and mirrors, hiding the hard truth that most businesses can no longer guarantee what was once permanent, and therefore must replace the permanency with temporal niceties? Stop to think about this for one moment before you dismiss this as one man’s pessimistic outlook. Was my father happy with his job primarily because there was at least a small sense of certainty with respect to the nature of his employment?

My dad could be fairly certain that if he did a good job, came into work on time, was respectful to his peers, and was responsible for his actions, that he would receive everything promised to him on the day of his job interview. That is not to say there was never a mistake made by management, but the likelihood that he would get passed over for his hard work and dedication was less of a concern. The relationship between himself and the post office was symbiotic, and it was understood that the livelihood of both employee and employer were dependent on both doing exactly as promised.
What to do about it

If that is the case, then I want to explore the alternatives, and what I consider to be the prerequisites that all employers should adhere to in order to create an atmosphere conducive to employee happiness. This exercise is not as complicated or scientific as you might think, but these three requirements certainly require some forethought when you are job hunting.
1.) Fair wages for a fair day’s work

The question running through your mind is undoubtedly, how do you decide what is fair? This is not that difficult to determine, and it involves little research. The first point to consider though is that fair does not involve your life situation. Debt, a mortgage, hobbies, private school for the kids — none of these matter when you consider your future salary. The fact is, you have experience, a job history, skills, education, and a mean average cost of living. These will help to determine what is fair.

Start by reviewing open positions that you are qualified for in comparable cities across the country. For instance, eliminate sweeping generalizations about pay grade by avoiding comparisons like Detroit to San Fransisco, or Atlanta to New York. Average the salary ranges for matches on similar job descriptions, as well as your experience, and you will find out quickly what is fair. Then, find employers who will stick by these same standards.

A manager once explained to me why several employees were granted a senior title, when it was obviously unwarranted based upon their performance. He said that they were great negotiators, and because HR matched the salary to the title, the two then became inseparable. Many did not consider that fair, including the manager. He spent a considerable amount of time trying to level the playing field for current and new employees, and was completely honest about it. This is the type of fairness that you will need to seek.
2.) Honesty in all things before and after

Four months before the Internet bubble burst I was employed with an interactive agency building dot com startups. Every day my entire department would come into the office and surf the Internet, chat away the week over coffee, and enjoy free lunches. After a couple months a coworker and I began discussing the economic feasibility of supporting five hundred employees who had no billable hours to a single client. In our frustration we were open about our doubts, and before long management caught wind of our nay saying.

Of course, we were reassured like everyone else at the time, that all was well, and this was merely a bump in the road. The sales pipeline was full, and we would be busy again soon. Not too long after the daily free lunches moved to Friday, and then stopped altogether. At our next quarterly meeting we were each given a copy of the now infamous book Who Moved My Cheese, a patronizing tale about survival in the corporate world written at a third-grade level. The message was clear, but management would not budge. No one was going to lose their job.

I quickly became the town crier, bemoaning our demise, and telling other employees they had better update their resumes. I only received back blank stares. Tired of the whole ordeal our manager walked into our
next department meeting and candidly taped two pieces of paper up on the wall. He drew a smiley face on one, and a sad face on the other. He pointed to the sad face, and said, “You can be one of two people. If this is you, then we don’t want you here.” I typed up my letter of resignation. Two weeks later everyone lost their job. The company declared bankruptcy.

Some businesses still operate under the same dishonest practices. They are unwilling to share financial data, information about why employees are here one day and gone the next, and they lack a vision that truly drives the organization past status quo. The piece of paper taped to the wall is an adequate illustration — it only makes employees sad.
3.) Respect for the common man

The final requirement for employee happiness might be considered altruistic by some, and an unquantifiable goal. Everyone views respect differently, and how can a thousand, or even ten employees come to a single consensus on what it means to be respected. My answer to that is one word — roles. I am not writing about status, or even responsibility, but more about purpose. Respect means giving each employee a role, or purpose, and communicating exactly what that should mean to them.

Not only must the employee own the role, but a business must allow them to define that role, and grant them the authority to work within the bounds of that role. I am reminded often of the TV series The Office when I ponder roles. Dwight K. Schrute, a valued employee at Dunder Mifflin, so desires to have authority bestowed upon him as Assistant Regional Manager. However, he is undermined constantly by his boss Michael Scott, who informs him incessantly he is only Assistant to the Regional Manager.

Although no one enjoys being compared to Dwight, relating to him is quite easy. He is given token responsibilities as a method of appeasement, but no authority to carry it out. He is asked to perform duties not in line with his position, and he is reprimanded for taking initiative in matters he has no business attending to at the Scranton branch. This constant limbo is nauseating to employees in the real world, and it quickly leads to anxiety and uncertainty.

The only thing worse is being expected to fill someone else’s role. When an employee is asked to pull double-duty because a fellow coworker is unable to perform, it can cause a great deal of resentment. In some situations, being shorthanded in one department will cause an overlap in roles. For a short time this might be acceptable, but if resources remain tight long term, then an employer should make amends for the blurred line between roles.
Too easy

Do these three suggestions appear too simple-minded? Could it really be all that easy for employers to keep employees happy by adhering to those principles? There really is only one way to tell, and that is to try and instill those organizational values if you are a manager, and demand those rights as an employee. Openly discussing the issues, and pushing for change in performance reviews and even during interviews will be the only way to help bring about a positive outcome.