Category Archives: Programming

The Importance of Leverage

I first read this in James Clear’s 3-2-1 Newsletter, but thought the idea from Naval Ravikant was so good that I just had to share…

Humans evolved in societies where there was no leverage. If I was chopping wood or carrying water for you, you knew eight hours put in would be equal to about eight hours of output. Now we’ve invented leverage… As a worker, you want to be as leveraged as possible so you have a huge impact without as much time or physical effort.

A leveraged worker can out-produce a non-leveraged worker by a factor of one thousand or ten thousand. With a leveraged worker, judgment is far more important than how much time they put in or how hard they work.

For example, a good software engineer, just by writing the right little piece of code and creating the right little application, can literally create half a billion dollars’ worth of value for a company. But ten engineers working ten times as hard, just because they choose the wrong model, the wrong product, wrote it the wrong way, or put it in the wrong viral loop, have basically wasted their time. Inputs don’t match outputs, especially for leveraged workers.

What you want in life is to be in control of your time. You want to get into a leveraged job where you control your time and you’re tracked on outputs.

The Almanack of Naval Ravikant
Like this? Consider joining my mailing list, or at least using my affiliate link when buying from Amazon ๐Ÿ™‚

You or someone you know looking to buy or sell?
Disclaimer: Thoughts and opinions are my own, and do not reflect the views of any employer, family member, friend, or anyone else. Some links may be affiliate links, but I don't link to anything I don't use myself. You would think this should be self evident these days, but apparently not...

ArchConf 2020

Last week I had the opportunity to “attend” ArchConf (virtually). Of the sessions I attended, Venkat Subramaniam’s presentation of “Building Evolutionary Architectures” was easily the best and combined an engaging and enthusiastic style with useful content. David Sietz’s “Data as a Service (DaaS)” presentation was also very good and applicable for my needs. Aside from that, Joshua Smith and Laine Minor from RedHat were probably the most entertaining/fun/funny.

If you’re interested, here are my notes for each session I attended and took notes for :). Replays (for attendees only)

Architecting Cloud Native Applications

Nathaniel Schutta – 3/5

Main Takeaway: In order to successfully implement micro-services they must have consistent/good monitoring

Paved Roads – Architecting for Distributed Teams

Nathaniel Schutta – 4/5

Main Takeaway: Any alert someone gets should be informative and actionable. Otherwise, put it on a dashboard or report.

  • Even when we’re in person we’re still communicating remotely (sending IMs, Texts, etc)
  • Fitness function = todo list from arch to devs
  • Review boards don’t work!
  • Just because we can measure it does NOT mean it matters
  • If everything is an option, nothing is an option
  • Look into spring cloud contract
  • Temporal fitness function = essentially a reminder (ex: Review this code in 1 year)
  • Keep track of non-decisions/non-goals too (i.e. we don’t care about X because…)
  • Fitness functions should be visible and reviewed at least annually.
  • If you’re going to get an alert it needs to be informative AND actionable. Just informative goes on a dashboard or report.
  • Look into building a “radar”
  • thoughtworks.com/radar

To Hug or to Strangle: Tips for Dealing with Monolith Pain

Laine Minor & Josh Smith – 3/5

Main Takeaway: Consider “hugging” (applying micro-service best practices) legacy apps that are too big to strangle

  • pain = the thing that prevents you from doing the part of your job you came/want to do
  • pain = mental load of things you know are not as they should be
  • You get an architecture whether you plan for it or not
  • Long time between delivery is a BUSINESS problem
  • Biggest benefit of microservices is clean lines
  • Option 1: strangle, then hug
  • Option 2: hug, then strangle
  • Hugging = applying microservice best practices to a monolith (monitoring, etc)

Developer To Architect

Nathaniel Schutta – 3/5

Main Takeaway: Review boards and heavy handed governance doesn’t work.

  • Consequences can be positive and negative
  • Maximizing one minimizes another
  • Governance in most orgs is heavyweight, high ceremony… and it does NOT work
  • SLA vs SLA. The A matters and it indicates a consequence. If there is no consequence its an SLO (Objective)
  • A reform most often advances via indirection
  • It’s not just about the tech. It’s the relationships
  • Portfolio architect provides high-level architectural and software engineering expertise to managers and technical staff.
  • Domain architect : the way he describes it is essentially what we describe as a digital architect
  • Specifically mentioned TOGAF as a “meh” certification

Sifting Technologies – Separating the Wheat From the Chaff

Nathaniel Schutta – 3/5

