DEV Community: Stephen Leyva (He/Him)

From HS dropout to Software Engineer

Stephen Leyva (He/Him) — Fri, 19 Jun 2020 00:27:05 +0000

These stories seem to be very common nowadays but I thought I'd take the time to share mine. I don't believe it’s special by any means, however, I am using it as a mechanism to do a retrospective on my life. To preface, I by no means discourage education. I think it is of paramount importance. However, the path to attaining education and ultimately wisdom is each one's path to forge. Discipline and determination are required no matter the path. However, as Socrates said: "Now, when you want knowledge as much as you wanted air, you shall have it."

I am a first-generation American as my parents immigrated from Mexico. I grew up in a sizable family with very little means. Though I didn't know it at the time and I wouldn't trade that experience for the world. When I was 7 years old, my dad brought an old broken Xbox 360 (RROD error for you Xbox 360 alum out there) home. As we didn't have a lot of money, my dad challenged me: If I could fix the Xbox, it would be mine. Little did he know that this would spark an interest in me that would define my future endeavors.
After reading tutorial after tutorial and watching Youtube video after Youtube video suggesting I put my Xbox in the oven or wrap it in a towel, I found one that suggested re-soldering the CPU to the motherboard. After saving up to acquire a soldering iron, CPU thermal paste, and flex screws for the heat sinks, I was ready to go. I remember the pride I got seeing that Green ring light up as the home screen came into view. I wanted more.

As we didn't have a computer or internet at home, I'd walk to the library when I wanted to use the internet. I found myself there every day, experimenting, tinkering, and creating simple applications and eventually landed in full-stack development using Codecademy. After completing several of their courses, I decided to start building a web site for small businesses in my town and hosting them on AWS. This eventually also branched into IT work (you can build a website fix my PC). About the time I was 13, I dropped out of school for personal reasons and decided to finish my HS through correspondence. College was not even possible for me and at that time plus I had decided that school just was not for me. It wasn't that I didn't like learning, I love learning. Rather, it was learning about things that I failed to see the practicality of that left a bitter taste in my mouth.

For about 4 years I did IT work in my town and surrounding areas (though I didn't know what in the world I was doing) fixing printers, imaging PCs, cleaning, and configuring pay systems for stores like Walmart. Finally, at 17 I applied to be a bank teller at a local bank to get professional experience in the workforce. I went in for the interview and the CIO of the bank (though I didn't know this at the time) interviewed me and ask if I wanted to start as a JR. network engineer under their Sr. network architect. I was floored!
This is what I consider to be my first break into tech as its what allowed me to branch into engineering on a professional level. Additionally, it allowed me to work with some amazing people and get some awesome mentoring. 5 years later, I now have my dream job of working on solving some awesome problems at Amazon Web Services. While the journey involved late nights banging my head against a computer, weekends at various coffee shops cursing at my code, and bargaining (if this pod goes into a CrashLoop one more time...) it was worth it. Everyone has their path to take when it comes to attaining knowledge and everyone is capable in their way. In the words of Socrates (or someone just as wise IMO), "just keep swimming".

That's my story, what's yours?

How have many without a college education broken into the industry?

Stephen Leyva (He/Him) — Sat, 28 Mar 2020 21:53:34 +0000

I was watching an Engineering AMA panel (shout out to a great learning resource for newcomers called MASTERMND for hosting it) and one of the questions asked was how many without formal education have broken into the tech industry? As someone with a non-traditional background, it was really awesome and encouraging (especially for ones trying to break in to the industry) to see so many who didn't go the formal education route. I am very curious as to what other stories are out there, so I leave it with the wider Dev audience: What's your story?

Self Balancing Binary Search Tree: Insertions

Stephen Leyva (He/Him) — Fri, 27 Mar 2020 02:54:44 +0000

Binary Search Trees (BTS) are an extremely useful data structure found in a variety of applications. They provide O(log^n) time complexity for most operations. However, when a tree becomes unbalanced (IE. too many entries on the left or the right of a given node), the time complexity of operations degrade to something that looks more like a linked list. Several self-balancing tree data structures exist to solve this problem. These solutions can be found in anything from LSM Tree based databases (Cassandra, Hbase, RocksDB, etc) to the Completely Fair Scheduler algorithm that is used in the Linux Kernel as the default processes scheduling algorithm. This tutorial will cover the implementation of a particular self-balancing tree known as a Red-Black Tree in Golang.

Overview

Red Black Tree's have constraints that guaranty relative (tho not perfect) balance on both sides. Those constraints are:

The Root node is always Black
All leaf nodes are black
There can be no adjacent red nodes. (IE red node will have two black children nodes)
Every simple path from a node to a descendant leaf contains the same number of black nodes.

These constraints guarantee that a tree will be relatively balanced. These constraints are maintained on every mutation by a combination of re-coloring and node rotations based on other node relationships (Parent, Grand Parent, Siblings, etc). Today we will be developing the parts of the Red-Black Tree to handle insertions. This tutorial assumes a working knowledge of BST trees.

Implementation

It's important to realize a red-black tree is still a BST. This means insertions and searches are handled in the same way as with a normal BST Tree. We can then implement the parts of a BST that we are familiar with.

The struct that represents our tree and public insertion related functions we know are on a BST Tree for consumers. Additionally, the red-black tree requires some private functions for tree correction and rotation:

// tree.go
package tree

import (
    "fmt"
)

type RedBlackTree struct {
    Root *Node
}

func (*r RedBlackTree) Insert(node *RedBlackNode) {}

func (*r RedBlackTree) Search(key string) *RedBlackNode {}

func (*r RedBlackTree) fixTreeAfterInsertion(node *RedBlackNode) {}

func (*r RedBlackTree) rotateLeft(node *RedBlackNode) {}

func (*r RedBlackTree) rotateRight(node *RedBlackNode) {}

Next, we will define our Node, a new property called Color to represent whether a node is red or black, and the Node’s Parent. Additionally, we will define a NilNode for leaf nodes:

// tree.go
type Color uint

const (
    RED Color = iota
    BLACK
)

type RedBlackNode struct {
    Color  Color
    Key    string
    Parent *RedBlackNode
    Left   *RedBlackNode
    Right  *RedBlackNode
}

var NilNode = &RedBlackNode{Color: BLACK}

Now that we have the structure lets implement some functions:

BST Insertion and Search

Insertion is just a BST insertion at first so let us implement that function as we know how. Take notice that the fixTreeAfterAdd function gets called on every insertion. So, we'll add that too, though it's just a no-op right now:

// tree.go
func (r *RBTree) Insert(node *RedBlackNode) {
    if r.Root == nil {
        r.Root = node
    } else {
        currentNode := r.Root
        for {
            if node.Key == currentNode.Key {
                return // Do nothing as node already in tree
            }
            if node.Key > currentNode.Key {
                if currentNode.Right == NilNode {
                    node.Parent = currentNode
                    currentNode.Right = node
                    break
                }
                currentNode = currentNode.Right
            }
            if node.Key < currentNode.Key {
                if currentNode.Left == NilNode {
                    node.Parent = currentNode
                    currentNode.Left = node
                    break
                }
                currentNode = currentNode.Left
            }
        }
        r.fixTreeAfterAdd(node) // No-Op right now
    }
}

Now let us write a test to assert correctness so far. I use a technique from property based testing that involves generating a lot of random input for my tree. I use the helper methods func String(length int) string and StringWithCharset(length int, charset string) string to generate this input:

// tree_test.go
package tree_test

import (
    "math/rand"
    "sort"
    "testing"
    "time"

    . "github.com/srleyva/LSM/pkg/trees"
)

func TestRBTress(t *testing.T) {
    // Generate List
    entryCount := 10000
    entries := make([]string, entryCount)
    for i := 0; i < entryCount; i++ {
        entries[i] = String(10)
    }

    t.Run("Test insertion into an RB Tree", func(t *testing.T) {

        // Set Up tree
        tree := &RedBlackTree{nil}
        for _, entry := range entries {
            newNode := &RedBlackNode{
                Color: Black,
                Key: entry,
                Parent: NilNode,
                Right: NilNode,
                Left: NilNode 
            }
            tree.Insert(newNode)
        }
    })
}    

func String(length int) string {
    return StringWithCharset(length, charset)
}

func StringWithCharset(length int, charset string) string {
    b := make([]byte, length)
    for i := range b {
        b[i] = charset[seededRand.Intn(len(charset))]
    }
    return string(b)
}

At the moment, this doesn't test for anything but sets up the necessary scaffolding we need for testing. We now need a function to retrieve our key, so let us add that. Once again, this is just a classic BST Search and quite similar to the Insertion Algorithm.

// tree.go

...
func (*r RedBlackTree) Search(key string) *RedBlackNode {
    currentNode := r.Root
    for currentNode != NilNode && key != currentNode.Key {
        if key < currentNode.Key {
            currentNode = currentNode.Left
        }
        if key > currentNode.Key {
            currentNode = currentNode.Right
        }
    }

    if currentNode == NilNode {
        return nil, fmt.Errorf("key does not exist in tree: %s", key)
    }
    return currentNode, nil
}

Now we can modify out test:

func TestRBTress(t *testing.T) {
    // Generate List
    entryCount := 10000
    entries := make([]string, entryCount)
    for i := 0; i < entryCount; i++ {
        entries[i] = String(10)
    }

    t.Run("Test insertion and retrieval on RB Tree", func(t *testing.T) {

        // Set Up tree
        tree := &RedBlackTree{nil}
        for _, entry := range entries {
            newNode := &RedBlackNode{
                Color: Black,
                Key: entry,
                Parent: NilNode,
                Right: NilNode,
                Left: NilNode 
            }
            tree.Insert(newNode)
        }

        // Pick random entry for entry list
        randomIndex := rand.Intn(entryCount)

        entry, err := tree.Search(entries[randomIndex])
        if err != nil {
            t.Errorf("err where not expected: %s", err)
        }

        if entry.Key != entries[randomIndex] {
            t.Errorf("search returned incorrect key: got=[%d] expected=[%d]", entry.Key, entries[randomIndex])
        } 
    })
}

Now we run that test and see it is passing

go test -timeout 30s

# Output
ok      github.com/srleyva/LSM/pkg/trees
Success: Tests passed.

Now, let us add a specific test to check for RedBlackTree level constrains. Also, I am adding a helper function to calculate the height constraint.

Now I am not going to conflate unit testing methodology here as that's a topic for another day, for simplicity I will keep all my tests in one case, though if this were a production product, I would not ship with this test:

// tree_test.go
...
    t.Run("Test RB Tree", func(t *testing.T) {

        // Set Up tree
        tree := &RedBlackTree{nil}
        for _, entry := range entries {
            newNode := &RedBlackNode{
                Color: Black,
                Key: entry,
                Parent: NilNode,
                Right: NilNode,
                Left: NilNode 
            }
            tree.Insert(newNode)
        }

        // Pick random entry for entry list
        randomIndex := rand.Intn(entryCount)

        entry, err := tree.Search(entries[randomIndex])
        if err != nil {
            t.Errorf("err where not expected: %s", err)
        }

        if entry.Key != entries[randomIndex] {
            t.Errorf("search returned incorrect key: got=[%d] expected=[%d]", entry.Key, entries[randomIndex])
        }

        // Test Height Constraint
        maxHeight := 2 * LogN(entryCount+1)
        node := tree.Root
        count := 0
        for node != NilNode {
            count++
            node = node.Right
        }

        if count > maxHeight+1 {
            t.Errorf("Broke Level Contraints: got=[%d] expected=[less than %d]", count, maxHeight+1)
        }
    })
...
func LogN(n int) int {
    if n < 1 {
        return 0
    }

    return 1 + LogN(n/2)
}

Running will yield an error about height constraints, as we have not implemented the balancing but right now we have a basic BST Insertion and Search Algorithm.

Perfectly Balanced (though not really), as all things should be.

So we know that red-black trees involve re-coloring and node rotations in that order. First, re-coloring will attempt to adjust the tree to satisfy the Red-Black Tree Constraints. If re-coloring does not work, then the algorithm will perform node rotations to fix the tree.

Rotations

Let's implement rotations first as they are the last in the order of operation for Red Black Trees after re-coloring.

First, an animation to demonstrate rotations:

Notice how the BST properties are maintained. For example, a left rotation will shift a child node to the parent, however, the children to the left of the child node being promoted are now moved to a right child under the old parent. This is because these children are greater than the old parent but still less than the new parent.

Here is the implementation

// tree.go
func (r *RBTree) rotateLeft(node *RedBlackNode) {
    // Right of node (old parent) will become the new parent
    RightNode := node.Right

    // Assign the right tree of new parent to old parent
    node.Right = RightNode.Left

    // Tell the right tree of new parent about the change by setting a new Parent Property
    RightNode.Left.Parent = node

    // Assign old parent's parent to new parent 
    RightNode.Parent = node.Parent

    // Correct top of tree

    // If this is the top of the tree
    // Make RightNode root
    if RightNode.Parent == nil {
        r.Root = RightNode
    }
    // If This is not top of tree, need to fix node's parent node
    // Check if node is Left or Right of Parent Node and assign RightNode 
    if node == node.Parent.Left {
        node.Parent.Left = RightNode
    } 
    if node == node.Parent.Right {
        node.Parent.Right = RightNode
    }

    // Demote current parent to child of new parent
    RightNode.Left = node
    node.Parent = RightNode

}

The right rotation will be an inverse of the above logic:

// tree.go
func (r *RBTree) rotateRight(node *RedBlackNode) {
    LeftNode := node.Left
    node.Left = LeftNode.Right

    LeftNode.Right.Parent = node
    LeftNode.Parent = node.Parent

    if LeftNode.Parent == nil {
        r.Root = LeftNode
    } else if node == node.Parent.Left {
        node.Parent.Left = LeftNode
    } else if node == node.Parent.Right {
        node.Parent.Right = LeftNode
    }

    LeftNode.Right = node
    node.Parent = LeftNode
}

Re-coloring

The next operation after the mutation (this case insertion) is a re-coloring. This is done to assert whether or not rotation is necessary. It is done after every insertion.

func (r *RBTree) fixTreeAfterAdd(node *RedBlackNode) {
    node.Color = RED // New nodes are always red

    // If node is root or the parent is Black, we don't need to perform any re-coloring
    for node != r.Root && node.Parent.Color == RED {

        // Check if parent is a right or left node

        // If parent is left node
        if node.Parent.Parent.Left == node.Parent {
            // because parent is left of grandparent, uncle is right of grandparent
            uncle := node.Parent.Parent.Right

            // If uncle is red, recolor parent and uncle to black
            if uncle.Color == RED {

                // Recolor parent and uncle to black increasing the black node count from nth node to leaf by 1
                node.Parent.Color = BLACK
                uncle.Color = BLACK

                // Make the granparent red
                node.Parent.Parent.Color = RED

                // Traverse up the tree to grandparent and re-run through fix algorithm
                node = node.Parent.Parent
            } else {  // Uncle is black
                // if node is a right child
                if node == node.Parent.Right {
                    // traverse up to parent
                    node = node.Parent
                    // rotate left
                    r.rotateLeft(node)
                }
                // recolor parent to black
                node.Parent.Color = BLACK

                // recolor grandparent to red
                node.Parent.Parent.Color = RED

                // rotate grandparent right
                r.rotateRight(node.Parent.Parent)
            }
        } else if node.Parent.Parent.Right == node.Parent {
            // because parent is right of grandparent uncle is inverse left of grandparent
            uncle := node.Parent.Parent.Left

            // if uncle is read re-coloring is all thats needed
            if uncle.Color == RED {
                // increasing black node count to leaf from nth node to one
                node.Parent.Color = BLACK
                uncle.Color = BLACK
                // traverse to grandparent and re-run fix algorithm
                node = node.Parent.Parent
            } else { // unlce is black, rotation is needed
                if node == node.Parent.Left {
                    // traverse to parent
                    node = node.Parent

                    // rotate right
                    r.rotateRight(node)
                }
                // recolor parent to black
                node.Parent.Color = BLACK

                // recolor grandparent to red
                node.Parent.Parent.Color = RED

                // rotate left
                r.rotateLeft(node.Parent.Parent)
            }
        }
    }

    // To satisfy Red Black Tree constraint #1, recolor root to black
    r.Root.Color = BLACK
}

