Tag Archives: software

When Does Counting Lines of Code Make Sense?

ALERT: I’m not pulling any punches with this one. If you are looking for a balanced argument including thoughts on some potentially good reasons to measure LoC, you won’t find it here. The best reasoning I can give for the existence this article: it gives me something to point people to when they ask for my opinion on the topic.

Counting Added Lines of Code as a Measure of Productivity

“Any process or procedure that incentivises based on creation or destruction of lines of code is missing the point entirely.”

David Adsit
Software Craftsman – Pluralsight

Counting LoC drives bad behavior and is easily manipulated. It leads to developers being less concise and writing code that is difficult to maintain. There are so many ways to write code less efficiently and these are exploited in a scenario where LoC are measured for productivity.

Here is one extremely simple example of code inflation:

Arrays.fill(array, -1);

and

for(int i = 0; i < array.length; i++)
{
  array[i] = -1;
}

The above examples logically equivalent in Java. They both work. They both do the exact same thing. In C# the first could look like the following:

array = Enumerable.Repeat<int>(-1, array.Length).ToArray();

We could also write our own C# extension method to match the simpler Java method and use it throughout the code in future improving readability and maintainability.

public static void Fill(this int[] array, int fillValue)
{
  for(int i = 0; i < array.length; i++)
  {
    array[i] = fillValue;
  }
}

Once complete, it would be executed as follows:

array.Fill(-1);

This approach would lead to a couple of additional lines when it is first written ONCE and then only one line to do the same work forever after. Assuming of course that people know the extension method exists and they use it… another discussion perhaps.

One of the reasons we use modern programming languages is because they are expressive and easy to read. Even in a current modern language, older and more verbose approaches are still valid in code (to enable us to customize better approaches on our own that are not supported by the framework) and can easily be exploited by developers looking to boost their LoC written.

Counting Added LoC as a Measure of Productivity Must be Based on False Assumptions

“[Counting lines of code as a measure of productivity] presumes that each day or week or month is the same as the last day, week, or month, and that the thought stuff we actually get paid to do doesn’t matter.”

Dwayne Pryce,
Senior Software Engineer Microsoft Research

Measuring added LoC also assumes the work completed before, after, and during the coding process to determine best/cleanest/most maintainable/efficient approaches are meaningless and that testing to verify that the code does what is was intended to do is a waste of time.