Main Takeaway: Consider implementing architectural briefings

  • Education isn’t something you finish
  • Attention is like real estate. they’re not making any more of it.
  • Architectural briefing: why, how, where should/n’t we use
  • Not just how much does the thing cost, but how much does it cost to use it (dev, maint, hardware, etc)?
  • Speed reduces risk
  • There’s a difference between a dead tech vs a mature one
  • Developers are like cats. They’ll push back just on principle.

Building Evolutionary Architectures

Venkat Subramaniam – 5/5

Main Takeaway: Postpone decisions until the last possible moment because it’s possible YAGNI and doing so lessens the considerations for reversibility. Keep all code as simple as possible.

  • UFD = Up Front Design
  • Now that we’re “Agile” we’re not doing enough UFD (nor big UFD)
  • Power point architects = dangerous
  • Scrum master was never intended to be a title, else there’s no such thing as a self organizing team
  • “adaptive planning” and “feedback driven development” are the most important words for Agile
  • Rate all features/stories by business value and architectural impact
  • Goal should be delivering value. Not using a particular tech.
  • People confuse unfamiliar w/ complex
  • People confuse familiar with simple
  • reversibility = the ability to back out of a decision (less expensive)
  • postpone decisions until the last responsible moment
  • YAGNI = You Aren’t Gonna Need It
  • parsimony = the most minimal solution. Ask “do we have to” for everything
  • triangulate = implement 1 way, then another, and abstract common code to Base class
  • Don’t START with an abstraction. Refactor into it.
  • Postel’s law = be generous about what you receive and conservative about what you send
  • Good reuse comes from repeated active use
  • Be ruthless in minimizing dependencies including libraries and frameworks
  • http://www.agiledeveloper.com/downloads.html

Core Software Design Principles

Venkat Subramaniam – 4/5

Main Takeaway: Have the courage to postpone doing things, and when you do, keep it DRY

  • DRY = don’t repeat yourself
  • Violating DRY results in duplication of effort, not just duplication of code
  • Manual testing is a violation of DRY
  • Manual deploy is a violation of DRY
  • Effort: now > later -> postpone, now == later -> postpone, now < later -> eval probability of needing it
  • We need to have the courage to postpone doing things
  • SRP = single responsibility principle
  • SLAP = Single Level of Abstraction Principle
  • Then use the Compose Method Pattern to combine same level SLAPs
  • OCP = open close principle
  • Software modules (functions, classes, etc) must be open for extension but closed from modification
  • LSP = Liskov Substitution Principle
  • Inheritance should only be used for substitutability and not for reuse
  • DIY = Dependency Inversion Principle -> class should not depend on another class. Both should depend on abstraction or interface.

Cloud Integrations and Data Architecture for Enterprise Applications

Rohit Bhardwaj – 3/5

Main Takeaway: The API should come first. Or, when implementing an API for an existing implementation, don’t model the API on the internal workings of the system.

  • Application EA -> define our objects, what things they are part of, and the relationships between them
  • Applications interact with domains and data flows between them
  • Orchestration services should always queue requests and process/respond async
  • Lambda is basically serverless (functions)
  • You might consider using topics/queues for each service instead of load balancer
  • https://github.com/robertmrk/docker-cometd-demos
  • Check out CometD
  • Use a correlation id to sync across systems
  • API comes first! Then the implementation.
  • schema.org
  • MDM data cleansing: normalize data formats, replace missing values, standardize values, map attributes
  • Identify sources (producers and consumers of master data) -> collect and analyze metadata -> appt data stewards -> implement data gov program and council -> dev MD model and choose toolset -> Design infra, generate and test MD -> Modify producing and consuming -> implement maint process

Modeling for Architects

Nathaniel Schutta – 2/5

Main Takeaway: The value in the artifact is not in the artifact itself. It’s in the conversation it facilitates.

  • If the team can’t understand it, they can’t build it
  • It’s ok to throw out or deprecate a diagram
  • The value in the artifact is not in the artifact itself. It’s in the conversation it facilitates.
  • Component diagrams, deployment diagrams, and sequence diagrams are most common

Architectural Awareness: Engineering Super-skill

Ken Sipe – 3/5

Main Takeaway: Question everything. Don’t be afraid of a little chaos or of making mistakes

  • Hardest part of architecting is being aware
  • awareness = awareness or perception of a fact
  • chaos breeds creativity
  • Dryfus model: novice, advanced beginner (most people in IT industry), competent, proficient, expert
  • you get what you tolerate
  • shame and fear are toxic
  • We shouldn’t loosely couple everything. We should have it in the right places.
  • Team strengths: empathy, vulnerable/humble, collaborate/communicate, ability to share vision.
  • Is your process intentional or not?
  • “scrum but…” = I want all the benefits but don’t want to pay for it
  • Why are we doing ..x..? Should we do something else? Is it working?
  • context matters… and context could be foreign
  • embrace inconsistency
  • dependencies matter
  • it’s a mistake to worry too much about scalability from the start, but also to not think about it at all.

