DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
What's in store for DevOps in 2023? Hear from the experts in our "DZone 2023 Preview: DevOps Edition" on Fri, Jan 27!
Save your seat
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Measure Your Code to Get Back on Track

Measure Your Code to Get Back on Track

Measuring something your team does can result in improvements. That’s powerful. Establishing measures helps the team stay focused on important activities.

Erik Dietrich user avatar by
Erik Dietrich
CORE ·
Feb. 02, 17 · Opinion
Like (5)
Save
Tweet
Share
5.14K Views

Join the DZone community and get the full member experience.

Join For Free

When I’m called in for strategy advice on a codebase, I never arrive to find a situation where all parties want to tell me how wonderfully things are going. As I’ve mentioned before here, one of the main things I offer with my consulting practice is codebase assessments and subsequent strategic recommendations.

Companies pay for such a service when they have problems and those problems drive questions. “Should we scrap this code and start over, or can we factor toward a better state?” “Can we move away from framework X, or are we hopelessly tied to it?” “How can we evolve without doing a forklift upgrade?”

To answer these questions, I assess their code (often using NDepend as the centerpiece for querying the codebase) and synthesize the resultant statistics and data. I then present a write-up with my answer to their questions. This also generally includes a buffet of options/tactics to help them toward their goals. Invariably, I (prominently) offer the option “instrument your code/build with static analysis to raise the bar and prevent backslides.”

I find it surprising and a bit dismaying how frequently clients want to gloss over this option in favor of others.

Using the Observer Effect for Good

Let me digress for a moment before returning to the subject of preventing backslides. In physics and science, experimenters use the term “observer effect” to describe an experimental problem. This occurs when the act of measuring a phenomenon changes its behavior, inextricably linking the two. This presents a problem, and indeed a paradox, for scientists. The mechanics of running the experiment contaminate the results of the experiment.

To make this less abstract, consider the example mentioned on the Wikipedia page. When you use a tire pressure gauge, you measure the pressure, but your measurement lets some of the air out of the tire. You will never actually know what, exactly, the pressure was before you ran the experiment.

While this creates a problem for scientists, businesses can actually use it to their advantage. Often you will find that the simple act of measuring something with your team will create improvement. The Agile concept of “big, visible charts” draws inspiration from this premise.

In discussing this principle, I frequently cite a dead simple example. On a Scrum team, the Product Owner has ultimate responsibility for making decisions about the software’s behavior. The team thus needs frequent access to this person, despite the fact that product owners often have many responsibilities and limited time. I recall a team who had trouble getting this access and put a big piece of paper on the wall that listed the number of hours the product owner spent with the team each day.

The number started low and improved noticeably over the course of a few weeks with no other intervention at all.

The Importance of Measurement

The simple act of measuring something your team does can result in improvements. That’s powerful. We haven’t even done anything with the measurement results yet.

You can probably now understand why I find it so dismaying that teams opt to skip the static analysis implementation. The simple act of setting up the tools and making their results visible can have a lasting positive effect. The concept of “gamification” builds on this idea and gives us the astonishing success of Stack Overflow, where people labor for free in the hopes of chasing “points” and “badges.”

Before Scrum or Stack Overflow, famous management consultant Peter Drucker purportedly said, “what gets measured gets managed.” Measurement’s impact transcends the observer effect and helps establish goals and means of tracking progress. Returning to the product owner example, perhaps the figure improves from two hours per day to five, but the team really wants seven. Establishing seven as a goal and examining the reasons for the shortfall can help improve things even more.

Nothing about this should mystify anyone reading.  But the complexity of the workplace has a tendency to gobble up deliberate action and put us into a frantic churn of emails, meetings, and “fighting fires.” Establishing measures and goals helps the team stay focused on important activities and prevents their sweeping under the rug.

The Sins of the Past

All too often, we mistake simply identifying problems for having solutions to them. “Oh, we had way too many dependencies! We won’t make that mistake again.” This represents a macroscopically focused attitude — one that will promptly get lost in the day to day activities of writing code.

As I mentioned in the beginning of this post, when teams call me, they don’t pick up the phone to tell me how well they’re doing. They want to know why their code got messy and how they can fix it. They want a different outcome. For this to happen, they also need specific, actionable information.

“This code has large, complex methods and classes. You’re using global state extensively. You frequently write to external sources, making the code hard to test. You take an outsized number of dependencies, making refactoring difficult.” And so on.

“Oh, thanks for letting us know. We’ll stay away from those problems in the future.” This sentiment represents an excellent start, but only a start. The team needs visible measurements of what “good” looks like.

“Fail the build if more than 5% of classes have 300+ lines. Do the same with use of global variables. Issue a warning if more than 3% of classes write to files.” Now we’re talking.

I really mean that. We’re talking. Such rules exist not to create draconian restrictions, but to force conversations. “Hey, we’ve had problems with hard to test code in the past. Your commit just pushed us over the threshold of more than 3% of classes writing to files. Could we revisit our approach here?”

Don’t Boil the Ocean

Assuming that you find my argument for code metrics to be appealing, I will leave you with one final piece of advice. Avoid implementing every metric or best practice that comes to mind. You will thrash and you will give up.

Start by picking a few that seem most critical and getting those within acceptable thresholds. Once the team grows used to that and accepts it as a norm, move on to the next few. This creates a constant cycle of mastery and growth.

Measuring practices around your code is critical to your success. If you don’t have measurements around your coding practice, go out and get them. Make sure that you improve at a sustainable pace so that you continuously reap the benefits.

scrum agile Measure (physics)

Published at DZone with permission of , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Unleashing the Power of JavaScript Modules: A Beginner’s Guide
  • Top Five Tools for AI-based Test Automation
  • Exploring the Benefits of Cloud Computing: From IaaS, PaaS, SaaS to Google Cloud, AWS, and Microsoft
  • What Java Version Are You Running? Let’s Take a Look Under the Hood of the JDK!

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: