Week 1

Week 2

Week 3

Defensive Programming

Write code expecting it to fail. Amateurs write software for happy paths. Professionals write software expecting it to fail. Professionals limit hubris and know they aren’t omniscient. Expect your code to fail, software to fail, dependencies to fail, systems to fail, and servers to fail. Don’t have servers? No problem. Your serverless functions can also fail for many reasons – like network or permissions.

So, how do you program defensively? There are two primary ways: exception handling and guard statements.

Assuming you are a full-time programmer or have been a programmer at some point in your career, this looks trivial. You may even be wondering how something so simplistic would make it into any modern book on software. Well, building software is about a strong foundation and working its way up the stack. Is your exception handling really handling exceptions?

Software engineers can practically end the world by not checking for null! Imagine how many code errors are caught while engineers are debugging during initial development. Do you have that mental picture? Now consider how much slips through the cracks! Checking for null is the easiest way to protect against both inaccurate data and preventing exceptions from bubbling up and crashing methods, routines, executions, services, and systems overall. LIFT is a system and systems include basics. Check for null.

The second example is focused on accuracy. In this scenario, when an account balance exceeds the predetermined amount, the function returns with that error code. The snippet doesn’t say what happened before or after and for these purposes it doesn’t matter. Protecting the accuracy of the business logic is what matters. In this case, the method returns. In other cases, the code may assign a tracker variable a value and that variable makes it all the way down to the end of the method. There is a time and place for both approaches – and any other of myriad approaches. Don’t judge the examples, mind the principle it exposes.

Aggressive Logging

Questioning logging vs. some other grand idea is excellent in theory. But why push against a technique so well understood and adopted? There are plenty of other challenges during BUILD without sweating something like this.

What do you get from this effort? Your operations team can operate the system without calling you and engineering and generating product incident alerts. And as you look down that list, really consider the consequence of #5. Teams can be at odds between “code vs. network” issues. Log the network failures, and there is less to fight about, and you’ll help the network team get to the bottom of the problems faster and solve for everyone. Win-win.

Debuggable Software

Software is incredibly complex. Debugging software is a primary activity of software engineers today and far into the future. Therefore, reducing the debugging effort on the software you and your team write pays itself today in both the short term and the long term. After all, as soon as the code ships it’s legacy. Someone, maybe you, will debug it shortly.

Small Functions

Write your functions small, as in short, so you don’t end up with spaghetti code, like in Table 4-7 below. It’s that simple. No fancy refactoring or software patterns are required to do this, so even the junior engineer can contribute on day one. Functions call functions. Methods call methods. Rinse and repeat.

Table 4-7

Small functions

Small Functions