Architectural Resiliency

Jeremy Deane – 4/5

Main Takeaway: Need to have ownership to have accountability, and ownership needs to be end to end.

  • Threat Modeling book
  • openmastery.org
  • promote accountability/ownership. No orphans
  • Correlate activities. use a tracking id/correlation id
  • Do synthetic transactions
  • Look into “data dog” for dashboarding
  • Cloud hosting should be multi-region
  • Security Resiliency: Secure by default, defense in depth, least privilege
  • Event sourcing
  • Postel’s Law – Be conservative in what you send, be liberal in what you accept
  • Bulkheads. Limit failure exposure.
  • Validate your input. Sanitize your output.
  • Need to have end to end ownership
  • https://prezi.com/mb-vcfp-cry8/architectural-resiliency/

Architectural Trade-offs

Jeremy Deane – 4/5

Main Takeaway: Be aware that there’s a trade off (negative) to any choice you make.

  • RBAC = Role Based Access Control (ex: AD, Prism)
  • ABAC = Attribute Based Access Control (context based policies. ex: location based, etc)
  • Feature Toggles tend to result in technical debt
  • Blue green results in unnecessary releases
  • orchestration causes coupling and dependencies
  • choreography has complexity and needs monitoring
  • Need to understand the requirements and your domain!
  • Cloud providers tend to be “sticky”. Hard to get out of.

How to Technology Good – Tips for Implementation at Scale

Laine Minor & Josh Smith – 2/5

Main Takeaway: For good or bad, metrics (or data if you prefer) are needed to promote any tech

  • Metrics help build understanding, certainty, and trust
  • Until you have metrics it’s a non-starter

Data as a Service (DaaS)

David Sietz – 5/5

Main Takeaway: Publish data changes to your topics, have microservices consume the data as needed, and version as necessary.

  • Data model changes are expensive
  • Use a NoSQL db
  • Version all data coming in
  • Provisioning data: real time, self guided flow, variable load, parallel
  • Publishing data: real-time, variable endpoints, variable load, managed access
  • Use a business lens: risks, rewards, volatility
  • ROI is not always monetary
  • Last Responsible Moment (LRM)
  • There’s nothing wrong with copying data as long as you understand the intent and retention
  • Build your data marts at the last responsible moment
Like this? Consider joining my mailing list, or at least using my affiliate link when buying from Amazon ๐Ÿ™‚

You or someone you know looking to buy or sell?
Disclaimer: Thoughts and opinions are my own, and do not reflect the views of any employer, family member, friend, or anyone else. Some links may be affiliate links, but I don't link to anything I don't use myself. You would think this should be self evident these days, but apparently not...

The Day We Stopped Sprinting

An interesting take on a different approach to Agile.

“We get better results faster when we help new agile teams begin with a flow-based approach rather than sprints.”

https://www.linkedin.com/pulse/day-we-stopped-sprinting-joshua-kerievsky/Like this? Consider joining my mailing list, or at least using my affiliate link when buying from Amazon ๐Ÿ™‚

You or someone you know looking to buy or sell?

Disclaimer: Thoughts and opinions are my own, and do not reflect the views of any employer, family member, friend, or anyone else. Some links may be affiliate links, but I don't link to anything I don't use myself. You would think this should be self evident these days, but apparently not...

Stevey’s Google Platforms Rant

I don’t recall how this gem of an article came to my attention recently, but even though it is now 8 years old it is still amazingly relavent. If you are at all invovled in writing software I would strongly encourage reading this and taking it to heart.

https://gist.github.com/chitchcock/1281611Like this? Consider joining my mailing list, or at least using my affiliate link when buying from Amazon ๐Ÿ™‚

You or someone you know looking to buy or sell?

Disclaimer: Thoughts and opinions are my own, and do not reflect the views of any employer, family member, friend, or anyone else. Some links may be affiliate links, but I don't link to anything I don't use myself. You would think this should be self evident these days, but apparently not...

Selling the Investment to Pay Down Technical Debt: The Code Christmas Tree

I meant to post this over the holidays, but still think it’s relevant. Personally, I like the prominent visual aspect of the idea.

Selling the Investment to Pay Down Technical Debt: The Code Christmas Tree | Agile AllianceLike this? Consider joining my mailing list, or at least using my affiliate link when buying from Amazon ๐Ÿ™‚

You or someone you know looking to buy or sell?

Disclaimer: Thoughts and opinions are my own, and do not reflect the views of any employer, family member, friend, or anyone else. Some links may be affiliate links, but I don't link to anything I don't use myself. You would think this should be self evident these days, but apparently not...

Yes, Cross-functional Teams โ€” but Real Ones!

As we work through the process this seemed pertinent (emphasis is mine)…

The next leap is bringing these different units together (not only through the interface of the Product Owner) to form teams that are actually as knowledgeable about business, contracts, mathematics, sales, marketing, and everything else that is relevant for the companyโ€™s value stream as they are in software. For the Scrum teams, the leap means that they canโ€™t โ€œhideโ€ behind their backlog or the Product Owner and need to explore and learn about the market, their customers, and the companyโ€™s value stream themselves. Basically it means that now the Agile teamsโ€™ focus is beyond software.

Yes, Cross-functional Teams โ€” but Real Ones!Like this? Consider joining my mailing list, or at least using my affiliate link when buying from Amazon ๐Ÿ™‚

You or someone you know looking to buy or sell?

Disclaimer: Thoughts and opinions are my own, and do not reflect the views of any employer, family member, friend, or anyone else. Some links may be affiliate links, but I don't link to anything I don't use myself. You would think this should be self evident these days, but apparently not...

Including the version in a Maven artifact

Recently I wanted to include the version of an artifact generated by a Maven build into a text file in that artifact. As Google and and good friends will help you with, I was pointed to this article that was exactly what I wanted.

Basically, create a /src/main/resources/version.txt file with the following content…

${project.version}

… then including the following snippet in your “build”…


<build>
  <resources>
    <resource>
      <directory>src/main/resources</directory>
      <filtering>true</filtering>
      <includes>
        <include>**/version.txt</include>
      </includes>
    </resource>
    <resource>
      <directory>src/main/resources</directory>
      <filtering>false</filtering>
      <excludes>
        <exclude>**/version.txt</exclude>
      </excludes>
    </resource>
  </resources>
</build>

Like this? Consider joining my mailing list, or at least using my affiliate link when buying from Amazon ๐Ÿ™‚

You or someone you know looking to buy or sell?

Disclaimer: Thoughts and opinions are my own, and do not reflect the views of any employer, family member, friend, or anyone else. Some links may be affiliate links, but I don't link to anything I don't use myself. You would think this should be self evident these days, but apparently not...

Lean or Agile? Why choose when you can have it all? The power of applying Agile with a Lean mindset

Interesting article. I have the book queued up for perusal. If you have a subscription to Safari Books you can read it too!

Lean or Agile? Why choose when you can have it all? The power of applying Agile with a Lean mindsetLike this? Consider joining my mailing list, or at least using my affiliate link when buying from Amazon ๐Ÿ™‚

You or someone you know looking to buy or sell?

Disclaimer: Thoughts and opinions are my own, and do not reflect the views of any employer, family member, friend, or anyone else. Some links may be affiliate links, but I don't link to anything I don't use myself. You would think this should be self evident these days, but apparently not...

All Code Is Bad, So Don’t Stress If Yours Sucks

Some funny for my developer friends. If you don’t program for a living, just ignore everything in these articles because you will become convinced the world will implode shortly. On the other hand, if you do program I’m pretty sure you’ll love this…

Read the full article here, or… check out the summaryLike this? Consider joining my mailing list, or at least using my affiliate link when buying from Amazon ๐Ÿ™‚

You or someone you know looking to buy or sell?

Disclaimer: Thoughts and opinions are my own, and do not reflect the views of any employer, family member, friend, or anyone else. Some links may be affiliate links, but I don't link to anything I don't use myself. You would think this should be self evident these days, but apparently not...

Remove Duplicate Lines in Notepad++

If you’ve ever had the need to remove the duplicate lines from a long list of entries like so…

hi
bye
hi
guy
bye
hi

… and are looking for this…

hi
bye
guy

You can use the find/replace feature in Notepad++ to do it if you use the regex funcationality. Here’s the find string…

^(.*?)$\s+?^(?=.*^\1$)

Just replace with a zero length string.

If you’d like to read up on the details I found this tip hereLike this? Consider joining my mailing list, or at least using my affiliate link when buying from Amazon ๐Ÿ™‚

You or someone you know looking to buy or sell?

Disclaimer: Thoughts and opinions are my own, and do not reflect the views of any employer, family member, friend, or anyone else. Some links may be affiliate links, but I don't link to anything I don't use myself. You would think this should be self evident these days, but apparently not...