Re-run test to ensure red-black tree level constraint is satisfied:

go test -timeout 30s

# Output
ok      github.com/srleyva/LSM/pkg/trees
Success: Tests passed.

Recap

In review, we've learned a tree data-structure that allows for self-balancing. It is important to realize that this balancing is relative and not perfect (sorry Thanos!). This tradeoff allows for faster insertions and deletions. AVL Trees, on the flip side, are more strictly balanced resulting in faster lookups and are more ideal for heavy read applications. However, the trade off here is insertion and removals are slower. This is why LSM Tree's tend to favor AVL trees over Red Black Trees. However, things like the Completely Fair Scheduler algorithm prefer faster deletions and insertions into the scheduler's timeline for future execution. In the next article, I will dive into deletions from a Red-Black Tree utilizing some of the functions we've already built. Until then, stay curious and stay healthy!

Beginner Guide to Design Patterns: Strategy

Stephen Leyva (He/Him) — Tue, 24 Mar 2020 19:58:29 +0000

Throughout the course of my career, I have worked at various companies ranging from the small startup to the massive tech company. The variety of my experience has led me to some conclusion especially when it comes to on-boarding with new projects and technology stacks. Software Design really matters. In addition to system architecture, algorithmic design, software design is a skill set in itself. You can have well designed and elegant algorithms but if the encapsulation logic and design around them is lacking, maintaining and on-boarding for new developers becomes a nightmare. As I am currently in social isolation (as most of us), I have decided to write articles about this field of study to pass the time and sharpen my own skills. For more in depth knowledge, I recommend "Design Patterns: Elements of Reusable Object-Oriented Software". This will be a brief overview to help my own recollection and hopefully help others through my struggles. A basic understanding of Object Oriented Design is recommended. It is also noted that these patterns are not silver bullets and based on your use case, can be considered over engineered solutions. I will be using Python to present examples, however, design patterns tend to transcend languages so you can follow along in your preferred language. So, with that introduction, let's explore the Strategy pattern.

Avenger Initiative

Project Requirements

A grave threat is upon our world! The only thing that stands between us and total destruction is YOU! You have been tasked to assemble a special team of heroes to combat this threat.

Code

Let's define our base hero and give him some abilities.

class SuperHero:
    def display(self):
       raise NotImplementedError

    def attack(self):
        print("Punch!")

    def shield(self):
        print("Shield!")

    def fly(self):
        print("fly!")

Sweet we have a base hero that our heroes can inherit from! Now, let's create our first hero!

class IronMan(SuperHero):
    def display(self):
        print("I am Ironman!")

We just heard back from HQ, another hero has been found on ice. Lets create a class for him!

class SuperSoldier(SuperHero):
   def display(self):
       print("Captain America! Avengers Assemble!")

There is however a slight problem, the super soldier can't fly! Also, come to think of it, I think IronMan definitely has way better attacks than punch. Guess we can override those particular abilities.

class IronMan(SuperHero):
    def display(self):
        print("I am Ironman!")

    def attack(self):
        print("tank missile!")

class SuperSoldier(SuperHero):
   def display(self):
       print("Captain America! Avengers Assemble!")

   def fly(self):
       print("I cannot fly...")