Additionally, less-experienced junior developers are always going to write more lines of code than senior people for a variety of reasons.

  1. Junior people often take the easiest, most brute force approach because they haven’t learned to do it better. Yet.
  2. Junior people are given less complex tasks to solve that can be done more quickly.
  3. Progressively more experienced people have additional increasing responsibilities (for example mentoring and training less experienced people, doing more code reviews, being involved in architecture/design discussions, taking on difficult roles like security guild, creating documentation, etc.

1 and 2 are arguably best solved by pair programming. Another discussion. Another time.

Counting Removed LoC as a Measure of Paying Technical Debt

“Simplicity is the ultimate sophistication.”

Leonardo da Vinci

Same as measuring added LoC, counting removed LoC drives bad behavior and can lead to developers writing code that is intentionally overcompact and difficult to read. However, in a large and unwieldy application, we want to remove lines that serve no purpose at every opportunity while maintaining the same functionality. If this were trivial, we could simply automate programming and developers would no longer be needed. Making things simpler is, simply put, not easy.

Counting LoC as a Measure of Quality

In the history of computer science, there has never been a valid correlation between LoC and quality in any programming language in existence. Check the textbooks, the internet, or anywhere else you can think of. This correlation does not exist.

The Burden of Unnecessary LoC is Non-trivial

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”

Bill Gates

I’ll use a slightly exaggerated example here, but it isn’t too far off, so please bear with me. Let’s assume we have two people attempting to solve a difficult problem.

Persona A

  1. may be less experienced or expert beginner
  2. just get’s it “done”
  3. tends to solving problems hastily without concern for introducing bugs
  4. often works quickly and on their own without taking time for design discussion, planning, and refactoring
Persona B

  1. may be more experienced
  2. cares about quality and hates bugs
  3. aims to understand the scope of the problem before starting to solve it
  4. involves others (seeking real input) to suss out design flaws and make take more complex problems to a mentor

I’ve seen real life scenarios where Persona A will solve a similar problem in 2000-3000 LoC where Persona B would solve it with 200-300 LoC. That may not seem so bad. Maybe Persona A finished their effort in less time than Persona B. Now consider, from the time this code goes into production until it is replaced/removed/refactored/decommissioned, we have to pay to maintain the code that was written. When we want to make a change in the behavior of the

Maybe Persona A finished their effort in less time than Persona B. Now consider, from the time this code goes into production until it is replaced/removed/refactored, we have to pay to maintain the code that is written. When we want to make a change in the behavior of the code or add a new feature, Persona A’s code may require days of review to understand and will also require many changes to achieve. To make a similar change to Persona B’s code, it could be understood in an hour, perhaps. The changes should take considerably less time depending on their complexity.

When we want to make a change in the behavior of the code or add a new feature, Persona A’s code may require days of review to understand and will also require many changes to achieve. To make a similar change to Persona B’s code, it could be understood in an hour, perhaps. The changes should take considerably less time depending on their complexity. Of course, this scenario is hypothetical. This is my one apology for rhetoric.

Coda

For clarity’s sake, I’m in no way arguing against hiring junior people. Fresh blood is vital for tons of reasons I won’t go into here. However, the effective incorporation of junior people must be accompanied by the correct structure and support from more experienced people in order for them to succeed. I AM against hiring expert beginners who’ve been doing this work for many years and thinks the “just get it done” approach is the best/only way.

 

Holy Microsoft, Now Compile

The following is 100% parody of the good-natured Weird Al variety. Much like a good Weird Al song, I couldn’t get it out of my head, so now I’m subjecting you to my foolishness as well.

I offer up my apologies to Catholicism in general. Microsoft, on the other hand, can fend for itself.

 

Hail Microsoft, full of office tools.
Our code is with thee.
Blessed art thou among DEVELOPERS,
and blessed is the fruit of thy IDE: executables.
Holy Microsoft, Mother of C#,
pray for us sinners,
now and at the hour of our broken build.
Compile.

 

Now share this post with 10 people and Bill Gates will donate 99% of his wealth to charity.

Legacy Dependency Kata v2.0

Well, well, well. Look what the samurai dragged in. An updated version of my Legacy Dependency Kata. I’ll have to update the Coding Kata Resources page.

50795_01_kurosawas-classic-seven-samurai-gets-stunning-4k-remaster

I’m not proud to admit that there even was a v1.0 at the moment. Let me explain.

Just over two years ago, I was experimenting with writing katas, presenting at code conventions, and running a coding dojo. It turns out. I wasn’t super fantastic at any of these things. Nevertheless, I wrote a kata, ran it a few times with the kind folks in my dojo, and proceeded to share it with the delightful folks at Utah Code Camp 2014. Reviews were mixed, but overall I felt good about it.

Fast forward to the present. While planning the lunchtime learning schedule for our recent SAFe Program Increment, there was an opening, and I, ever so graciously, decided to run my Legacy Dependency Kata for folks who may not have had the chance to see it before. Upon thoroughly embarrassing myself with some of the crappiest kata slides in existence (slides even I couldn’t completely fathom), I recognized that my life would be forfeit if folks were forced to do the kata again with the same slides the following day.

I dashed to revise the slides and spent many hours on the task. When I presented the kata on the second day, it was a much more successful attempt. I’d go so far as to call it a version 1.7. I spent some more time and enlisted the advice of the ever-gracious and capable Kaleb Pedersen in finalizing v2.0. The source code is still the same. Legacy code problems from 2 years ago are still very similar to what they are today.

coughnounittestabilitycough

I think the new slides do their job. Could this kata still be better? Without a doubt. Please submit your recommendations in the comments or feel free to yell at me on Twitter. I’m sure I deserve it for something.

Without further adieu, I give you Legacy Dependency Kata Version Two.

Seed code is still on GitHub:
https://github.com/KatasForLegacyCode/kCSharp/releases/tag/Step0

The Pursuit of Simplicity

Recently I read Seven Brief Lessons on Physics by Carlo Roveli. True to its title, the book is brief, and clocks in at a scant eighty-one pages. Its beauty is in the nearly poetic brevity and the expressive nature of the word choices the author (and translators) use. Unlike massive scientific tomes on particle physics I once attempted to read as a 12-year-old boy, Roveli’s book is written in a way I could have understood even as a young boy.

The book brought me a remembrance of the elasticity of young minds with its references to young physicists like Einstein, and his solving massive problems with simple solutions at a very young age. The book inspired me to write, and this is the result.

Fractal_tree_bbc

Anecdote Time

When I was a first-grade elementary school student, I recall having a tough time memorizing multiplication tables as students were taught to do at the time. Ever precocious, I wanted there to be some rhyme or reason, a pattern even, to the way we determined the values of these simple mathematical expressions. No, I was told, you just have to add the number you are multiplying by to itself the number of times the multiplier expresses.

For a young, and frankly lazy, Willy Munn, this was an annoyance at best for a number like one, two, and three; and completely unbearable for the silly number nine. You see, not being able to use a calculator or a multiplication table, and being required to show my work meant writing out nine addition problems just to “show my work” and get an acceptable grade.

My young brain started looking for a better way. It wanted to enable the laziness my heart so desired. It wanted to find a way for me to skip writing out these problems and allow me to go back to reading or playing with Lego blocks or watching the Superman movies I taped onto VHS from TV. I WANTED some rule as simple as “1 times anything is the number being multiplied” or “10 times anything is the number being multiplied with a 0 tacked onto the end”. I started to see patterns (we are talking about math after all, which is nothing without patterns). A solution for the ridiculously tedious number nine came first.

Looking at the following multiplication table, I unconsciously looked for patterns I could exploit. What patterns do you see?

1*9=9
2*9=18
3*9=27
4*9=36
5*9=45
6*9=54
7*9=63
8*9=72
9*9=81
10*9=90

I noticed the following in this approximate order:

Reversed Pairs of Numbers as Results
This was the first thing I noticed. 18 and 81, 27 and 72, and 36 and 63 all the results on opposite ends of the table form numeric palindromes. Even 09 and 90 technically work.

Everything Adds Up to Nine
Next, I realized that the first and second digit of every result always add up to 9. This seemed like something exploitable, and I saved the knowledge for later use.

First Digit Is The Number Being Multiplied By Minus One.
Eureka! I had a formula (even if I didn’t know that’s what it was called). I could take any number one through ten and subtract one from it for the first digit. Then I could subtract that number from nine to get the second digit. Simplicity itself!

I took my solution to Mrs. D, my first-grade teacher, for confirmation. I just knew she would be so happy and proud that I had found a better way to do multiplication by nines.

My youthful supposition couldn’t have been farther from the truth.

A study in human nature, being an interpretation with character analysis chart of Hoffman's master painting "Christ in the temple"; (1920)

Mrs. D. assured me that this was not the proper way to do the math and that I must write our all of my answers as she had taught. Needless to say, if young Willy Munn was a thing besides lazy, he was stubborn. I dug in my heels, so to speak. I refused to do this work stating that I would sooner die than do unnecessary work after I had found a better solution. Predictably, Mrs. D marched me right down to the principal’s office and demanded that he deal with my insubordination. She suggested corporal punishment if necessary.

The principal of my elementary school, Mr. F looked at me with kind, wise eyes, mostly gray hair, and just a quirk of a smile on the edge of his lips, and asked me to explain my method to him. I was nervous. I didn’t know what this corporal punishment was, but it sounded serious. With sweaty little palms and a mildly shaky voice, I explained my idea for the number nine. Mr. F asked some thoughtful questions and proved my hypothesis on the blackboard in his office. Then, to the joy of my young heart, he said the words I had so desired to hear from Mrs. D, “Willy, it looks like you’ve come up with a better way to solve this problem. At least for you.” Then the golden words of freedom, “Mrs. D, since this proves out, it shouldn’t be necessary for Willy to write out all of his multiplication solutions should it?” Mrs. D grudgingly agreed with her boss, although I’m fairly sure she held a cold, dark place in her heart for me for the rest of the year. In retrospect, maybe I shouldn’t have challenged her so directly, but I was 6 and thought the world revolved around me.

Mrs. D grudgingly agreed with her boss, although I’m fairly sure she held a cold, dark place in her heart for me for the rest of the year. In retrospect, I shouldn’t have challenged her the way I did, but I was six and thought the world revolved around me.

I went on to “discover” patterns for other simple multiplication problems that saved me a bit of time over the years, and even eventually memorized all the basic times tables. For several years, I got away with doing all of my math problems in my head and never showing my work. This irritated my teachers to no end and probably is what made learning manual Calculus feel like one of the most tedious tasks I’ve ever undertaken.

Many years later, while attending Southern Utah University, I learned additional math practices in my Discrete Mathematics class that used similar patterns and approaches to my early experimentation. Fun realization, that.

The Point (There Is One)

I knew, even as a youth, I had spent more time working on this solution than it would have taken just to write out the problems as I had been asked.

Today, I recognize my solution as less simple from the Mrs. D’s viewpoint. She was giving students one tried and true way of solving all multiplication problems. While it wasn’t easier for me to achieve my work, it was certainly simpler to teach. Just because there is a pattern or formula, doesn’t make a solution better based on that merit alone.

A fractal bacteria colony may BE simple once you understand it, but at first glance, it seems strange and complex.

fractal_bacteria_colony
Fractal Bacteria Colony

All anecdotes aside, the pursuit of better, simpler solutions is one that I’ve been chasing from a young age. It is the same pursuit of any scientist including the computer scientist. Let’s not forget this as we write code. Our ultimate goal should be the simpler solution because it will lead to better, more maintainable code. It will save time overall even if there is an opportunity cost up front.

We must remember that what is simpler from our particular point of view may not make sense from another’s perspective. A simple solution is only as good as our colleagues’ ability to grasp it.

2014 Developer Learning Guide: Part 3

This is the 3rd and final post in my series on continuous developer learning. I recommend you read 2014 Developer Learning Guide Part 1 and Part 2 if you haven’t already.

When I started writing about this subject, I thought I would cover all of the options in one post.

I.

Was.

Wrong.

One of the wonderful things about learning, is that there is a lot to learn about it! I’m in the process of recording a new podcast with a friend of mine and one of our first episodes will iterate just exactly why we believe continuous learning is so important. Stay tuned!

Now, the finale…

In-Person (Larger Groups/Formal Training)

Hackathons/Hack Nights

Hack-er
Um… wrong kind of hack!

This is one that I need to get more involved in. I’ve heard great things about hackathons. I only attended my very first one a couple weeks ago and it was a good experience (all WiFi issues aside).

Additional personal experience is more related to startup work even less formal than these events. There have been a couple of times I’ve tried to put together a quick app or program in a short amount of time using the MVP or “Minimum Viable Product” approach from The Lean Startup. I found that I learned a remarkable amount in a short amount of time.

I learned even more when I did this together with some friends who ranged in skills from entrepreneur to systems admin to programmer to business development.

Code Camps/Large Conferences

I’ve considered writing an entire post about these. There is nothing like being surrounded by others who are looking to improve and be awesome at what we do.

This kind of event can run from half a day to a full week. They tend to be a little heavier on the pocketbook, but you can find lower cost options as well. If you live in an area with a very active tech community, you will probably have many great local options that at least save you on the travel costs.

Conferences really get the creative juices flowing and keep you fired up about your work. Most major tech companies have at least one developer conference per year (Google, Apple, Facebook, Microsoft).

WWDC

Employers with a decent training budget send their developers to 1-2 larger conferences per year (almost never 3+).

I try to mix it up like so:

  • 1-2 out of town conferences. I enjoy travel and this is a nice opportunity to get out of the state for a few nights.
  • 2-3 local conferences. To help keep the budget down.
  • As many code camps as I can reasonably attend.

Why so many? There are a lot of topics I’m interested in and it just so happens that they are all related to my work. This year, I attended an AngularJS conference (ng-conf), an Agile conference (AgileRoots was amazing), Utah Code Camp, and DevFest Family. I’m still planning to attend a large UX conference and a more hard-core software engineering/architecture conference.

I’ve also found it extremely valuable to speak at some of these events. No one learns more than the person who stresses over getting in front of a bunch of smart people to tell them about something!

On-site Training

This type of training is great when you have a team that all needs to get on the same page.  Schedule a trainer to come out to your company on your schedule. I will turn you loose on Google for this one… do a little research and you will find many companies offering this type of service.

My experience here is positive. On-site training sessions can be highly valuable just make sure you get a great trainer. Interview them first or suggest a trial session.

Costs, I’m not super sure on but what is published online is $1000-5000 per session. If you think you will have an ongoing need for this, negotiate a better rate.

Certifications/Degrees

Certifications are highly valuable for IT people although they are not be as well recognized in development circles. I have a former boss who refused to interview candidates with Microsoft’s developer certification on their resume…

MIT
MIT. Yes, I know there’s a TARDIS on it.

Advanced degrees are valuable if you are specializing in certain areas of our field. Machine learning, concurrent programming, and human computer interaction are all excellent examples.

Both certifications and advanced degrees become considerably more valuable if your company is willing to pay for part or all of the tuition. Without that, I would probably avoid them because your return on investment may not be very good.

Conclusion

As you can see, the options for learning run the full gamut of price, time, and commitment. The great news is, even if your company has little or no budget for training, all you need is a couple committed developers to get started with the less expensive (free) types of training. Even better if your company agrees to a budget or commits to learning in other meaningful ways (time/food/support).

I recommend that you seek out employers who understand and value learning. I have and I couldn’t be more glad.

Remember to read 2014 Developer Learning Guide Part 1 and Part 2 if you haven’t already. Follow me on Twitter (@dubmun) for comments about development and other shenanigans.

Image credits:
https://www.flickr.com/photos/anantns/
https://www.flickr.com/photos/notnil/
https://www.flickr.com/photos/bbcamericangirl/