Main() {    getCurrentId();    getSystemObject();    log("complete") } private int getCurrentId(){    //call db    // return id    //catch exceptions /* This is considered a short method.  */ } private int getSystemObject(){    obj system = caller.System.Context.Call.Current;    return system; /* This is considered a short method.  */ }

Avoid Coupling Components

Loosely coupled software components are the second key in debuggable software. It’s a term that’s thrown around at times by know-it-alls, newbies, or management. Still, it’s a valid design concern and one that can assist with debugging software, so should be respected.

The concept is simple, but hard in execution for new software engineers. Don’t let the internals of Component A know Component B’s internals. You can see this concept illustrated in Figure 4-4. This goes into all kinds of design thinking around abstraction, interfaces, and polymorphic behavior – but don’t worry about that yet. Just stick with A doesn’t know how B works. A only knows how to work with B – but not what B does internally. This is accomplished differently depending on the language in use. In Java, this is usually an interface or abstract class. It’s also achievable via naming conventions and data hiding in just about any language.

What Coupling Looks Like

Anti-Corruption Layers

If there is one practice that can easily, and I mean quickly, be picked up by even an average experience development team, it’s the concept of anti-corruption layers published by Eric Evans in his book Domain Driven Design. Domain Driven Design (DDD) approaches software projects by thinking, modeling, and building around the domain using abstractions that work. This is different than the traditional object-oriented programming approach to model the real world with software. As we all now know, an e-commerce shopping cart doesn’t mimic the shopping cart in your local Walmart store well at all. Software is nuanced and complex; a shopping cart made of metal is as simple as it gets.

Would you like the benefits of micro-service and distributed architectures like resilience, independent versioning, and deployment velocity without rewriting your world to micro-services?

Well, you’re in luck, because the anti-corruption layer acts as a facade or intermediary between System A and System B. It translates what comes out of System B (someone else) into your language and data structures in System A (you). This prevents System B from leaking into your system, and that is more amazing than it sounds.

From experience, all systems, data, and APIs that aren’t under your direct control are foreign forces with unclear intentions. That’s right. Managing dependencies is serious business as your product’s health and long-term maintainability is on the line.

Think of it like this: if you integrate the Foo API and your app breaks or is slow, it’s your fault. However, The Foo API team has no problems. They are the service provider, and you are the user. Sure, the service provider has different stressors (reliability, uptime, versioning, etc.), but your failure is not their failure. Your product’s loss is your product’s failure. Period. So, protect yourself because, in software, no one will come to save you.

Is an anti-corruption layer this additional work? Yes, of course, it’s extra work. But it pays for itself very quickly. Generally, in life, if it’s too good to be true, it probably is. Will that new exercise bike make you lose 20lbs? Not right away. Can you buy a stock that will surely deliver 300% gains? Probably not. So, you’ll have to put your inner pessimist on mute for a bit because creating an anti-corruption layer to protect your system from another team’s system will return significant gains. And it will produce those gains almost overnight.

Consider System A (e.g., your system/product/app/service) is responsible for calculating car leases’ historical prices. For this to work, A must call into APIs from System B, which return the last three years’ costs at different fidelity levels for all vehicles manufactured and headquartered in Europe. They produce data structures ABC, which have GUIDs (globally unique identifiers). This is not unusual, nor is it a problem.

Look at Table 4-8 – System A also has to integrate with System C, a daily FTP drop of 5-year prices for all vehicles manufactured and headquartered in Japan. This integration has yet another data structure and because they are sane, use an increasing numeric value as their identifier.

Table 4-8

Systems at play

System B API – Europe	System C FTP Drop – Japan
GUIDs	Numeric Identifiers
JSON	CSV

You are at a crossroads. Do you want your development team leaking System B GUIDs and System C numeric identifiers down into all your app code? Do you want your junior engineer to understand these two data sources’ internals and intricacy and then start coupling external GUIDs to your internal models?

Thus, the creation of the anti-corruption layer.

All the code goes into this layer. This layer maintains the contracts with the other systems, performs data translation, and maps your internal models. The internals of System A now work with the anti-corruption layer, and it can’t break. It’s your model to your model. Not your model to N models. And there aren’t foreign abstractions spreading across your codebase. See Figure 4-5.

If this interests you, please read more about Domain Driven Design in Eric Evans’ book. It’s also a prevalent practice, and a quick Google search will yield more than enough results to get started.

Anti-Corruption Layer Diagram

Performance

This is a two-edged sword.

One edge says not to overoptimize, which can also be used to mean don’t optimize early. New engineers and those who lack humility throw around old Donald Knuth quotes like “Premature optimization is the root of all evil.”

Really? I doubt it.

Let’s dispel the misinterpretations of this quote first. He said optimizing algorithms by nitpicking at code before it was profiled was a waste of time. He wasn’t saying that optimizing software before it fell over under use was a waste of time.

Take this to its logical conclusion and optimizing the right things early is a healthy practice. Consider a system that handles ecommerce orders – what if it couldn’t handle more than three concurrent orders? That’s not helpful. Or a system that exchanges records with a regulatory authority. It can handle one transaction a second and then the business development team hits it’s goals and sells 100 more licenses. Now, this is not going to be pretty, because unless the team gets in there to make significant changes immediately, there will be a lot of upset customers.

Write Things Down and Document As You Go

No two teams are the same, and different teams, even inside the same company, are going to operate at different maturity levels when it comes to documenting and understanding the system. Now, there is no argument that the best way to understand a software system is to write readable code. But is that enough? OK , now toss in unit tests that describe the behavior and test the code, is that now enough?

Of course not. Why?

Because we live in the real world and not some academic textbook or idealized scrum fantasy where everyone does everything, knows everything, has the same desires, and can live via tribal knowledge. Teams are spread out with people in different offices, work from home, and time zones. Information must be documented. And, as we’ve pointed out over and over, software systems are more than the code. If the build environments, deployment environments, database schemas, and terraform scripts aren’t documented in some form, then how will the team ever find efficiencies?

Document as you go.

Beliefs

It’s all waste when looked at from a given perspective. But turn the view, and you’ll see just how subjective these concepts are.

The Product Manager needs those meetings because she doesn’t know if the development team understands the requirements and sequencing. So, this is how it’s done in her world. The Software Engineer doesn’t choose to avoid big releases because Operations hasn’t worked with them to decompose the production infrastructure footprint. And the unreleased software is a fact of life to both Operations and Software engineering because the requirements for them change too often from Product Management.

Now, none of this is true. It’s just a perspective. It’s no different than Plato and his allegory of the cave.

In this allegory, Plato asks the reader to consider people born and raised in a dark cave, held in place to only face forward. On the other side of a wall are people who carry objects shown as shadows on the far wall from a fire burning in front. The people held captive see the shapes cast by flame and only know these shadows as objects in the world as they have no other experiences.

Next, Plato suggests that one of these people is set free and led up a steep incline out of the cave and into the sun. The sun burns his eyes, and it takes time to make out the shapes of the real world as his brain cannot believe. Given enough time, this individual prefers the outside world’s freedom and new reality and returns to the cave to tell the others. Upon return, he can no longer see in the dark, and the captives believe that the outside has ruined his eyes – and therefore, it would be perilous for any of them to venture outside. And they all prefer to stay.

Teams put these possible waste items in place because of previous experiences and a need to stay in the cave. Let’s use the example of the meeting again. The Product Manager states she needs the meetings for a few reasons: gather status, take questions, and discuss the next iteration. The engineering team (dev + ops) says this meeting is a waste because they are busy on the current iteration and don’t have questions; they want to remain heads down. Their rationale that the meeting is a waste stems from: they are actively working, and switching in and out of development is a waste of time on its own.

Last year was the Product Manager’s first proper software assignment with a different development team. The Product Manager did not meet regularly during an iteration with the team and missed several deliveries that year, reflected in her annual review. Her experience tells her that these meetings are critical, and she must push the development team. The meetings are her cave and fire – the shadows on the wall are real for her.

The lead developer tries to pull her up and into the light by taking her to coffee and explaining that finishing the iteration is the team’s most critical job, and the mid-iteration status meetings can wait. But to the product manager, skipping status meetings is dangerous. Her only experience developing software products failed without meetings. So, the meeting stays on the calendar, and everyone attends, begrudgingly.

This isn’t an attack on Product Managers – far from it. Let’s look at the lead developer.

She has been shipping software into production environments for ten years. A lot of what she has learned and internalized tells her continually reducing build times will lead to better product outcomes. That may be true to an extent, but there is a point of diminishing returns. She received rewards for reducing massive legacy applications build times from 60 minutes to 10 minutes in her previous role. It was a stated goal from her manager and did make a difference for the firm because that reduction allowed them to bring on additional teams to make changes to this application to help them in the marketplace. In another role, the architect approved of reducing build times as a breakthrough because the firm didn’t have any continuous build and integration previously.

In the current team, she and the team spend 20 hours a week trying to take an extra two minutes off an 8-minute build cycle. This building cycle has several dependencies to bring in, tests to run, and a deployment validation cycle. The team is one iteration behind, the PM is stressed, and the lead engineer won’t stop this work because this is what she knows. Reducing build times is her cave and her fire.

Deploy

After going through this evolution a couple of times, a team finds its natural rhythm. And underlying the team’s rhythm is the constant drumbeat of “checking-build-deploy” of continuous integration. Now, CI is a standard and table stakes operation, but cannot be left out. After each developer code commit (check-in/push) to source control, a build process must kick-off, run any available tests, and deploy the bits to a development environment.

This environment is how the product, QA, and the entire development team see the fruits of everyone’s labor and avoids the “works on my workstation” syndrome.