On Monday morning, Jimmy pulls up in front of Starbucks at 8:16 am on his way to work. He decides to forgo paying for parking. It only costs $0.25 / 15 minutes but the hassle of navigating the parking app on his phone isn’t worth it.  "I'll only be a few minutes," he reassures himself. After ordering his favorite drink and paying $6.38, Jimmy patiently waits for his name to be called. “A venti caramel latte for Timmy,” someone yells. Eight minutes later, he heads back to his car and drives off. The following days, Jimmy repeats this routine. However, on Thursday, as he leaves the store, his heart sinks when he notices an orange envelope placed on his windshield—a $60 parking violation ticket.

It’s not uncommon for companies that build new products to cut corners in areas where they should aim to raise the bar. Instead, they put their energies into building more feature rich products, a strategy that increases execution risks, and hurts the company’s short and long term chances of success.

I would like to argue that there are three reasons why.

1. Leadership may lack experience in building products in a lean, and agile way. Building a strong culture is an absolutely essential ingredient but it may not be enough. It is considerably more complex to build a team that can establish really strong engineering, operational, and data-driven strategic disciplines that are designed for scale. It requires leaders with enthusiasm and ability to articulate their vision, but also equipped with the hard skills to be able to steer the technical strategy towards the right direction.
2. The product in question is just not mission critical for the company, both in potential value as well as investment risk. If the product fails to deliver, it doesn’t mean the company fails. The company knows what it needs to do to maximize the chance of success but it intentionally chooses to divert its investments into its top priorities, making a calculated bet.
3. While (1) or (2) represent a small number of orgs, a mix of (1) and (2) (lack of experience combined with prioritization challenges) describes a 2-D plane where most companies that build products are fighting their daily battles. In this place, it isn’t always quite clear if one decision is better than another and progress can be difficult. Companies are also constantly moving up/down and left/right on this plane as they battle competition, an ever-changing workforce, and a fast evolving tech ecosystem.

There are ways to steer the ship more towards a successful destination by first recognizing and understanding that some easy-looking strategies are not always the most successful ones. Examples:

• Funding a team to "go away somewhere" and come back with a product ready for launch in 10 months is rarely the right strategy for building many products. Instead, a team should be tasked with bringing a much smaller version of that  product to a limited number of customers much sooner so their feedback can help inform/adjust the strategy. This is just the Agile philosophy at work.
• Deprioritizing necessary infrastructure and processes such as having proper end to end deployment automation and rollback, collaborative tooling, automated security, increases daily toil, dampens collaboration, and kills innovation. These things may be not very exciting to build but they are critical in maintaing velocity as the product scales and the team grows.
• Not setting a high enogh bar for the quality of the system design, the written code, the testing tools and release processes, not establishing the means for tracking key success/failure metrics – these directly impact the product quality and set an upper ceiling for hiring and retaing the tech talent that becomes very difficult to raise later without a significant shift in strategy and investment.
• Underinvesting in the customer support experience by not creating an operationally mature, cross-functional culture where everyone in the company feels responsible for the customer outcomes, a culture where everyone understands the importance of reacting to customer issues swiftly, thoughtfully, and proactively working to improve them.
• Underinvesting in building data “eyes” into an active product from the very beginning and as part of the implementation strategy. Leading a product that lacks data analytics, operational and technical metrics is a lot like flying an airplane through clouds with navigational instruments turned off.
• Not consistenly reviewing and updating the execution strategy on a regular basis so it can be frequently course-corrected for what is being learned through each iteration and customer feedback.

Recently, I began practicing guitar more regularly after a nearly 14 year practicing hiatus and I wanted to share some of those routines. In this post I will cover some fundamental arpeggios which are an excellent mechanism for building up fluidity across the fretboard.

While typical arpeggio patterns you may have seen focus on common triadic shapes, I want to focus on 7th chord 2-note per string patterns that are repetitive and can easily expand diagonally on the fretboard.

I typically categorize them by chord family, flavor, and length.

