Continuous deckbuilding

A couple of years back, I held an impromptu seminar on the Nash equilibrium. For those of you unfamiliar, it's a solution concept in a branch of mathematics called game theory; the thing Russel Crowe's character in A Beatiful Mind gets a prize for at the end of the movie. It’s also a fairly unfriendly and complex topic far removed from the line of work of the audience I presented it to.

Off the bat with a subtle Nash equilibrium / Magic card reference. This can only be good, right?

I wanted to test the waters. See how well I could handle a talk about a topic most people weren't a priori interested in; a topic which the audience had little prior knowledge about nor practical use for. I guess it went well enough; no one threw their underwear on the stage, but on the other hand, no one threw their underwear on the stage.

I’ve been thinking about this topic for a while. About building things.

// Here be Dragons

Now, what I do for a living other than ski boxing and screaming at trains, is IT consulting. I have a few reasonably tuned strings on that harp, with my main focus on testing and release management. The IT industry has changed a lot since back in the old school days of 93/94. Back then, it was somewhat feasible for a programmer to write a game or a fairly high-end program for public consumption and understand most of everything about how it worked. Go back another decade or so, and we're at a time when it wasn’t that uncommon for a single developer to write all parts of game - from music and story to game play dynamics and logic - often knowing exactly what part of the code used which parts of the machine's memory registers.

That's how you get Easter Eggs like this I suppose.

This is really not case anymore. Though we have much better tools to works with today, creating and releasing a major product is complex. I could write about how Knight Capital Holdings lost $465 million in 45 minutes because they failed to deploy new production code to their eighth server. Or mention how healthcare.gov wasn’t built to handle the proper load and prompted President Obama to issue an apology from the White House Rose Garden on US national television. Or just listen to people playing Magic Online complaining about buggy software until they threaten to ragequit over to Hearthstone.

Ain't easy being Worth.

But let’s leave that for some listicle to handle. Today, we go deep nerd. We’re going to look at how to create and deploy working software. Creating software is not unlike creating a Magic deck, so let's take the tools we use to build software and use them to build a deck instead. It’s old school Magic and software development processes in a ghastly topical blend. Buckle up mofos!

Of course we will.

Why?

Step one. Why? ”Always start with why.”

Why do we want to build this deck? In a larger context, this could be defined as an epic; essentially a large user story that can be broken down to a number of smaller user stories. A user story is one (or a few) sentences written in everyday language that captures the ”who”, ”what”, and ”why” of a project; in this case the deck. It is most commonly defined as ”As a <role>, I want <goal>, so that <benefit>”.

As an Old School Mtg player who enjoys trying different strategies, I want to build a monored Sligh deck, so that I can play it with friends and lend it out during tournaments.

As a Netflix user, I want to be able to resume a program I’ve previously watched, so that I won’t have to search the buffer whenever I return to a program.

As a Vintage player, I want a deck that have a favorable matchup against the most popular decks in the current meta, so that I can win tournaments with it.

Solid choice two years ago, but doesn't beat Mentors nor Eldrazis today.

This may sound like a no-brainer, but it is really not the case. People rarely think about why they do things. Why does Magic Online have an interface that many describe as unfriendly? Is it because we haven’t thought about who the intended user is? What’s the goal for the product in one setting? What would it be in five?

I’ve worked at a lot of projects where employees - certainly including myself - can’t explain exactly what that the product is. Or at the very least, we have different ideas of what it is, and what words mean. We need to find a common language and a common model everybody understands. As a smarter man than myself said, ”The worst bugs, the major technical debt, are mostly modelling errors”.

It will get worse over time.

What is a Magic card? If you work with software that use Magic cards - be it MTGO, TCGplayer, Gatherer search or whatever - there should probably only be one answer to that question. Both technical and domain experts in the project should understand it. Looking at it from a domain driven design (DDD) viewpoint, it’s probably a collection of objects (value objects and entities) bound together by a root entity.

The values objects and entities of a card will be different for different products. If we go to morphling.de to check out Vintage decks, those lists don’t care what edition the cards are from or what their rarity is. If we search for a card at the ChannelFireball store, those cards wouldn't need to store specific rule FAQs for the card (like they do at Gatherer search). And if we play a card in the Duel of the Planeswalkers app, that card doesn’t care about its real life price tag, but cares a lot about how the card interacts in an actual game of Magic.

Knowing the components we work with will eventually save us time and a help us avoid a myriad of bugs and refactoring. If we neither know why we do something nor what it is that we do, we’re in for a hard time down the road.

A Sorrow's Path, if you will.

Requirements

Let’s say we’ve reached a basic idea of the who, why, and what. Let’s build that Sligh deck I’ve been thinking about for a couple of months.

As an Old School Mtg player who enjoys trying different strategies, I want to build a monored Sligh deck, so that I can play it with friends and lend it out during tournaments.

That’s our epic user story. This story will then be broken down in smaller tasks with unambiguous requirements.

Software requirements can go deep, easily becoming a faceless set of rules no one at the team really cares about. On the other side of the coin, we might skip the requirements all together, or make them fluffy rants of uselessness that can’t reasonably be verified without bias (”The deck should be good”).

IEEE (Institute of Electrical and Electronics Engineers) define a requirements as

1. A condition or capability needed by a user to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
3. A documented representation of a condition or capability as in 1 or 2.

Yep. I will also humbly note that IEEE-830 defines Software Requirements Specifications, and that IEEE-829 defines Software Requirements as "A distinguishing characteristic of a software item (e.g., performance, portability, or functionality)."

Words and such. Here’s the deal though; when we’re creating something - anything - together, the requirements should be a collaboration tool.

Functional requirements!

Say that you and a couple of friends have decided to go on a road trip. When you meet up to talk about the trip, one of the friends has already booked all the hotels and pit stops, decided on which road to take, and booked you all in to The Gathering of the Juggalos at the end of the trip (yep, in this scenario you're friends with a juggalo). The guy then asks for your commitment and money to pay for your accommodations on the trip he planned.

The road trip now has a few feature requirements. Where to stay each night, where to travel, and what the end of the line will look like. This might make you feel less excited about the trip. It would probably be more enjoyable if you had collaborated with the requirements, in particular as you will commit a big part of your time to it. Maybe you know about a great bed and breakfast on the road that your friend didn’t even look up, or maybe you know a lot more about cars than your friend who already booked one. What if you don't care about magnets, and with a small detour you could have caught an unplugged session of Neurosis in addition to the Insane Clown Posse festival.

Everybody gets pitchforks.

When we talk about feature requirements in software development, I am a big fan of the Three Amigos approach. In a nutshell, it states that the requirements of the project should be written in collaboration between a feature developer, a tester, and someone with deep knowledge about the end user (e.g. a business analyst or designer). This gives us a more complete picture of the delivery, help us avoid a lot of communication problems down the road, and as a bonus increases the motivation and “ownership” of the end result. In many cases, we’ll also find out cheaper solutions to solve the problem, and squash a bunch of potential bugs already at the drawing board.

When we write the requirements, they should be unambiguous, testable and understandable for both technical and non-technical personnel. I think that it's a good idea to use some form of Gherkin syntax when writing requirements. It makes them easy to transform from plain text to testable code; using Cucumber, RBehave or similar tools. With Gherkin syntax, we write our requirements on Given-When-Then form. E.g. ”Given that I’m driving my car at crusing speed; When I press my foot on the break pedal; Then the car should slow down.”

It’s funny because this is kind of like a car and the banding ability is like collaboration.

If you are familiar with software development, you’ll recognize this as the first steps in Behaviour Driven Development (BDD), also known as Specification by Example. To let Dan North summarize the methodology: ”BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.”

Some requirements regarding the road trip are fairly unnecessary to state. At what time should you eat dinner each day? What color should the seats of the car have? These are either not pertinent to the experience of the trip, or will restrain your agility during it.

Let’s look at the very specific requirements that must be true for most every Magic deck. Things like

Given a constructed Magic deck,
When I count the number of cards in the main deck
Then that number must be at least 60

...and such. If we go deep enough, we see that the requirements could define things like what a Magic card even is (we don’t want to accidentally build a deck with Jack of Clubs or Charizad), or what constructed Magic is (”Hey, in 5-color you have to play like 300 cards!”, no one just screamed). But we are not trying to write Principia Mathematica here, we simply want to write requirements that makes sense to an end user. Testing of the smallest units of truth is done during the feature development part of the process (i.e. unit testing). What we're looking for here is something more like this:

Story: 93/94 Sligh deck
As an Old School Mtg player who enjoys trying different strategies
I want to build a monored Sligh deck
So that I can play it with friends and lend it out during tournaments

Scenario 1: We want to be able to lend the Sligh deck to other players in tournaments if we don't play it ourselves. As such, we want to have zero overlap between this deck and the Project M and Monogreen decks.
Given one player is playing the Project M deck
And one player is playing the Monogreen deck
When one player is playing the Sligh deck
Then all decks should be fully constructed without proxies

Scenario 2: We have access to a decent card pool, and should be able to build a solid Sligh deck without spending too much additional money on the project.
Given we need to buy cards to finish the Sligh deck
When we calculate the total cost for acquiring the cards
Then that sum cannot be higher than $100

Hey! Did you actually read that? Is anyone still here? I assume that the two guys still reading are Bjørn-Einar Bjartnes (who shares my unhealthy joy of both software development and building Sligh decks), and Shaman Ben Perry (who could just enjoy the absurd nihilism of writing 26 pages of software development theory on a supposed Magic blog, laughing in the face of reason and clickbaits). You’ll get a deck list in about 2000 words. Also, I guess that Ydwen Efreet is a criminally undervalued card if you want to go do one of those new-fangled buyout thingies (NB: Please don’t buyout Ydwen Efreet).

Nothing like a picture of a wall of text to alleviate the monotony of a wall of text. Did some syntax highlighting though.

Those requirements in the picture are important to make sure that we actually make a Sligh deck. Those are still very much what we call functional requirements, and easily testable.

There are some other requirements we should note as well, called non-functional requirements. These requirements are used to judge the operation of our product, rather than specific behaviors. In software development, this could be the average response time of pressing a like-button at Facebook. The number of people who could stream Stranger Things on Netflix without the video lagging for more than 1% of them. How frequently your Magic online client will crash. The most critical of the non-functional requirements are often referred to as the Key Performance Indicators (KPI) of the product.

If you like testing non-functional requirements, some stuff Netflix do is basically nerd porn.

Say that the best deck in 93/94 is U/R Burn (the most represented deck in Shark tournament top8s the last few years). If you want to build a deck that can beat U/R burn, it’s not that hard. You cram a bunch of life-gain, main deck circles of protection and cities in bottles, and build a pile that is solely made to make U/R Burn's life miserable. Being able to beat one deck is similar to only having to worry about a few hundred users. It's comparably not that hard to write a webpage that can handle a hundred or a few thousand users. But with each magnitude beyond that, you’ll face new problems. Writing an interactive webpage with millions or more daily users is a whole other bag of snakes.

This is deploying it to a larger market without load testing it. Obama doesn't approve.

Our non-functional requirements for the Sligh deck include that we should statistically win against a goldfish opponent at the latest turn seven with 14 out of 15 opening hands. On average, the winning turn should be before that. It says that we should deploy some interaction turn one at least 90% of our games. It says that we should have at least an X% chance of winning against deck Y.

Off to development

“About time to get that mo-fo'ing co-so of a deck. Why not just start here!?1” Because if we start here our twitter feed will become a peanut gallery of angry nerds, and we’ll lose a lot of revenue to Hearthstone due to buggy decks. Or some other analogy.

Your requirements should drive your implementation, not reflect it.

Just like a carpenter wouldn't grab a stack of wood and a hammer and start pounding away to build a chair, we can't just grab an IDE and swordfish away to build a webpage. If the chair were to be stable and fit with the rest of the furnishings, we need to first work out of what the finished product should look like. Write requirements on how to saw up the planks. Having documentation of the product and how to make it doesn't make the carpenter less of a craftsman. Give me and Ed Carpenter (real guy!) the exact same detailed instructions on how to make a chair, and I can assure you that Ed's will look better. Give Patrick Chapin and a random new player at the local FNM the same instructions to build a competitive standard deck, and Chapin will come out on top.

That is what happens when the brewmaster brew.

(Sidenote: It would be awesome to have Tha Gatherin playing a live session at n00bcon. Would anyone happen to know how much they would charge to play at a Swedish equivalence of Moe’s Tavern? Let my bidding start at $400 and a local couch to sleep on.)

The first step in building a 93/94 deck list may be to make sure that the deck is actually legal in the format.

TestIs9394MagicCard()
{
  foreach (card c in slighdeck)
  {
    Assert(contains(c, 9394LegalCards))
  }
}

TestNumberOfCardsInDeck()
{
  Assert(slighdeck.decksize() >= 60)
}

...and so on. These kind of tests are called unit tests. Unit tests are the lowest level of testing, verifying the smallest testable parts of the product. It’s written by developers in the same language as the feature code. In an ideal world, most every line of feature code have unit tests.

Starting with an empty deck list, of course all these tests will fail. But we write the tests firsts, and when they start passing we know that we're getting somewhere. Writing test before we start will actually speed up the development process a lot and help us avoid late surprises. The earlier we find the bugs, the cheaper they will be to fix.

Guess bugs are like Power in that aspect.

We want things to fail as soon as possible. Realizing our deck list only contains 59 cards is lot cheaper to fix before we place the order to buy the last cards. And it gets really expensive when we get disqualified presenting a 59-card deck just after they announced the top8 at our first Grand Prix.

As we want things to fail early, we could implement a few of the feature requirements already here as unit tests. Let’s write unit tests that check our mana curve. No need to wait until playtesting to see if we made mistakes in the theory.

TestNumberOfOneDropPermanents()
{
  Assert( (slighdeck.NumOfPermanentsWithManaCost(1) >= 8) && (slighdeck.NumOfPermanentsWithManacost(1) <= 13) )
}

We’ll do the same for all the examples in the feature requirements regarding mana costs and card types. Let’s write a deck list to make those tests green.

Make it green!

Now we enter the realm of creating solid decks. What separates the master carpenter from the novice woodcutter.

In deck building, current best practice is to approach the task with four sets of eyes. These are eerily similar to the best practices of creating software products.

I’m a big fan of George Baxter and the other pioneers in deck building theory from the 90s. But I think that the greatest contributor to the subject is Patrick Chapin. In his book Next Level Deckbuilding, he gives far deeper insight to the processes and art of deck building that I could ever hope to do here. In the book, Patrick defines the four paths as this:

• Top-Down. What is there?
• Bottom-Up. What is not there?
• Backwards. How did we get to the winning position? 
• Forward. What’s the gameplan from turn one and forward?

Top-Down. What's there? Good decks play good cards. We cannot entirely rely on mana curve with a complete disregard for card quality. Let’s start with adding 4 Lightning Bolts, 4 Chain Lightning, and 4 Mishra's Factory. As raw power level goes, we should heavily consider Blood Moon as a three-drop. We start here, and build around this.

If we're playing mono-red, we have access to a few powerful cards we can cast more easily than other decks. Ydwen Efreet is deceptively strong, and we will always have the right colored mana to cast Fork or Ball Lightning. Gauntlet of Might could pull a lot of weight here as well.

Bottom-Up. What's not there? What’s useless and inefficient? We might need to playtest to see this well, but we have a few hints already. The two-drops on the curve are sorely lacking. I wish I could play seven Ironclaw Orcs.

The powercreep these days...

Basically, the beatdown two-drops we get to choose from are Ironclaw Orcs, Atog, Kobold Taskmaster, Ank of Mishra, Copper Tablet, Goblin Rock Sled, or perhaps a one-off Raging River. Control-wise, we could add stuff like City in a Bottle, Fork, Shatter, and Chaos Orb. But we really want 6-8 ways to use our mana turn two aggressively. Maybe we could commit even more on one-drops to use all mana turn two. The lack of solid two-drops hurt, but it is not enough reason for us to pivot and scrap the deck.

What’s not there for our opponents? Life gain is lacking in the format. Apart from Mirror Universe and Ivory Tower, dealing damage here is basically the same as getting poison counters in the Modern format. You won't get rid of it. Ivory Tower and the red circle of protection could be an issue, but people don’t play those maindeck, and we should be able to race Mirror Universe. To handle the viable life gain alternatives, we should probably look to Manabarbs and Shatter/Detonate in the sideboard. Pyroclasm isn’t here. In the current meta, few or none play Moat or Wrath of God. This could help make the deck viable.

What else is not here? Looking at our requirements of not taking cards from our other assembled decks, we won’t play Mox Ruby, Black Lotus nor Library of Alexandria. Having a budget of less than $100 in new cards makes us unable to play Gauntlet of Might.

Might be that Dragon Whelp is a better 4-drop anyway...

Backwards. We burn out the opponent before they have the chance stabilize. We have zero cards in hand, and our lands are all tapped. This is round six or so. To get here, we have dealt at least 14 damage with creatures, and have a couple of burn spells to seal the deal. So the turn before that we attacked with a swarm of creatures, at least five damage. The creatures are small, so either we need evasion or to be able to destroy opposing Mishra's Factories. By turn six, opponent has had five land drops and drawn 13 cards, so we might need some disruption to get here.

If we have attacked for more than ten damage by turn five, we should have a lot of board presence turn four. Without moxen nor Lotus, everything above three-drops are curiosities. We'll only cast one or two four-drops before we win, so we don’t need many. Turn three we attack with two creatures. Hopefully a one-drop and a two drop. Could be two one-drops and a factory. Turn two we drop a threat or attack with a factory. Could also go for a one-drop creature and a bolt.

Forward: We need a land drop and threat turn one. If our land drop is Mishra’s Factory, it is much preferable to be able to use the mana than to not. Black Vise seems like an obvious include, maybe Brass Man as well? Turn two we attack with the Factory and our one-drop, or even better, play a two-drop. If we don’t have a factory, we need either two-drops or two one-drops to make our mana useful. Making our mana useless is how we lose, our cards are weak in a vacuum and we need tempo to win.

This might work.

I leave it as an exercise to the reader of examples of applying those rules to software development. But one concept is important enough to note in particular, what in Lean is called ”Acheiving Failure”. It affects deck lists, road trips, and software development.

As Eric Ries put it:

"We spend a lot of time planning. We even make contingency plans for what to do if the main plan goes wrong. But what if the plan goes right, and we still fail? This is the most dreaded kind of failure, because it tricks you into thinking that you’re in control and that you’re succeeding."

Forethought is 19/20.

We should always have focus on the actual value we're looking for. The product itself is secondary to the value of it; be it joy, profit or whatever. Here, the product is a monored 93/94 Sligh deck. The value is that we want to play it with friends and be able to lend it out during tournaments.

What if the deck is simply not competitive in the local market? What if a majority of the meta is Tax Edge with 4 maindeck Ivory Towers or Power Monolith combo? Then the value of lending it out during tournaments would be very slim as most anyone wouldn't be interested in borrowing it.

What if the deck is utterly unenjoyable for your friends and they don't want to play against it? Like if your play group enjoy casual kitchen table vintage, Duel Decks and such, and this one guy shows up with Draw-Go or Uba Stax. Sligh could possibly hit that point, as its game plan is to win before the opponent gets do do his or her thing. If we make a "perfect" Sligh deck that no-one want to face outside a tournament, we haven't got the value we looked for either.

Focus on value. If we realize that the product doesn't give the value we're looking for, pivot. We could just scrap the Sligh curve and go for midrange. Or maybe just build an Erhnam Burn'em or Dead Guy instead. No need to waste time and money on something that doesn't give us any benefit.

It's a bad thing if we realize that we've achieved failure after spending a long time and a lot of money acquiring all the cards. That's why we want to start small, and instead make continuous small improvements to our product. The first version we present might even lack core functionality; its main feature is for us to learn from the users so that we can make the next version better. In Lean startup methodology, this is what is called a Build-Measure-Learn loop.

The first thing we build is called a Minimum viable product (MVP). The MVP is defined as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort". This was the MVP for my Project M deck back in 2012:

63-card deck list on an airplane sick bag.

This is enough for the primary customer (in the case of this pet deck; me) to see what the deck could look like and figure out if it is something I'd like to take further. To get an overview of the expenses in creating the deck and look at the synergies. Bring it to a friend, ask them to look at it, and see what feedback I get. This deck list has some functionality in that I can learn a lot from it, but it of course lack one of the core functionalities of a deck; i.e. ability to play it (I didn't have the cards).

Feedback can be painful. Data help us avoid bias.

It seemed like a good plan to keep working on though, and step two was to create a deck list that I could build in the next couple of months. I know that the deck I'll play won't be the end-all be-all product, but if I waited to play the deck exactly as I wrote it on the paper bag, I'd have to wait over two years before playing it. And I would first then realize that the deck should probably be built differently (e.g. no Power Artifact combo).

Project M v1.0, January 2013.

If we're building a deck for a high-level tournament like the Pro Tour, then we have to own the build-measure-learn loop. We have a couple of weeks after spoiler season to come up with ideas, proxy together decks, playtest them, and then either scrap them or keep working on them. Build-playtest-learn, repeat until tournament. We'll have great advantage in a cross-functional team of deckbuilders, playertesters and strategist at our side.

Every new iteration should go quickly from learning to playing. How long does it take between that we realize that we  should cut 2 Swamps and 2 Plains for 4 City of Brass to improve the early game, to that we hold that new version of the deck in our hand?

Test and release

Let's go back to the Sligh deck.

The MVP for the Sligh deck.

After we've exhausted what we can learn with basic theory crafting, the next step is to take this to a sandbox environment and see how it plays. Testing in a local environment if you will. In this sandbox stage, it may be a good idea to use what in software development is know as mocking.

