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. 

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: 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: 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: 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: 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: the impact set of  fitnesse  20151230. 

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

 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: 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  ' impact set. 

And this little minx.

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.