ALTERNATE UNIVERSE DEV

CodingBlocks

The Pragmatic Programmer – Is Your Code Orthogonal?

The dad jokes are back as we learn about orthogonal code while JZ (the 8-mile guy) has spaghetti on him, Michael’s Harry Potter references fail, and Allen voice goes up a couple octaves.

Are you reading these show notes via your podcast player? You can find this episode’s full show notes and join in the conversation by going to https://www.codingblocks.net/episode107. While you’re there, be sure to checkout past episodes as well.

Sponsors

  • Datadog.com/codingblocks – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.
  • O’Reilly Software Architecture Conference – Microservices, domain-driven design, and more. The O’Reilly Software Architecture Conference covers the skills and tools every software architect needs. Use the code BLOCKS during registration to get 20% off of most passes.
  • Discover.bot – a digital space for bot developers and enthusiasts of all skill levels to learn from one another, share stories, and move the bot conversation forward. Want to learn more about building bots? Get started with their Guide to Bot Building Frameworks.

Survey Says …

Anonymous Vote
Sign in with Wordpress
What is your preferred type of language to spend most of your day in?
  • Dynamically typed languages like JavaScript or Python. I can't be bothered to compile. I catch my errors at runtime.
  • Statically typed languages like Java, C, or C#. I'd like to say that my errors are caught at compile time. But sadly not always.
  • Functional languages like Haskell or F#. Here's a quarter kid, get a real programming language.
  • SQL. If you're not working in sets, you're wasting your time with one-offs.
vote

News

  • Thank you to everyone that left a review:
    • iTunes: marathon57, NDIndian2019, Steeeeeevee, rholloway4, ogre14t, skmetzger, Knack of flying, vikingsfan421
    • Stitcher: Zach Ingbretsen. LouisHendricks, OhHelpMePronounceThis, omnomynous
  • Wanna kick Allen in the shins? Opportunity is knocking.
    • Allen will be speaking June 24th at the Atlanta Intelligent Devices meetup, giving his talk Moving from Batches to Real Time with Apache Kafka. (Meetup)

Orthogonality on Orthogon Alley

  • Geometry term: two lines are orthogonal if they meet at right angles.
  • In software, two components are orthogonal if changes in one does not affect the other.
    • For example, changes to a database do not affect the UI and vice versa.
  • Nonorthogonal systems are more complex than orthogonal systems.

Tip

Eliminate effects between unrelated things.

Benefits of Orthogonality

  • Design components that are self-contained.
    • SINGLE, well-defined purpose. Remember SRP (the single responsibility principle)?
  • When components are isolated, you can change them without worrying about other components.
    • Obviously if you change the external interface, all bets are off.
  • A few primary benefits of writing orthogonal components:
    • There’s a productivity boost because changes are localized, making development and testing time greatly reduced.
      • Simple components are easier to design than complex, large components.
    • Promotes reusability because when you have simpler, well-defined components, they can be reused easily and maybe in unexpected ways.
    • There is a slight productivity gain when you use two orthogonal components together.

Orthogonality Reduces Risk

  • Bad code (or diseased code as the book calls it) is isolated.
  • The system is less fragile overall.
  • Orthogonal code promotes testability.
  • The system might not be as tied to any vendors because your coupling is in smaller, more well defined components.

Applying Orthogonality

Project Teams

  • How do you organize teams into well-defined responsibilities with little overlap? While there’s no one answer, the authors prefer to separate infrastructure from application (database, middleware, UI).
  • Measuring team orthogonality – the more people required to make a decision, the less orthogonal the teams are divided.

Design

  • Layers are only coupled to the abstractions below it.
    • If I change the requirements behind a particular function, how many layers would be affected? One should be the answer (although often not realistic).

Toolkits and Libraries

  • When working with 3rd party toolkits and libraries, isolate those libraries in your own code so that an update to the library shouldn’t require you to change the signature of your code or interfaces.
  • AOP (Aspect-oriented Programming) is a great example of orthogonal code. You can implement logging throughout your application without touching your code simply by applying aspects to your classes/namespaces.

Coding

  • Every time you write code you run the risk of duplication. This requires attention to the overall picture.
  • Keep your code decoupled. Remember the Law of Demeter.
    • Write “shy” code, don’t expose anything that needn’t be.
    • Object state changes should happen from the component being used, not your use of the component.
  • Avoid global data.
    • Sharing data globally causes problems. It is better to pass “shared data” into any component that depends on it.
      • By passing the “shared” data around rather than actually sharing it, this will also reduce tight coupling to any particular implementation.
    • Be careful about singletons. Don’t use them as global variables in disguise. Doing so creates tight couplings.
  • Avoid similar functions.
    • This usually indicates problems with the overall structure.
    • Look into using a strategy pattern, template method pattern, or others.
  • Be willing to refactor your code. Be purposely critical for improving orthogonality and structure.

Testing

  • Typically orthogonal systems are much easier to test because the components are much smaller and more focused.
  • Bug fixes are a good way to identify the orthogonality of the system as well: Does a simple change fix everything, or do you have to sprinkle changes throughout the code base.
  • Analyze trends to identify the number of files modified for each bug fix.

Documentation

  • With orthogonal documentation you should be able to change the look without changing the content.

Living the Orthogonal Dream

  • Developing orthogonal and DRY components makes for more flexible, testable, understandable, and easier to debug systems.

Reversibility

  • Engineers tend to like objective solutions to a problem, like 10 > 7.
  • Most problems aren’t that easy though. Often the solutions we come up with aren’t binarily right or wrong.
  • As you make decisions, you commit to a smaller target.
  • The more critical decisions you make, the smaller the target for success becomes.
  • As the target gets smaller, it becomes easier to miss.
  • If you are inflexible to change, a snag with any of those decisions can be a snag for the whole project.
    • Many things can change: requirements, pricing, new versions, etc. If you’ve fully committed to your technology choices then you can be put in a bad spot.

Tip

There are no final decisions.

Flexible architecture

  • You need to keep your code AND your architecture flexible.
  • Poor encapsulation, high coupling, hard-coded logic/parameters reduce flexibility.
  • Try to make all your decisions reversibile.

Resources We Like

Umm, what?

Tip of the Week

  • MDX Deck – Use React’s JSX inside markdown inside a presentation.
    • Includes presenter mode, notes, and short-cuts.
    • Dave Follett wrote a nice getting started guide: Learning MDX Deck: Getting Started (dev.to)
  • Fortunately for us, someone printed out the various encodings to answer URL Encoding using C#. (Stack Overflow)
  • CSS Zen Garden – See the beauty of CSS design.
  • Learn Kubernetes Basics (kubernetes.io)
  • kubectl Cheat Sheet (kubernetes.io)

Episode source