• Chord Families: Major, Dominant, Minor, Diminished
• Chord Flavors: flattened fifth (b5), sharpened or augmented fifth (#5)
• Length: ~2.5 octaves and ~3+ octaves (requiring a jump somewhere)

Generally, I focus on two types of patterns for each chord/flavor/length: arpeggios beginning on the lower E string, and arpeggios that begin on the A string. These end up hitting different paths in the fretboard, even though they share common shapes.

In either case, I follow a personal rule for the 3-octave arpeggios - they should aim to expand on the D string whenever possible (i.e. it requires playing 2 notes followed by a jump on the same string and then playing 2 more notes higher). The reason is simple: the D string is preceded and succeeded by strings tuned in 4ths and therefore there are no odd pitch shifts happening right after the expansion, as would be the case with the G string followed by B, a major 3rd up. I also try to avoid these jumps in the B and E strings as they have notes in the melody register and expansions are more challenging to execute in a seamless way. Lastly, I avoid the lower E, and A strings because of their low registers and intonation issues with these types of transitions. Overall, using the D-string tends to make lines more fluent and opens up possibilities in improvisation.

I specifically pay a lot of attention to the altered fifth versions of each chord as well as the diminished scale. These are not exotic flavors but they play a fundamental role in functional harmony. For example a Major 7 b5 arpeggio outlines the Dom 7 chord a whole step above it, a Minor 7 b5 arpeggio outlines the Dom 7 chord a major third below it, and so on.

Below are the patterns shown in the video.

E-String Patterns

G Major 7

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|_1_|___|___|_4_|___|___||___|___|___|___/
b  ___||___|___|___|___|___|___|_1_|_2_|___|___|___|___||___|___|___|___\
g  ___||___|___|___|_1_|___|___|_4_|___|___|___|___|___||___|___|___|___/
d  ___||___|___|___|_1_|_2_|___|___|___|___|___|___|___||___|___|___|___\
a  ___||___|_1_|___|___|_4_|___|___|___|___|___|___|___||___|___|___|___/
e  ___||___|_1_|_2_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|___|___|___|___|___|___||___|_1_|_2_|___/
b  ___||___|___|___|___|___|___|___|___|___|___|___|_1_||___|___|_3_|___\
g  ___||___|___|___|___|___|___|___|___|___|___|_1_|_2_||___|___|___|___/
d  ___||___|___|___|_1_|_2_|___|___|___|_1_|___|___|_4_||___|___|___|___\
a  ___||___|_1_|___|___|_4_|___|___|___|___|___|___|___||___|___|___|___/
e  ___||___|_1_|_2_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

G Major 7 b5

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|_1_|___|_3_|___|___|___||___|___|___|___/
b  ___||___|___|___|___|___|___|_1_|_2_|___|___|___|___||___|___|___|___\
g  ___||___|___|___|_1_|___|_3_|___|___|___|___|___|___||___|___|___|___/
d  ___||___|___|___|_1_|_2_|___|___|___|___|___|___|___||___|___|___|___\
a  ___||___|_1_|___|_3_|___|___|___|___|___|___|___|___||___|___|___|___/
e  ___||___|_1_|_2_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|___|___|___|___|___|___||___|_1_|_2_|___/
b  ___||___|___|___|___|___|___|___|___|___|___|___|_1_||___|_3_|___|___\
g  ___||___|___|___|___|___|___|___|___|___|___|_1_|_2_||___|___|___|___/
d  ___||___|___|___|_1_|_2_|___|___|___|_1_|___|_3_|___||___|___|___|___\
a  ___||___|_1_|___|_3_|___|___|___|___|___|___|___|___||___|___|___|___/
e  ___||___|_1_|_2_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

G Major 7 #5

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|_1_|___|___|___|_4_|___||___|___|___|___/
b  ___||___|___|___|___|___|___|_1_|_2_|___|___|___|___||___|___|___|___\
g  ___||___|___|___|_1_|___|___|___|_4_|___|___|___|___||___|___|___|___/
d  ___||___|___|___|_1_|_2_|___|___|___|___|___|___|___||___|___|___|___\
a  ___||___|_1_|___|___|___|_4_|___|___|___|___|___|___||___|___|___|___/
e  ___||___|_1_|_2_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|___|___|___|___|___|___||___|_1_|_2_|___/
b  ___||___|___|___|___|___|___|___|___|___|___|___|_1_||___|___|___|_4_\
g  ___||___|___|___|___|___|___|___|___|___|___|_1_|_2_||___|___|___|___/
d  ___||___|___|___|_1_|_2_|___|___|___|_1_|___|___|___||_4_|___|___|___\
a  ___||___|_1_|___|___|___|_4_|___|___|___|___|___|___||___|___|___|___/
e  ___||___|_1_|_2_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

G Dominant 7

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|_1_|___|___|_4_|___|___||___|___|___|___/
b  ___||___|___|___|___|___|_1_|___|_3_|___|___|___|___||___|___|___|___\
g  ___||___|___|___|_1_|___|___|_4_|___|___|___|___|___||___|___|___|___/
d  ___||___|___|_1_|___|_3_|___|___|___|___|___|___|___||___|___|___|___\
a  ___||___|_1_|___|___|_4_|___|___|___|___|___|___|___||___|___|___|___/
e  ___||_1_|___|_3_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|___|___|___|___|___|___||_1_|___|_3_|___/
b  ___||___|___|___|___|___|___|___|___|___|___|___|_1_||___|___|_3_|___\
g  ___||___|___|___|___|___|___|___|___|___|_1_|___|_3_||___|___|___|___/
d  ___||___|___|_1_|___|_3_|___|___|___|_1_|___|___|_4_||___|___|___|___\
a  ___||___|_1_|___|___|_4_|___|___|___|___|___|___|___||___|___|___|___/
e  ___||_1_|___|_3_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

G Dominant 7 b5

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|_1_|___|_3_|___|___|___||___|___|___|___/
b  ___||___|___|___|___|___|_1_|___|_3_|___|___|___|___||___|___|___|___\
g  ___||___|___|___|_1_|___|_3_|___|___|___|___|___|___||___|___|___|___/
d  ___||___|___|_1_|___|_3_|___|___|___|___|___|___|___||___|___|___|___\
a  ___||___|_1_|___|_3_|___|___|___|___|___|___|___|___||___|___|___|___/
e  ___||_1_|___|_3_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|___|___|___|___|___|___||_1_|___|_3_|___/
b  ___||___|___|___|___|___|___|___|___|___|___|___|_1_||___|_3_|___|___\
g  ___||___|___|___|___|___|___|___|___|___|_1_|___|_3_||___|___|___|___/
d  ___||___|___|_1_|___|_3_|___|___|___|_1_|___|_3_|___||___|___|___|___\
a  ___||___|_1_|___|_3_|___|___|___|___|___|___|___|___||___|___|___|___/
e  ___||_1_|___|_3_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

G Dominant 7 #5

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|_1_|___|___|___|_4_|___||___|___|___|___/
b  ___||___|___|___|___|___|_1_|___|_3_|___|___|___|___||___|___|___|___\
g  ___||___|___|___|_1_|___|___|___|_4_|___|___|___|___||___|___|___|___/
d  ___||___|___|_1_|___|_3_|___|___|___|___|___|___|___||___|___|___|___\
a  ___||___|_1_|___|___|___|_4_|___|___|___|___|___|___||___|___|___|___/
e  ___||_1_|___|_3_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|___|___|___|___|___|___||_1_|___|_3_|___/
b  ___||___|___|___|___|___|___|___|___|___|___|___|_1_||___|___|___|_4_\
g  ___||___|___|___|___|___|___|___|___|___|_1_|___|_3_||___|___|___|___/
d  ___||___|___|_1_|___|_3_|___|___|___|_1_|___|___|___||_4_|___|___|___\
a  ___||___|_1_|___|___|___|_4_|___|___|___|___|___|___||___|___|___|___/
e  ___||_1_|___|_3_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

G Minor 7

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|_1_|___|___|___|_4_|___|___||___|___|___|___/
b  ___||___|___|___|___|___|_1_|___|_3_|___|___|___|___||___|___|___|___\
g  ___||___|___|_1_|___|___|___|_4_|___|___|___|___|___||___|___|___|___/
d  ___||___|___|_1_|___|_3_|___|___|___|___|___|___|___||___|___|___|___\
a  ___||_1_|___|___|___|_4_|___|___|___|___|___|___|___||___|___|___|___/
e  ___||_1_|___|_3_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|___|___|___|___|___|___||_1_|___|_3_|___/
b  ___||___|___|___|___|___|___|___|___|___|___|_1_|___||___|___|_4_|___\
g  ___||___|___|___|___|___|___|___|___|___|_1_|___|_3_||___|___|___|___/
d  ___||___|___|_1_|___|_3_|___|___|_1_|___|___|___|_4_||___|___|___|___\
a  ___||_1_|___|___|___|_4_|___|___|___|___|___|___|___||___|___|___|___/
e  ___||_1_|___|_3_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

G Minor 7 b5

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|_1_|___|___|_4_|___|___|___||___|___|___|___/
b  ___||___|___|___|___|___|_1_|___|_3_|___|___|___|___||___|___|___|___\
g  ___||___|___|_1_|___|___|_4_|___|___|___|___|___|___||___|___|___|___/
d  ___||___|___|_1_|___|_3_|___|___|___|___|___|___|___||___|___|___|___\
a  ___||_1_|___|___|_4_|___|___|___|___|___|___|___|___||___|___|___|___/
e  ___||_1_|___|_3_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|___|___|___|___|___|___||_1_|___|_3_|___/
b  ___||___|___|___|___|___|___|___|___|___|___|_1_|___||___|_4_|___|___\
g  ___||___|___|___|___|___|___|___|___|___|_1_|___|_3_||___|___|___|___/
d  ___||___|___|_1_|___|_3_|___|___|_1_|___|___|_4_|___||___|___|___|___\
a  ___||_1_|___|___|_4_|___|___|___|___|___|___|___|___||___|___|___|___/
e  ___||_1_|___|_3_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

G Diminished

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|_1_|___|___|_4_|___|___|___||___|___|___|___/
b  ___||___|___|___|___|_1_|___|___|_4_|___|___|___|___||___|___|___|___\
g  ___||___|___|_1_|___|___|_4_|___|___|___|___|___|___||___|___|___|___/
d  ___||___|_1_|___|___|_4_|___|___|___|___|___|___|___||___|___|___|___\
a  ___||_1_|___|___|_4_|___|___|___|___|___|___|___|___||___|___|___|___/
e  _0_||___|___|_3_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|___|___|___|___|___|_1_||___|___|_4_|___/
b  ___||___|___|___|___|___|___|___|___|___|___|_1_|___||___|_4_|___|___\
g  ___||___|___|___|___|___|___|___|___|_1_|___|___|_4_||___|___|___|___/
d  ___||___|_1_|___|___|_4_|___|___|_1_|___|___|_4_|___||___|___|___|___\
a  ___||_1_|___|___|_4_|___|___|___|___|___|___|___|___||___|___|___|___/
e  _0_||___|___|_3_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

A-String Patterns

I couldn't cover these with another video due to time limitations.

C Major 7

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|_1_|_2_|___|___|___|___||___|___|___|___/
b  ___||___|___|___|___|_1_|___|___|_4_|___|___|___|___||___|___|___|___\
g  ___||___|___|___|_1_|_2_|___|___|___|___|___|___|___||___|___|___|___/
d  ___||___|_1_|___|___|_4_|___|___|___|___|___|___|___||___|___|___|___\
a  ___||___|_1_|_2_|___|___|___|___|___|___|___|___|___||___|___|___|___/
e  _0_||___|___|_1_|___|___|___|___|___|___|___|___|___||___|___|___|___\
                 o       o       o       o           o            o

    0    1   2   3   4   5   6   7   8   9   10  11  12   13  14  15  16
e' ___||___|___|___|___|___|___|___|___|___|___|___|_1_||___|___|_3_|___/
b  ___||___|___|___|___|___|___|___|___|___|___|___|_1_||_2_|___|___|___\
g  ___||___|___|___|___|___|___|___|___|_1_|___|___|_4_||___|___|___|___/
d  ___||___|_1_|___|___|_4_|___|___|___|_1_|_2_|___|___||___|___|___|___\
a  ___||___|_1_|_2_|___|___|___|___|___|___|___|___|___||___|___|___|___/
e  _0_||___|___|_1_|___|___|___|___|___|___|___|___|___||___|___|___|___\

I am going to leave it up to the reader to come up with patterns the rest of these arpeggios. When doing so, keep in mind three things:

• Try expanding them along the D string for reasons mentioned above
• Try substituting a 4th finger with a 3rd finger for any landing note above the 12th fret because frets are closer together in that region. When viable, 3 is usually easier to play than 4.
• Try maintain a 2-note per string pattern, even if sometimes it may lead to odd shapes and uncomfortable fingerings. I would argue that some of the clustered triadic shapes which are trivial to play really don't lend themselves well for expanding across the board without sacrificing line fluidity and range.

Keep in mind that this stuff works for me, it should generally work for others, but it may also not work for some. Ultimately you have to find a good balance between borrowing others' ideas and ideas that work well for you.

I hope this was helpful in some way and I welcome any feedback.

My kids love playing Roblox on their iPads. But they can only play on the weekends and they have a 2hr time limit per day. That’s a lot less time they want and my wife and I are in constant negotiations with them to extend their time limits.  So, recently, I gave them a new challenge. You want to spend more time on Roblox and even do something cool? How about learning to design and code your own games? They looovvvved the idea!

We’re in Week 2 and they are now using laptops, becoming comfortable with the Roblox Studio IDE (Roblox’ game building software), and they’re chipping away at learning the Lua programming language for game interactivity.

I thought the experience would be a steep learning curve but I was wrong. They “ditched” the concepts and “theory” that I tried to explain carefully and instead dove straight into the fun, learning by trial and error. With just a little guidance, and a whole lot of relentless persistence and hyperfocus, their young brains can seem to remember complex UI shortcuts and how to type entire code segments in an effortless way.

It has made me think about a couple of things.

We sometimes oversimplify things for the new generation, forgetting that with the right support and some thoughtful guidance/instruction they can learn at incredible speeds. Instead, we lower the entry barrier because it makes it easier for us to roll out a teaching process. But the slowdown drags out the learning process, diminishes the rewards, and often destroys the most important element of learning - the motivating factor. Of course, there are times when it is worth slowing things down in order to build a strong foundation but it doesn’t have to happen right away and it has to be balanced with reward in a dynamic way. It feels like we simply don’t have great mechanisms to do this at scale yet but at a smaller group level (family, friends, work team), we have more opportunities to do this better.

As adults, we have a harder time shutting off distractions when pursuing an idea we are passionate about. My kids easily ignored the non-relevant elements to deliver on their goal to build a game. But as adults, when we take first steps, we often begin questioning ourselves based on our experience, insecurities, and our appetite for risk-taking. Is my approach correct? Should I read a book first? Are we doing it wrong/is there a better way? What risks am I taking? What if I fail? Of course, some of these questions are critically important to answer but those are not the ones we always prioritize to answer first. We are as rational as our emotions afford us to be, and, ultimately, even though we know exactly how to succeed, we manage to drag ourselves through the more difficult and longer path. This also applies to groups of people with a common goal such as a team or organization.

Photo by Zdeněk Macháček on Unsplash

And so it begins: The Chromium team has announced that Chrome will begin to get a little Rust-y!

https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html

They now support a Rust tool-chain for third-party libraries by enabling inter-operation between it and Chromium's code-base, written in C++.

Why I think it matters: Chrome is by far the most popular browser with a 75%+ market share. Rust is a modern systems-level language that provides better security, performance, and results in better management of large+complex code-bases. The long-term move (and it would take a long time) towards Rust should make browsing experience safer and better for everyone.

Wait, is that it? No. Last year Linux kernel 6.1 also enabled support for Rust, another significant signal that perhaps there is a new technology in town that might rule the long-term future of everything digital? This technology could be safer, more performant, more energy efficient, and make technology more accessible at scale.

But, how do we get there?

In 2023, the world still runs on COBOL, a ~65 year old language. Some 250+ billion lines of code run our banks, hospitals, infrastructure, and the government. Decades later, we haven’t found a good way to replace COBOL with any of the dozen or so modern languages used today. The cost of that work is extremely high, and the effort is too dangerous. Imagine how much disruption an FAA system caused with just a few hours of downtime just a week ago.

Now, compare the COBOL bits with the code that runs the rest of our technology: every computer, phone, microwave, electronic toy, car engine, AI, robot, and the very browser with which I am typing this post. With some exceptions, all of it is/was built using C or C++, two very similar yet separate languages with some strong common roots and interoperability.

These languages have, too, been modernized over the years. The newest version of C++ for example, C++23, is actually a great language and if you ignore many of the older features it still supports for backwards compatibility, it is quite comparable to other popular technologies. But the older features are precisely what are being used to manage existing code-bases, like Chromium (Chrome’s foundational code-base) so those features are here to stay. Given the enormous scope, C/C++ also have very large and active communities who are innovating day by day to deliver the things that others build upon -- the foundations of all technology: operating systems, networking equipment, system programs, device controls, game engines, microcontroller programs, etc.

How do we absorb this cost as a society? Who’s got the money and the time to rewrite the world? Are the tradeoffs worth it? Are the benefits better than marginal gains? Does the strategy of enabling a little Rust in more projects really lead to a long-term transformation at scale without something much more fundamental? Does extreme automation via AI and ML in the near future perhaps enable this?

What do you think?

Note: This post is about distributed systems design

Contents

1. Introduction
2. An Example Problem
3. An Adaptive Design Solution
4. An Example Implementation
5. Results
6. Conclusion

1. Introduction

Today's distributed software systems are typically designed with just enough complexity to satisfy basic functional requirements. This approach makes sense because a simple initial design means shipping a product faster and cheaper, therefore reducing the short-term risk to market.

But for products designed for hyper-growth, non-functional requirements like performance and resource costs could become functional requirements at scale. And while performance related to internal design choices are easier to address down the road, it is those that depend on external factors such as vendors that may not become obvious until sometime later. That is why it is extremely important to invest in evaluating, benchmarking and testing external factors with more scrutiny as part of the discovery phase and before major dev investment has begun. Once identified, these cases may require thinking about an elastic design up-front as a way to scale product down the road.

There's a great talk by now-retired C++ expert, Scott Meyers, where he beautifully explains how Donald Knuth's famous quote "...premature optimization is the root of all evil.." has often been relayed by leaving out some crucial context. The quote was meant for the little optimizations in a system, not foundational system design.

2. An Example Problem

Let's illustrate this with a fictional problem. A team builds a software product consisting of an App and its backend API. The product will allow users to fetch the current balance of a digital wallet on demand so they can make a real time decision about something they want to buy.

In order to fetch the wallet balance, the API must forward the request to a vendor's API which provides wallet access. In this scenario, the vendor is really the "server" and the client API is mostly a proxy.

Initial user experience studies show that most users will check their balance at lunch time and after work. Peak days will be Thu, Fri, and Sat. This means the largest number of API requests, and therefore, vendor API activity will also vary over time.

In addition, the product team concludes that the quality of user experience will be driven by two important factors:

• UI speed - which depends on vendor response time. Obviously, the client can cache server responses but won't solve for the next factor...
• Data accuracy - which depends on vendor's ability to resolve on-demand requests reliably

The product team projects technical benchmarks and speaks with the vendor which assures the team that the service will deliver what they need. Here's a recap of what the fictional contract looks like.

SLA Contract With Client. Vendor guarantees to

• support up to 100 client concurrent requests 99.95% of the time
• deliver a response time of 20ms for 99.95% of all client requests
• successfully respond to 99.95% of all valid client requests

Great. The team implements the integration and is ready to go to market. Then reality sets in. As the number of users grows, the team notices that the SLAs aren't always observed. The problem starts to get worse as the product becomes more popular. Certain user segments are hit even harder for unknown reasons.

After a lot of back and forth with the vendor, the team realizes that the vendor won't be able to deliver better results anytime soon. Moving to a new vendor won't be possible at this stage as it is a strategic move that will require restarting a complex negotiation process and a new technical implementation, and a migration process that may take years.

3. An Adaptive Design Solution

One potential solution would be to loosen up the synchronous and static design of the system and introduce a few components starting from the vendor to the user:

• A forward proxy to act as a broker between the two parties. Aside from transparent communication to and from the server, implementing basic resiliency patterns (i.e. simple retry, timeout circuit breakers, or even fallbacks to local caches for certain cases), the proxy's other important role is to provide telemetry to the client about the server's performance.
  
• A client which will own the communication strategy with the vendor
  
• A queue which will act as ephemeral storage for queuing requests
  
• A producer service which is responsible for brokering requests for the API. It allows the API to focus on serving the App while producing requests to the client on its behalf.
  
• A telemetry solution not shown for simplicity. Instead the dotted arrows show the feedback loops enabled by this telemetry.

3.1. The Approach

Let's start with a workbench test. First, we will simplify the system by temporarily ignoring the App and the API and focus on the producer which can be artificially configured to continuously generate requests that are uniformly distributed at R_API=max measured API traffic (requests for second). This will ensure that traffic peaks are covered. In this context, the producer is greedy: I must produce at R_API rate at all times and at all cost. I will also accept anything within the range [min, R_API] if necessary but I will continue pushing for R_API over time. I won't give up.

Second, let's develop a client that is smart enough to negotiate with the producer: ok, I will help you, producer, but I will let you know when you might want to slow things down or speed things up. I will take care of the rest.

Third, let's implement a queue which will provide a back-pressure absorbent layer between the client and the producer so that shockwaves from the vendor server never reach the API. We'll assume the queue in this example has much higher throughput than the production rate R_API.

Finally, what is left is to figure out how to implement the smart client. Let's just consider the three SLAs being broken one at a time.

3.1.1. Scenario 1: Changes to server rate or concurrent requests limits

Server and concurrency limits should not have any effect on the client system as long as server rate R_s and server concurrency rate P_s  (P for pool size) are such that

P_API << P_s and R_API << R_s

Otherwise, the server will begin responding to impacted requests with a typical 429/TooManyRequests response code. (Remember we are using simple HTTP for this example). The client must put these requests back to the queue for reprocessing and then signal the producer to slow down if re-enqueuing reaches a threshold. Given, the client doesn't know what the new viable rate must be, the feedback for the producer is intentionally open. The producer then lowers the ceiling of the [min, R_NEW]  where

R_NEW = 0.75 x R_API

It continues lowering the rate recursively until the client's feedback is no longer negative. The producer must also memorize the new ceiling R_NEW and attempt to raise it at a less frequent interval given that client signal is positive, following an exponential curve that will continuously approach R_API again. This is important to help the producer to make but continuous changes to its production plan rather than reacting dramatically to feedback which can result in calibrating difficulties for the producer-client operation.

3.1.2. Scenario 2: Changes to response time

The way to make up for lost time per request is to send more requests in parallel, thus increasing computational costs. Little's Law can help figure out how many. It says that, given a stationary system

L = λW                 where

L - is long-term average of number of customers in a stationary system
λ - is the long-term average effective arrival rate
W - is the average time the customer spends in the system

Note a couple of important things. This formula talks about averages. This formula isn't computer-science specific. It may as well apply to people waiting to enter a large football stadium with multiple lines and gates. We can redefine it to fit our problem.

a customer is a client request
arrival rate is production rate
time spent in system is request time

then we can rewrite the relationship above as

P_API = R_API T

where

P_API - avg # concurrent requests which defines a client "thread" pool size P *
R_API - the average production rate
T - the response time that includes server, proxy, and client time

* Given our scale context, it's likely by "thread" here we mean a type of virtual thread. We are talking about potentially hundreds or even thousands of threads on a web server which are only possible using reactive/async solutions and not native threads. In the implementation example below I have used goroutines to achieve and control concurrency for this purpose.

With this approach we have enabled a way to increase the number of concurrent threads to P_API maintain R_API as long as P_API << P_s from scenario 1 is true.

3.1.3. Scenario 3: Changes to response success rate

An accumulator on the client tracks request failure count. If this average rises above a critical predetermined threshold, the client can do a few things:

• can alert the producer to slow down, just like in scenario 1, because the root cause of functional issues is often related to saturation-related conditions
• alert the team (this is where manual intervention is finally needed)
• retry the failed requests by re-enqueueing and serve cached data along with proper messaging for the user

4. An Example Implementation

How does this type of design work in practice? How can one build such a system?

For demo purposes I implemented a distributed system example with Golang so that I could take advantage of Goroutines, a type of lightweight virtual thread solution that comes with the native Go runtime. However, similar implementations can be delivered with other reactive/async architectures in any technology stack. This solution spins up several services which are already pre-configured to talk to one another on localhost.

You can find the entire source code here: https://github.com/georgetheka/adaptive-architecture

In order to test the system just build and run using this steps:

make install
make build
make run

In order to stop the system use:

make stop

For more details see the README file:

adaptive-architecture/README.md at main · georgetheka/adaptive-architecture

Contribute to georgetheka/adaptive-architecture development by creating an account on GitHub.

GitHubgeorgetheka

5. Results

Fig. 1 shows a the stable system running with the following characteristics:

Producer Rate: R_API = 100 requests / second
Thread Pool Size: P_API = 10 (goroutines)
Response Time AVG: T = 100ms

The actual production rate is about 85 requests / second. It means the system is working at about 85% efficiency due to some loss in synchronization and optimization.

5.1. Scenario 1: Changes to server rate or concurrent requests limits

What if the rate limit suddenly dropped below the level agreed upon, to say only 50% of the required rate? We can reduce the rate in half by calling this endpoint:

curl http://localhost:7777/reduceratelimit

and then we can increase the rate limit by calling this endpoint:

curl http://localhost:7777/increaseratelimit

The client notices that too many requests are being returned due to the low rate limit and it absorbs the back-pressure from the server by re-enqueuing the events and notifying the producer to slow down. Producer then slows by guessing a lower rate limit and over time continues to adjust its rate up or down based on the client input. Once the client signals that the server rate limit stabilizes, the producer gradually increases the throughput to match the desired state. At the same time, the client scales down resources as well to re-achieve equilibrium state.

5.2. Scenario 2: Changes to response time

Next, let's simulate a server slowdown by forcing the server to double the response time each time the following server endpoint is called.

curl http://localhost:7777/slowdown

A few moments later, the system finds a new equilibrium point maintaining consistent throughput at the previous efficiency level but having acquired more resources (number of parallel workers) therefore at a higher but optimal cost for the new conditions. Notice the new pool size has self adjusted from 10 to 100 (in actuality ~90).

Now, let's speed up the vendor system again. The following endpoint will cut the response time in half for every call. The system will then respond by recalibrating itself by reducing number of resources back to minimal levels.

curl http://localhost:7777/speedup

5.3. Scenario 3: Changes to response success rate

The client is observing the number of failures and once a certain threshold is reached several things can happen:

• an alert is sent to the team (not implemented)
• the producer can be alerted to slow down (not implemented)
• errors can be re-enqueued for a second try (not implemented)

Increase the probability of requests to fail randomly and uniformly using the following endpoint:

curl http://localhost:7777/control?percentage_reqs_fail=20

5.2. Wait one second

Hold on. I understand that the dynamics between the client <> producer are now changing to automatically adapt to the new conditions. But how does this translate to an improved user experience? For this to happen, additional infrastructure would be needed, not shown in the design. For example, an additional memory cache would be required to track the open state of not-yet-fulfilled app requests. The app itself will need the ability to switch between a sync and an async + polling strategy with an exponential backoff pattern once the API response indicates the result will be delayed. For most active users, an LRU cache could feed a background process that continuously requests and updates info ahead of time.

6. Conclusion

This example strives to demonstrate some ways to design distributed systems that can adapt their performance against external factors when operating at the desired scale.

Note: this is a blog post for guitarists and musicians.

It's not uncommon for aspiring guitarists to begin the journey of lead and improv guitar using this scale:

But it becomes obvious early on that these patterns cannot be used for playing more fluid, expressive lines. What's the solution? Three-note-per-string patterns.

Okay, now the lines are more fluent but playing key changes hasn't gotten any easier. It requires shifting patterns up and down the neck which breaks line continuity, musical thinking, and just makes the guitar a challenging instrument to play anything containing more complex harmony than a major or minor key.

Some advanced guitarists also experiment with four-note-per-string scales and patterns.

But there's a problem: four-note-per-string scales go up/down in fourths and guitars are also tuned in fourths (mostly). That requires inevitable shifting in both X and Y axis of the fretboard. It is pretty challenging to play guitar this way. It is difficult to build the muscle memory in a two-dimensional plane when there are no anchors (i.e. physical traits) to reliably help the player find their way on the fretboard without continuous eye-hand coordination.

Even though playing diagonally gives you the best range, the best intonation, and often it is how people appear to play, most have developed and internalized a framework of positional and linear anchors to get them there.

But there's also another common issue with all of the above patterns. They tend to focus on the lower strings which, in guitar, fall a whole octave below middle C and not suitable for melodic, fluent, or expressive playing.

Scaling it Down

One way to address this issue is to break it down into the smallest pieces and build it back up from there. Let's start by finding the smallest fretboard block that could allow playing in any key and require minimal movement and shifting.

I propose the range from C5-F5, (extended with B4 or F#5 as needed) on the E string for several reasons:

• It is natural middle-point in the fretboard and allows for instrument to stay in equilibrium without physical effort
• The frets are not too big or small. In this area, the average guitarist should be able to play a full perfect fourth between the index and the pinkie fingers. (This range typically goes down to a major third in the largest frets, and up to a tritone or more in the smallest frets)
• This is an expressive range for playing melodies (alto-soprano range) and the notes are easy to identify for those getting started

Introducing Guitar Tetris

Great. But how can one play in this range? Here come tetrachords - four note patterns that can help. Let's focus on the major scales for simplicity. Four tetrachords can cover all keys:

• WWH
• WHW
• HWW
• WWW

where W = whole-tone interval between two notes (e.g. C - D)
and H = half-tone interval between notes (e.g. E - F)

For example, the four notes: C, D, E, F form a W-W-H pattern and they cover different parts of each major scale for C Major and F Major.

Here are four other notes - C, D, Eb, F which form the W-H-W tetrachord which covers parts of the Bb and Eb Major scales.

I hope you get the point. If we go through the four tetrachord patterns: WWH, WHW, HWW, WWW, we would be covering major scales in the Circle of Fourths - all twelve keys. Here is an illustration.

Here's a rudimentary example of improvising within this very limited range through a Circle of Fourths modulation.

Impact

I hope by now it has become apparent that, even with this tiny range, it is possible to come up with contrived but yet fluent and expressive ideas that require little shifting and only a few patterns to master. This approach can help guitarists focus on music not technique, break out of the complex box-pattern thinking, and play fluently across complex harmonic changes.

Note: even though tetrachords contain four notes, this approach does not prescribe four-finger-playing as a necessity for these patterns. It may be more comfortable for some to instead use whichever fingers are dominant in their style. My own hands are just average and I have to shift the left hand often to hit certain notes. But I believe that guitarists who get comfortable playing at least up to a perfect fourth on the higher strings can more quickly open up their playing range across the guitar neck.

Scaling Up Again

As a next step, the pattern can be applied on the next string, B, within the same fret range. One will notice right away that the same tetrachord patterns will apply even though they will be shifted by a fourth. This expansion should feel natural quickly.

The third step is the most critical: Extend the tetrachord patterns across all the first two strings. Two strings are enough to play just about any melodic phrase. Two strings can also introduce contrapuntal elements much more gently and consistently. I have found this step to be an important period that requires systematic practice before scaling to other strings.

Detour - Gamifying Practice

At this point in life, music is a hobby for me. I rarely have the time to practice seriously so I do the best I can to get around it by gamifying practice sessions whenever possible by using coding to hack together various automations.

Here's a python script (requires MacOs) that uses synthesized speech to call out random keys alongside a metronome click. The goals are

• play simple and on time
• listen carefully and anticipate the next move
• try keep a continuous flow of musical ideas

kitchen-sink/practice_keys.py at main · georgetheka/kitchen-sink

Random Utilities. Contribute to georgetheka/kitchen-sink development by creating an account on GitHub.

GitHubgeorgetheka

And finally, I recorded a quick freestyle improv that uses these tetrachord patterns, particularly focused on the higher strings.

I hope this was helpful in some way and I look forward to your feedback!

After putting up the Christmas tree early with the kids, I spent a few hours this Sunday afternoon on another geeky techno-music experiment: building a program converts any MIDI guitar into a customizable computer keyboard.

Although getting this to work coding-wise was not difficult, the hard part was figuring out how to map a guitar to a keyboard. After many tries I found the right way: split the keyboard and flip the left side upside down. At that point it becomes a regular QWERTY keyboard and I started typing immediately and with almost no practice.

The code and the mapping are available here: https://github.com/georgetheka/kitara

Converting a regular six string guitar into a hybrid, seven-string.

Long story short: my interest in playing a hybrid guitar (bass + guitar as one instrument) got renewed during the beginning of the pandemic when playing with people in NYC was literally a choice between life and death.

Although, I have experimented in the past with 8-string, and 7-string guitars and various custom modifications, I never found myself falling in love with them. Adjusting to a different string set and tuning wasn't the issue. More strings meant many new possibilities but also a loss of expressiveness and fluency with a musical vocabulary built through the years. It felt like learning a new language, and any language takes many years to master.

So, I started thinking creatively. I sketched out what I wanted: a regular guitar that allowed me to play an emulated bass and guitar combo and a comfortable range in each instrument. How would that even work? Well, if it meant that some of the ranges overlap somewhere in the middle -- that's okay -- many melody lines in that shared range are often played in unison anyway. It's a good compromise.

Once I came to terms with that approach, the experimentation began. I designed a simple electronic circuit that utilizes a Seymour Duncan Duckbucker specialized pickup to allow signal splitting into two ranges of three strings each. This circuit has only one volume control via a 500K pot for a darker, warmer sound, its own 1/4" jack and the entire unit is grounded separately. This signal is sent through a bass synth petal and other effects in order to emulate a 3-stringed bass.

Then, I designed a second, more traditional, circuit that treats the upper range of the Duckbucker as a single-coil pickup. A 250K push-pull pot, combined with a  classical 5-way switch allows switching between humbuckers and single coil modes, therefore allowing for a wide range of sounds. A single tone control via a 250K pot and a 0.022µF capacitor for brighter sound is wired to apply to all three pickups.

Removing one of the two usual Stratocaster tone controls was necessary because I needed the existing space to accommodate both circuits under the same pick-guard without having to carve out parts of the guitar body. I ended up drilling only one additional whole in the pick-guard only, and although the controls are a little crammed, they're easy to handle. Besides, I think they look cool that way.

Below is a schematic of the circuits used for v1.

The new version 1.0 of the electronics wired and passing the tests before assembly.

And finally the first test drive.

Lastly, I trimmed two pieces of stainless steel and placed:

• the first on top of the two bridge humbucker magnets in order to attenuate the pickup signal signal for the E and A strings and create a sound separation between the bass and guitar strings.
• the second (optional one) covering the higher four strings of the middle pickup to absorb any left over bleeding from these strings in the bass signal

This setup allows playing in hybrid+overlapping mode: 3 strings of bass through the middle pickup lower range and its dedicated circuit, and 4 strings of guitar through the unattenuated bridge humbucker. Hence the name: 627 (six to seven). The overlap is the intentional compromise and it enables expressiveness on both instruments.

And with foot drums...

Cover photo credits: @ExpLatinAmerica. Learn more here.

Avoiding debt is hard, nearly impossible. It is even harder to get rid of it. But the hardest thing is figuring out the how. Just exactly how do you get rid of tech debt? And would you want to?

Here are some loosing strategies:

Strategy #1: Dedicate 20% of the sprint to tech debt.

Why it fails: besides the fact that humans are terrible at working in percentages in a multiplex environment, that 20% will be the priority battleground between engineering and stakeholders. How do you respond to "...tech debt can wait. If we don't get this out by next week, might as well there be no product..."? Well the rational answer is you can't. Feature wins, tech debt looses. You would think this will change in a bigger team. Nope. Bigger teams do have more capacity but they are also more expensive and the stakes are higher.

Strategy #2: Let's sneak in most of it on feature estimations. Nobody will notice.

Why it fails: Yeah. Nobody dumb enough. While this is a great strategy for the most basic kind of tech debt, it won't scale with for paying off large chunks of it. It will artificially inflate each estimation and the team will just fail to deliver critical stuff on time. Tech debt will ultimately become feature debt. And if there are multiple teams, velocity comparisons will quickly unravel that dirty magic trick.

Strategy #3: The Revolt - after X many months of accumulating lots of technical debt the team finally looses it: "That's it. We're going to force some tech debt into the next sprint and no one can stop us!!!"

Why it fails: setting aside the fact that revolts are risky business, even if they work, having uneven value distribution being delivered over time will quickly increase an organization's risk in the marketplace. It might feel like an internal victory but in a tight market race hitting the brakes on shipping continuous value for a moment is all it takes for your competitors to quickly get ahead. It can all happen in a blink of an eye.

So what is tech debt anyway?

Technical debt describes all shortcuts a team takes to achieve a goal in the short term making it difficult for the team -- and ultimately the business -- to succeed in the long term.

I like to think of it as using a credit card: you can swipe it to buy whatever you want but at some point you are going to have to pay it back. And just like a credit card, tech debt earns compound interest over time with a pretty high interest rate (consider how quickly code goes stale today).

So, how should you pay it off?

A. Transactor: You can pay it all back as soon as possible, but you may end up with no liquidity to pay for other things. [no teams ever do this although many want to do exactly this]

B. Delinquent: You can pay only the bare minimum regularly, but in the long term you may become delinquent and default. [many teams end up unintentionally doing this]

C. Revolver: You can pay an amount less than balance due such that you have enough cash in hand but large enough so you avoid incurring too much interest. [more teams should be doing this]

I believe the correct answer is C. Option A means a team cannot react to market demand if it is too busy paying off debt, and option B means there is a looming default event for this particular product or system in the future that an org may not see coming until it is too late.

But the biggest advantage of option C is that when combined with strong planning and feedback loops, it can identify opportunity windows to sometimes pay back a lot of the debt quickly, particularly during a moment when the market pressure is low. Strong feedback/planning can also identify opportunities to write off tech debt. When an org decides to discontinue  products or features that are no longer enabling the business, the related tech debt also becomes void. Goodbye.

A strategy that works

A strategy that works well is a multi-faceted one with at least three dimensions:

• Definition of Done
• End-of-Life Projection
• Engineering as Stakeholders

1. Definition of Done
An organization is better served if some aspects of tech debt are rolled into the Definition of Done for how product is shipped. The following should not be categorized as technical debt but instead they should become part of the shipping requirements for any feature:

• Unit Test Coverage: this may not make much of a dent in shipped product quality but it is the only way for a team to collectively maintain and refactor code over time without significant risk.
• Critical Path Integration Tests: these will definitely put strong assurances on shipped quality.
• Observability: logging and telemetry are as critical as your windshield, mirrors, and dashboard are to driving a car. Why bird-box your driving?
• Deployment Configuration: doing this right from the beginning significantly reduces downtime risks due to configuration changes down the road. There are no net gains when short-circuiting this process.

2. End-of-Life Projection
The most common mistake teams make is not computing and communicating the capacity/occupancy limits for a shipped feature that was delivered using shortcuts and incurring tech debt. Business stakeholders are often not aware that a shipped feature has scale limitations and, depending on the growth rate, those limitations are already setting a life expectancy for that feature.

Set and communicate capacity and end-of-life expectations clearly from the beginning and one of two things is likely to happen:

• stakeholders could be open to invest in the more scalable solution which could mean current tech debt becomes regular feature development.
• or, they could be fine with the life expectancy for that feature for the short term, but may want to regroup in the future to discuss redeveloping this feature for the next level of scale.

In the first case tech debt is not erased but significantly reduced. In the second case tech debt is not recorded as such as there is a clear end-of-life for this feature. Instead, tech debt could become the roadmap for the v2.0 of this feature.

3. Engineering as stakeholders
Consider what engineering teams typically work on during a sprint: a todo list prioritized by a product owner. The product owner has come up with that list by negotiating with several or many stakeholders: people or teams who have a stake in the code being shipped so they can advance one of their business goals, for the good of the organization.

Teams...needing to ship code....to advance....their goals....for the good of the organization...you say? That is exactly what engineering teams are trying to do when wanting to pay off tech debt.

What if, just what if:

Engineering teams take on a stakeholder role during planning and prioritization round table. Just like any other team, they will need to make their case to get sprint time for tech debt items they believe will advance their team goals for the greater good of the business.

They no longer have to find ways to justify doing the right thing for their organization or hide their incredibly valuable work under other features.

Tech debt becomes just regular feature delivery and shipping comes with the same recognitions and celebrations as any other feature that advances goals of any other team in the organization.

What's even more valuable, this approach provides a two-way checkpoint for the team: having to explain the value of tech debt to a non-engineering audience not only helps develop strong cross-team communications but it can also help engineering double-check their own thinking and avoid paying off tech debt that does not advance any business goals: "Is this tech debt really valuable or just a cool thing I am itching to work on?"

Tech Debt Utilization

Just like credit card consumers are advised to not exceed the ~30% credit utilization limit in order to build and maintain their credit, it is similarly a good idea to limit tech debt to around 25%-30% of the total points of the backlog. In the credit card example, credit utilization is the ratio of the current balance due over the credit limit and that can be translated to tech debt as:

Tech Debt Utilization = (Tech Debt Balance / Total Backlog Balance) x 100%

However, in order to compute the balance, it is critically important to first record all new tech debt correctly. This can be done by creating and estimating tech debt PBIs (product backlog items) for each shortcut the team takes, just like a credit card balance is augmented with each purchase during a merchant transaction.