Do you see any issues with the above approach? What if more heroes can't fly? We'll have to duplicate the logic in SuperSoldier.fly() violating DRY principle. Also, what if other heroes have attack abilities outside of punch? We'll have to override for each one and loose the value of inheritance. Additionally, one change to the super class can break functionality for old heroes. Is there a better way?

Introduce a little strategy

The first thing we want to do is identify what changes between objects and try and encapsulate that away into its own class of objects. We've identified attack and fly as two methods that vary between objects. So, lets create a contract or interface for those two methods.

class AttackAbility:
    def attack(self):
        raise NotImplementedError


class FlyAbility:
    def fly(self):
        raise NotImplementedError

Now that we've established out contract or interface, how can we change our SuperHero class to take advantage of this interface?

Program to an interface, not a implementation.

We know that our FlyAbility has a fly method. As the client of the interface, we don't really care how fly is implemented but rather just the contract is fulfilled and the function is called correctly.

class SuperHero:
    _fly_ability = FlyAbility()

    def fly(self):
        self._fly_ability.fly()

Of course, running this will result in a NotImplementedError being thrown. So, we have to create an object that implements our fly ability for Ironman.

class RocketFlyAbility(FlyAbility):
    def fly(self):
       print("Rocket Thrusters engage")

class IronMan(SuperHero):
    _fly_ability = RocketFlyAbility()
    def display(self):
        print("I am Ironman!")

    def attack(self):
        print("tank missile!")

What about the SuperSoldier who can't fly? Once again a new object to encapsulate that logic.

class NoFlyAbility(FlyAbility):
    print("Aww man, I can't fly...")

class SuperSoldier(SuperHero):
   _fly_ability = NoFlyAbility() 
   def display(self):
       print("Captain America! Avengers Assemble!")

Now lets introduce a new hero into the fold to see how easy it is to extend new heroes.

class Hulk(SuperHero):
    _fly_ability = NoFlyAbility()
    def display(self):
        print("Hulk Smash!!")

As homework, implement the attack methods in a similar way!

With a strategy like this, the planet should be in safe hands! That is until the next crisis!

Recap

The strategy patterns allows us to encapsulate implementations that vary between object to object. We also get a collection or hierarchy of similar algorithms and methods grouped under a superclass. Everything that inherits from FlyAbility is guaranteed to have a fly() method. The implementation is decoupled from the caller. This means we can change and add implementations without breaking existing functionality. What if a new Rocket comes out with faster flying enabled? Swap out Ironman's _fly_ability. In fact, in future lessons, we will look at how to do this in a more dynamic fashion at runtime.

Technical Debt and Embracing Risk: How to find the MVP?

Stephen Leyva (He/Him) — Mon, 28 May 2018 22:47:29 +0000

Technical Debt and Embracing Risk: How to find the MVP

Any good engineer constantly finds themselves asking what is the quickest and easiest way to deliver value to my stakeholder. This is commonly referred to as the MVP or minimal viable product. In easier terms it means what is the minimum I have to provide for my product to be useful to stakeholders. In fact, many engineers commonly stop and ask themselves in the middle of a project is this the MVP? However, by then it may already be too late. So, how do we solve this? We’ll examine some concepts such as good and bad technical debt, embracing risk, and the idea of what is value (and perhaps the difference between value to us and value to our stakeholders). Hopefully a consideration of these concepts can help us to examine what the MVP really is before we even touch a keyboard.

Technical Debt

Debt. Whether its monetary, time or something else, anything of value comes along with debt. For an engineer, the biggest thing of value is his time (and energy). There is commonly a bad stigma associated with technical debt but the truth of the matter is technical debt can be good. How so?

Technical debt can enable you to move faster when delivering a product or value to a stakeholder. To illustrate, typically when purchasing a car one goes into debt as they may have to get a loan. However, this allows for transportation to and from work, the grocery store, and other necessary places. This kind of debt delivers value upfront and can even aid in eventually paying off the debt. Sure one can work for a year to save up for the car but is this work really offering value up front?

