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

The 80% Rule of Program Coupling

How understanding the fundamentals of software structure is a great way to earn job security.

Edmund Kirwan user avatar by
Edmund Kirwan
·
Aug. 13, 22 · Opinion
Like (4)
Save
Tweet
Share
9.00K Views

Join the DZone community and get the full member experience.

Join For Free

Look, you want job security in the software industry? Here's how you do it.


Software Codes Rely on Fundamentals


There is no question that you can do a significant bit of good for yourself if you just learn how to work with 80% of the software based entirely on its fundamentals. This means that you may want to look at the core aspects of what makes a piece of software tick if you want to see how it can be improved. 


Right now, companies are offering handsome sums of money to those who can do things such as security testing their software or use other methods to improve upon the product they have already created. You just need to dig into what makes that software work and you are all set. People get pretty excited when they hear this, and they should! Make sure you learn how the basics of the software code work, and you are off to the races.


Examine software fundamentals, tease out the problems associated with those fundamentals and learn to solve those problems. These fundamentals are shared by all computer languages, across all applications, are unchanged in forty years, and are unlikely to change any time soon, as are their associated problems. Hence your workplace desirability.


The most fundamental of these fundamentals reveals itself in a trivial observation: software is composed of interacting parts. It has structure.

The timeless problem of structure is that when you change one part, you may also have to change others because these interacting parts interact. 


This means locking horns with your favorites: coupling and ripple effects. From a programmer's — and corporate accountant's — point of view, if a program's heavily coupled, its design is no good and only further investigation will tell. Low coupling does not imply good design but presents a crisp, inescapable prerequisite.


So, how do you tell — at a glance — whether a program's heavily coupled? You measure a property of its methods. Then you establish a threshold coverage — say, 80% 1 — such that only when 80% of the program's methods meet a certain property value can that program be considered loosely coupled. If it doesn't, that puppy's heavily coupled, and scrappage ensues.


So what property do you measure? How do you measure coupling 2?

Take method x() and count all the methods that depend on it directly or indirectly: that's your property. That's the impact set of x(), the most likely set of the methods that (in a worst-case scenario) might have to change when x() changes. That simply is the coupling.


Combining both ideas, your job-securing, lightning-fast program evaluation will look like this: 80% of this program's methods are depended upon by up to 10 other methods.


Or: 80% of this program's methods are depended upon by up to 17 other methods: Ugh. You really need me working here.


Or: 80% of this program's methods are depended upon by up to 23 other methods: my rate's doubling with every minute.


But... which figure do you choose? 10, 17, or 23? Is there an absolute figure for sloppy design? Well, no. But this litmus test allows us to compare any two programs. So let's turn the problem around and re-examine some java programs that this blog's already studied (and others besides) to find a nice low coupling figure to aspire to. Once we identify the good, all the rest will be bad.


Figure 1 shows the impact set for spring 3.2.0.rc1 3.

figure 1: spring's impact set

 Figure 1:  spring  's impact set. 

Yeah, so it's a CDF graph, and graphs put you in the kitchen at parties. But this one's interesting, honest: find 80% on the y-axis, follow it until it hits the curve, and read down to the x-axis. Thus: 80% of spring's methods are depended upon by up to 8 other methods. Is this good? Is this high or low coupling? We shall see.

figure 2: junit's impact set

Figure 2: the impact set of  junit  4.11. 

 

80% of JUnit's methods are depended upon by up to 9 other methods. We're going in the wrong direction. We want fewer dependent methods, not more.

figure 3: lucene's impact set

Figure 3: the impact set of  lucene  5.2.1. 

80% of Lucene's methods are depended upon by up to 9 other methods. No help here.

figure 4: log4j's impact set

 Figure 4: the impact set of log4j 5.2.1. 

 80% of log4j's methods are depended upon by up to 6 other methods  . Wow, that seems pretty good. Its 80th percentile impact set is 33% lower than, for example, Lucene's; you might say it's a substantial 33% less coupled. Well done, Log4j. But can we go lower?

figure 5: ant's impact set

 Figure 5: the impact set of  ant  6.2.1. 

 80% of ant's methods are depended upon by up to 8 other methods  . We're heading in the wrong direction again.

figure 6: fitnesse's impact set

 Figure 6: the impact set of  fitnesse  20151230. 

 80% of FitNesse's methods are depended upon by up to 10 other methods. Eeeewww…

figure 7: antlr's impact set

 Figure 7: the impact set of antlr 2.7.7. 

 80% of ANTLR's methods are depended upon by up to 12 other methods. Then we come to Netty. 



figure 8: netty's impact set

Figure 8: the impact set of  Netty  4.0.36. 

Just look at that jaw-dropping low coupling. 80% of Netty's methods are depended upon by up to just five other methods!

Here, then, is the gold standard. And Netty's no tiny, easy-to-design toy: it has 13,000 methods of loosely coupled gorgeousness. So if Netty's programmers can do it, why can't you?

And Netty's not even alone. Here's JGroups.

figure 9: jgroups's impact set

 Figure 9:  JGroups  ' impact set. 

And this little minx.

figure 10: spoiklin soice's impact set

Figure 10: the impact set of  spoiklin soice  . 

The conclusion may be drawn that building systems according to the 80% rule - with an 80th percentile impact set of just five methods or fewer - is a demonstrably achievable goal. Because it's achievable, larger 80th percentile values suddenly become commercially questionable.


So there's your job security: learn how to design programs as good as Netty and your pension's safe.

Summary

Yes, this post glossed over a slew of subtleties. The 80% threshold is arbitrary. Some programs might conceivably be less coupled with even higher thresholds. Everything described here is metric, and all metrics can be faked 4. and many more besides.


Despite this, the above metric seems to capture the age-old coupling phenomenon.

Do not think that coupling has been solved for a moment, and modern programmers have simply wafted on to other challenges. Fundamental problems do not "age" away. As you can see from the above examples, coupling continues to generate massive and unnecessary costs in our industry.


Yet clearly, some people can manage it better than others. The programmers of Netty look forward to comfortable retirements. Do you? Thanks to Mairbek for pointing out Netty as a design worthy of study.

Netty (software)

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How to Deploy Machine Learning Models on AWS Lambda Using Docker
  • DevSecOps Benefits and Challenges
  • The Real Democratization of AI, and Why It Has to Be Closely Monitored
  • 13 Code Quality Metrics That You Must Track

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: