Using SLOC to Take the Pain Out of Decision Making
Split second decisions. As I was driving over the Memorial Day weekend, I was reminded of all the important decisions we make daily. While merging onto the expressway there was a car next to me and I had to do the quick calculation we all do on whether to speed up or slow down. Since I was slightly behind it, I slowed to go behind.
At work we are paid to make quick decisions daily. Determining when programs can be moved into Production, for example. Often these decisions are like mine on merging: quick and based on calculations that we only dimly understand. They are based on our feelings about the program itself, the nature of the change and also who did the change and the testing. Our brains process all of this information and we make a go-no go decision. Based on our experience over years this has worked for us. But things have changed. We no longer have that connection with the application – or the person that made the change and did the testing. This is due to increased workload, but more so to the outsourcing of changes. So we are faced with applications with which we are unfamiliar.
In this situation, how do we make those quick decisions? How can we make up for this lack of knowledge so we can still make good decisions – quickly? What is needed is a way, an impartial and automated way, to help us assess the nature of the Application, Program, Change and Testing. By impartial I mean something that takes us away from our “gut” instinct, something that would provide consistent results across the board. Automation is key here because we need this impartial information to be ready for us at the time we make the decision.
So, what can be provided to assist us with unfamiliar applications? One gauge often used is Software Lines of Code (SLOC). This is a metric that goes to the roots of computing. I’m old enough to remember the physical representation of this metric in ever expanding card decks. You could easily compare the size of programs based on how thick they were. This metric has remained with us due to its simplicity. But what does it really tell us about the program and the application? Because of all the variables involved (no pun intended), it can’t give us a real comparison with other programs and applications. Straight or “Physical” SLOC can include all the comments, spaces and definitions.
[fusion_builder_container hundred_percent=”yes” overflow=”visible”][fusion_builder_row][fusion_builder_column type=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”no” center_content=”no” min_height=”none”] The ever expanding punch card deck. Attribution: Arnold Reinhold
There are basically two things you need to know about a program for a better comparison: how many statements and how many variables. In an attempt to remedy this, “Logical” SLOC is often used. It measures the number of executable statements. Since you will know how much of the program is involved with logic it gets you closer to understanding the true size of a program to aid in comparisons. By using this metric you will know how many statements the developer will have to review to make a change which helps you estimate the time it will take to evaluate and carry out the task.
In my next post I will discuss what I feel is a better metric to understand the size of a program — the Halstead. There are many metrics under the Halstead umbrella and I’ll show how it covers both statements and variables.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]
Latest posts by Mark Schettenhelm (see all)
- 10 Cross-platform and Mainframe DevOps Tools You Need Today - August 7, 2017
- Waterfall to Agile SCM Conversion: Why Not Use the Best? - May 11, 2017
- Top Four Reasons Your Mainframe Team Needs Chat Apps for DevOps - April 11, 2017