Essentially, an MVP may have us take on some technical debt. Work may have to be refactored or reworked. However, value is delivered upfront to the stakeholders. It has also been my experience that technical debt can help to get some of the foundational logic in place for certain things. Code can be refactored or even changed but hopefully the behavior remains roughly the same. A word of caution though. Beware of reckless debt.

Technical debt does not mean lack of consideration. Rather the cost of taking on technical debt should be counted and considered in relation to the value returned. Back to our illustration, I grew up in a desert climate. Not a body of water around me for hundreds of miles. (Does a pond count?) Now, imagine I were to go out and get a loan for a boat. Can it really be said that the debt I took on is delivering value?

The point here is technical debt (and real debt) should not be taken lightly. Rather it should be considered, counted very carefully, and documented in some form. It also does not mean we allow bad practice to invade our workflow. To paraphrase the pragmatic programmer: One broken window and there goes the neighborhood.

It is impossible to alleviate all technical debt but, by remaining wise and considering the technical debt we take on we can create a true MVP and build a good foundation that can be iterated on. Another question to carefully consider is in addition to technical debt, how much risk am I willing to take on?

Embracing risk

I am a firm believer in the SRE handbook’s stand on embracing risk. Anything worth doing involves a measure of risk. We see quite a few examples of this in any industry (especially the technology industry) and we also see that in end nothing is a guarantee. Innovation is inherently risky. However, without innovation (and rapid innovation) a company or product will die. So, how do we balance risk and the MVP?

Look at the following illustration:

What do we notice about a skateboard as opposed to a bike or even a car? More risk may be involved. It is easier to fall off of a skateboard as opposed to a bike. Also much easier to fall off a bike than to fall out of a car. (Although not impossible). The idea is that granted each product above has considerable risk but the question once again is how much risk should we accept?

To quote the SRE Handbook: "We strive to make a service reliable enough, but no more reliable than it needs to be." The idea being that investing too much into reliability can slow production, introduce bottlenecks, and is the enemy of the MVP. So like technical debt sitting down and calculating the cost before making a decision is the correct path. Measure how available does my system need to be? What is the expectation from my stakeholders? This will require communication with stakeholders and having clear requirements from your stakeholders.

Once again, MVP does not mean throw caution to the wind but rather means weigh what is necessary for my product to be viable right now. To understand this we have to ask what is value?

Value

The question of what is value is an interesting question and a matter of perspective. Value to you may not translate as value to your stakeholder. So, how can we differentiate between the two?

In the picture above the two men have a similar objective...to get water. One of these men is concerned with the MVP and one is not. Likewise, one will survive and one will not. This illustrates the importance of figuring out what is of value and what is not and delivering that value quickly. How can this be done?

Once again communicating with stakeholders to figure out what is most valuable to them and focus on shipping just that nothing more. Get hard (and preferably measurable) requirements. Do not leave anything to chance and do not make assumptions. When in doubt ask.

The benefit of communicating clearly with stakeholders will (1) help to identify value, (2) tear down organizational silos and (3) will allow for clear feedback. Once an MVP has been released stakeholders can give feedback on what they like and what they do not like. These suggestions can then easily be included in future iterations.

MVP for the win!

The MVP pattern enables you to deliver value quickly, allows one to innovate, and encourages communication with stakeholders. It does require discipline, consideration and balance. In the end, it can lead to a good product and can help to avoid unnecessary work. So, I'll leave you with this question...why build a ketchup cannon when all that was needed was a ketchup bottle?

How much code coverage is enough?

Stephen Leyva (He/Him) — Sat, 26 May 2018 01:35:48 +0000

I have always thought that code coverage can be looked at in a similar way as availability According to the SRE handbook, a system should be as available as it needs to be anything more is wasted effort for the value returned. In a similar way it may be possible to test 100% of your code but does it really return value for the effort it takes to implement? Google even aims for 85%. It is also worth noting language plays a big part in how practical and easy it is to implement tests. So I leave it to you how do you decide what coverage may be appropriate for a certain project?