A mock object is a simulated object that mimic behavior of real objects. It could be a crash test dummy mimicking a human when testing car safety, proxy cards for playtesting, or a preconstructed reply from a function mimicking a data base request. We could test a lot of our functionality before we have everything in place.

What do we not need yet? Physical cards and a real opponent for two. Lets build the deck in an online deck builder to see how well it matches up against the goldfish opponent and how well it mulligans.

Those lands can't be right...

After doing this for a while, a couple of things get clearer. A first turn factory can do a good job as an attacker turn two, but as we don't have that much spells that cost one colorless, it basically takes both the the one-drop and the two-drop spot on the curve. The factory curve could often work better with turn one mountain + Goblin; turn two Factory + Goblin/Orc; turn 3 three-drop, or Bolt + attack with Factory.

Even as a one-drop colorless card, Brass Man seems underwhelming. We rarely have the mana to untap him. Many of our three-drops are also kinda slow; cards like Ball Lightning would better follow our game plan. Atog looks plain bad as well, in particular without the Brass Men.

Whenever we come up with a new idea to improve the deck (or when we've finished writing a few lines of software code) it should quickly become a part of the solution. Making this happen continuously all the way to the finished deck is called continuous delivery. That process aims at building, testing, and releasing software fast and frequently. To make this go safe and painless, we use build automation tools. Continuous integration tools like Jenkins or TeamCity helps us check in our code to a mainline shared by the team multiple times a day, while checking that the new changes didn't break the product too badly (e.g. by running unit tests and integration tests).

We rebuild to this:

This online deck builder is basically a continuous integration tool. It checks that I have the right amount of cards, that the deck is legal in the format, and can show me the mana curve as well as helping me draw sample hands.

Eventually the deck feels faster and more consistent against the goldfish. Time to take this to a proper testing environment where we can play it against real opponents.

Now, actually putting together a deck can go fairly fast if we have the structure and architecture in place. If we don't, it can take hours upon hours. Are our cards organized in binders in a way that help us find them quickly? Do we know where that fourth Thoughtseize we're pretty sure that we own could be? Have we spent time or resources on acquiring a solid card pool, or will we have to buy new components to build the deck (or start making proxies for this stage)? Do we have 75 matching sleeves somewhere?

Is this our data base?

This is of course the same issues that can face the release process step for our software. Our automated tools help. I feel that I could write quite a lot about this part of the process, as it is basically my day job. But I also realize that this is page 23, and we're close to 6,000 words already. So instead of writing an extra 3,000 words on version control, sideboard plans, release management tools, integration tests, and dependencies; we'll just take four bullet points. Then I'll show you my winning deck lists from last weekends tournament in Stockholm and an awesome Buster Keaton clip.

• Is it scary to make changes to your deck? Are you afraid it won't work? Do you want to spend days testing it manually before trying it out in a tournament? (Lacking automated test coverage)
• If you rebuild the deck and it doesn't work that well anymore, can you quickly return it to the previous build that worked? Have you thrown away your old deck list or traded away the cards? (Version control and rollback plans)
• Is it hard to build decks because you have to move cards from deck to the next all the time, or your decks shares a lot of cards between them? (Dependencies)
• Do you feel comfortable with your sideboard, knowing what to board in and out in most matchups? What could go wrong? (Risk analysis)

Ok, sweet. Here are the decks:

Constructed: Undead Party Crasher

Top8 Draft: URb Control

And here's Buster:

So now we have decided on the deck list, put together the deck, and taken it to the final testing environment before production, i.e. the real market. Think of this last testing environment (commonly known as "preprod") as a stage where we really think the deck will work, but we want to do a general verification before we take it to the Pro Tour. This is where we test our non-functional requirements with load testing and such. It is where we actually sleeve up the deck and play it against a gauntlet of real opponents before the tournament. How much we test here is dependent on risk, i.e. the probability of failures and the impact of those failures. Testing a completely new deck for the Pro Tour requires more effort than testing a net-decked build before a FNM.

The less testing we have to do manually here, the faster we can take the deck to production. If we have a team, we ask them to help us out to save time. If we can in some way automate the testing of our requirements, we do that in all cases it makes sense in terms of time and cost. We can reuse those tests every time we tweak our product, so it's an investment that will pay dividends down the road.

As for the Sligh deck, we have something we can use in production now. While it's not "done-done", it delivers the value we were looking for while not having any major bugs or other issues. We'll play this deck with friends, maybe lend it out during tournaments, and see when the benefits of changing the deck further will be worth the cost of doing so. The first step will probably be to replace two Shatters with Detonates and the Digging Teams with Goblin Artisans and Goblins of the Flarg. After that we try to find a second Goblin King. The build-measure-learn loop never stops. We will continuously tweak this deck as long as there's joy in using it.

93/94 Sligh

Ok, so this was a very long and kinda weird post. You'll get those from time to time. If you got all the way down here, well done! Maybe you picked up on something. Maybe you got some ideas on how to work with software development. Perhaps you got some new plans for deck building. Or maybe you just picked up on the dangers of booking a road trip with a juggalo.