fredag 23 september 2016

MtgForLife retrospective

One year ago, this blog shifted some focus towards people who can't afford Magic decks, let alone food or flue shots.
To give up a part of one's own luxury to support some unseen and unknown people around the world is not always an easy thing. Stepping out of the comfort zone is uncomfortable, and a common natural response is to be defensive, annoyed or even insulted by the implication that we are the entitled ones. Who is this guy to tell me what I should do with my cards? We wont save the world, so why even try?
The top voted comment in the #MtgForLife thread at /r/magicTCG/
This was new territory. Apart from some charities where Magic players help give scholarships to other players (like the awesome Gamers Helping Gamers foundation or the old Magic Scholarship Series), giving to people outside our bubble is not something we as Magic players had much history of doing.
We know about hating on the internet though ;) (from #MtgForLife reddit thread)
And we set the bar very high. From the few examples of Magic players raising money for a non-magic related causes I could find, the money raised were in the scale of a few hundred dollars. We wanted $10,000.

But, then again, the MtgUnderground community is awesome. There's not a lot of whining around here, and people rather got inspired to use their cards for a good cause. The word about the campaign spread well, even to the more mainstream Magic scene.
One thing I find inspiring about the MtgUnderground was that the donations by country didn't correlate to the number of visitors to the campaign from that country, but rather correlated well with how large the old school communities in those countries were. Make of that what you will.
"Other" are UK, Switzerland and Belgium btw.
A few people stood out with helping the ball rolling early on different social media sites. E.g. Greg Titcomb started his own raffle of perks and urged his followers at the @oldschoolmtg Instagram account to join the cause. Shaman Ben Perry spread the word relentlessly to his Twitter followers. He quickly recognized this as something connected not just to old school Magic, but to the MtgUnderground at large. There's more focus on the community than having the best decks or all the best cards here, so giving up a few cards for a good cause is very much in line with the mentality.
Of the larger sites, contributed a lot with both selling cards and donating the full entry from the Swedish national championships in Legacy. PucaTrade also jumped in on the cause; suggesting to their followers on social media to join the campaign, and posted a community spotlight article where they interviewed me about 93/94 magic and #MtgForLife.

So we actually reached the ambitious goal we had set out. All in all, we collected $12,692 in the 40 days we had crowd funding page active. That's more than thirty-two times the yearly gross domestic product per capita in The Central African Republic. It's a few years worth of salary for a nurse working in South Sudan. It's in the ballpark of vaccinating 1,250 kids against pneumonia (even with the current high price tag of the shots).
We might not have saved the world but we really did something. Of all the things I've done within the realm of Magic in the last 22 years, this is the one that counts the most by far. All you who contributed with donations and spreading the word; thank you so much.
So what happened next? People in the MtgUnderground kept the mindset going. The players in the last UK national championship in 93/94 this summer opted to have a larger entry fee to the tournament to give a portion of the proceeds to Doctors without Borders. The upcoming 93/94 tournament at BSK will donate half of the tournament fee to a charity of the winner's choice. And players generally in the MtgUnderground seem to care. Not by "having them in our thoughs" or being preachy, but actually trying to make some sort of effort every now and then to make fucked up situations slightly less abysmal.

Enjoy Magic. Enjoy the #mtgunderground. If you care more about people you haven't met than about winning a PPTQ, you belong here. If beer is a better compliment to a tournament than planeswalker points, you are welcome. You won't have to give up anything except your mindset. But if someone should happen to join MSF and teach a kid in a war-torn country to play MtG, I'll happily give them a Mox.

You're the inspiration.

onsdag 14 september 2016

Long run

"Nice to see shots of decks (like the last one) that aren't packing power. While power makes for the most impressive and awe-inspiring photos, not everyone has it and it's not the end-all of what the format is about. Play with what you have and what you have the means to acquire. 93/94 is a marathon."
- Matt Shields, comment on Thomas Nilsen's Weaving magical tales at the Adventurers' Guild House

No secret I agree with Matt. 93/94 is one of the absolute worst formats to play if you want some instant gratification and then move on to the next quick fix. Building a deck here is not a sprint, and it's up to you when decide when to stop. Or at least slow down. My stop sign for the Project M deck after a three year run was the Beta duals. The price tag was simply to high, and I decided to play the deck with basics instead (yeah, I could technically play Unlimited duals, but that's kinda missing the point with the deck).
And hey, I managed to top8 n00bcon 5 with this version of Project M before I had any duals nor Power cards in the deck (except a Juzam, which technically is five Power). I was the only player in the top8 who didn't play multiple Mana Drains btw. Good thing to restrict that one.
Some players slow down at Unlimited versions of cards, some slow down before any duals. But at a certain point, when you've managed to get your first 60, every new card you get for your deck is a big deal. A one-off dual counts. A second Erhnam Djinn counts. Those decks tell a story about the format that few other decks can do. You would probably never see a guy at a Legacy GP playing a deck with two Force of Wills as he couldn't afford the playset. There are no Dredge players at the top tables in a Vintage tournament with less than four Bazaars. And some players in even newer formats can flat out neglect to play with their decks before they have all the cards some list on the internet tell them they need. That's not how Magic was played in the old days, and that's not the way to play 93/94.

There were 21 players competing in Drammen a couple of weeks ago. Three of the players in the top8 played zero Power cards. One of the decks in the top8 that did play Power cards was this one:
Mads Gårdvik Kihl's A Deck
I will call this deck A Deck, because it is clearly not The Deck yet. It isn't an ordinary UW control either; it plays Cities of Brass and Fellwar Stones to gain access to Regrowth, and it only plays four wincons. This is a 3-color The Deck with less than half of the Power cards and some unconventional card choices, maybe due to availability. Pretty damn cool. And it placed third in the tournament.

But the real Mages of the People in the Top8 were Bjørn-Einar, Kenneth, and Thorbjørn.

I'm not sure what to call Kenneth's deck. I've had the chance to play against it once (at Arcon in Oslo where Kenneth ended up in the finals), and it is deceptively strong. It just kills all your stuff and attacks with huge creatures, and all the way it still somehow seems to play "fair" Magic. It kinda reminds me of ErhnamGeddon in play style, but has less low-impact cards (like elves and mana birds), and instead more fire and removal.
Kenneth's WR Midrange
Thorbjørn's TaxEdge incorporates the synergy between Relic Barrier and Winter Orb alongside the Land Tax / Land's Edge combo to make it more prison-combo than usual. Thorbjørn was one of the first adopters of 93/94 in Oslo, and he has been on TaxEdge ever since he started. I'm not sure if he'll ever want to take the plunge for a Mox or two. The deck clearly works wonders as it.
Thorbjørn's TaxEdge
And finally we have Bjørn-Einar's Sligh deck. Bjørn-Einar started playing Magic in 1994 and is one of the pioneers playing 93/94 over Skype. This was however his first ever IRL tournament, a mere 22 years after he first picked up Magic cards. Very impressive début!
Bjørn-Einar's Goblin Sligh
I had the chance to meet up with Bjørn-Einar last Saturday afternoon to grab a beer and a few games at a local pub. We discussed the Sligh archetype a little, and we had both ended up on the idea that Ydwen Efreet might be the best offensive three-drop in the deck. My latest build of Sligh had cut the Goblin Kings altogether (mostly they are either Gray Ogre or they die) to play the full playset Ydwen, and I saw that Bjørn-Einar's latest build also played them in multiples.
They won't swim over Moats though. That Goblin Balloon Brigade / Goblin Wizard combo did however do an amazing job keeping Spirit Linked Serra Angel at bay. Magic!
What else is going on around the world? Enough for a bullet point list:
  • There are 84 players signed up for the Eternal Weekend old school tournament in Ohio in late October so far! Damn impressive! I don't think that the first edition of the European Eternal Weekend will even have a 93/94 tournament this year. We do however have BSK to look forward to for us Scandinavians, taking place in early November. So far there's about 40 players signed up for that one. Would be cool to break 64 so we get a seven round swiss :) Anyone from Stockholm or Norway up for the challenge?
  • Danny Friedman posted an awesome format primer at his Understanding Ancestral Recall blog. I highly recommend checking it out! Great musings and tech, as always.
  • Geena keeps creating sweet content at Nomad Gamer, one of her latest posts are about the Moxen. Some interesting trivia and lore mixed in with the cards.
  • Guillaume Soucy updated the Argivian Restoration blog with his story from GP Montreal and the 93/94 side event event there. He also recently completed his P9, which of course is wicked rad (as we said in '94).
  • There is a whole other blog about 93/94 out there that I for some reason had missed until last week, The Wizard's Tower. Speaking of today's topic of powerless decks, Taylor's latest post Kitchen Table Black Magic have some more content on that note. If you only have time to read one of his posts now though, I would start with 93/94 Magic and Some Existentialism.
  • I put this last, as it should take some time to savor this one. Our Shaman Ben Perry's vulgar display of power on the MtgUnderground blog. That one is a month old, so maybe you already read it. In that case, it's good enough to read again.
No lack of content these days. What makes me happy is that even though we might have some slight differences in legal sets or restricted cards among some communities, that same 93/94 (or MtgUnderground) mentality is found with all the different players producing content about the format. That casual attitude and jovial approach to the game is far more important for "real 93/94" than having a Lotus in your deck will ever be.

fredag 9 september 2016

Weaving magical tales at the Adventurers' Guild House

Mages, perchance you wonder at this show;
But wonder on, till truth make all things plain.
This man is Cortex, if you would know;

No sorcerous ways are driven by vain

This man, with maelstrom, troll, and bush of thorn,
Presenteth moonshine; for, if you will know,
By moonshine did these mages think no scorn
To meet at Drammen's tomb, there, there to woo

/Mg out

My fellow companion The Brewmaster and I set off to the Guild House which lies in the outskirts of a little hamlet by a smooth running river to the west. We traveled by coach, and on board he handed me two different bottles of his brew. In return I offered a deck of cards which told the story of giant Djinns and animated constructs; ravaging trough the landscape in a berserker's rage during a thunderstorm, laying waste to anything in their path. He smirked as he studied the cards and felt the potent magic that resided within. This was going to be his first Taleweaving harnessing such arcane magic. I gave him some pointers on how to control the forces before I produced the deck I was going to use for my tale. It was a tale of earthen maelstroms and dwellers of the underground coming forth to claim the torn and fire swept landscape. A tale which I learned in an exchange with the True Master, Elof the Mighty.
Upon arrival in the hamlet we distributed our burdens to ready for the walk southward to The Guild House. We were let in through the heavy gates, and after ascending the long spiraling stairs we were greeted by Nossy, the host himself.

Firm handshakes and nods of acknowledgement were traded before we eyed the rest of crowd and exchanged pleasantries. The place oozed with magic, and I counted more than four fists of eager Taleweavers shuffling cards and sipping brew.

The host called me over the the counter, slid an item wrapped in cloth over its battered surface and said "I heard you were looking for this..." Unwrapping the piece of cloth I exposed a horned demonic figurine made of the blackest stone. The carvings were classical and the maker's runes were embossed on the base. "May I", I asked eagerly. "Yes, but If you spill any of that vile stuff on the food I'll have your head". Nossy drove his cleaver into to a slab of meat to make his point, then adding the pieces to the stew. I went to the far end of the counter, placed the figurine inside my Duster and put it on top of a pristine card. One drop of blood, archaic words and mystic gestures made the item dissolve, rendering it's appearance and potency onto the surface beneath. I slid the card into a spot in my binder completing a quad. Along with his brethren he made a row of perfect harmony despite the grave taint they bore.
In the first seating of five I met my travel mate. His weaving was a bit stuttering due to inexperience, and my tale was the better one. The Sailor from the outlands recorded the event and his rendition can be found here.

Second seating, The Bard.
We started off with some light banter and cheers, but as the story evolved we needed to concentrate on the weaving. The Bard seemed a little puzzled when his world suddenly was consumed in torrents of fire and his monstrous constructs melted into the ground. He paused for a bit, and it all dawned on him when the earth dwellers poured out from the very same spots to seal the tale.
Third seating, The Doomsayer.
His prophecy was that all beings with a beating heart would be swallowed by a pitch black whirlpool of agony, and the only thing resembling life was the ever shifting swarm of metal overseers. His storytelling was of a strict and corrective manner, trying to twist and turn the ways I told my tale. I cannot blame him, as I made his lines tame and invalid to a point where he could only watch with fascination as my fire and lightning engulfed everything.
The stew was ready and it was time for a break. I looked at some of The Sailor's maps. One map was very old and it showed a barren region of flatlands. The condition was great and held the initials of the cartographer. Succumbing to the affliction I caught in the black borderlands I handed him a pouch of rare gems and traded for the map. One might only wonder what treasures can be found by studying it...
Fourth seating, The Wildmage.
My friend voiced with defeatism that his story was not as good as mine. So true, I could easily make his best points hollow with the maelstroms and my ability to riposte his lines. He was telling a wild story about the Cultists of Tawnos at candlelit altars during the season of high mana, and their prayers for all consuming fires and rays of disintegration. I told a story with gruesome earth dwellers and rioting assembly workers taking over the world and slaughtering the cultists on the way.
Fifth seating, The Purist.
A former power monger who lost his way and turned to ascetism sat across the table. Still needing to feel the mana surges he told of purity and the knowledge found in books and libraries. He blabbered on and on about angels of righteousness soaring high above the vistas. The description of these angels finally got to me and made my jaw drop. I could only applaud his story.
I was voted the best Weaver before the final eight, and my hopes for spoils were growing. The crowd had become quite intoxicated and the spirits were high even though some travelers from afar had to depart early.

A storm was building outside when we sat down. The crowd huddled closer and The Bard started to tune his strings as corks popped and more beer foamed in the tankards. The Joker told a long tale of chivalry and purity. His angels and gargoyles were slowly but surely defiled by trolls and assembly workers.
The Bard was up for revenge in the next seating. He was leading with a surge of mana and crushing constructs, but his story stumbled in a slur of words and told me he'd rather play the lute than do any further Taleweaving this night.

For the last weaving The Doomsayer put together a brutal story of endless hoards of living metal raining from the skies, accompanied by the downpour hammering on the windows and The Bard riffing his lute like there was no tomorrow... It was a wild ambience and a great tale. Honors to the Doomsayer, Honors to The Innkeeper and to everyone who visited The Adventurers' Guild House.

People were ready for a jamboree, but I had to bid my farewells.
I entered the rain and faded into the darkness.


torsdag 1 september 2016

BSK 2016. Info.

"It will be night, and the rain will fall. Falling, it will be rain, but having fallen, it will be frost. And we will stand in the morass among the crumbling tall lilies, with darkness forced upon our lands, and the lilies will sigh one unto the other in the solemnity of their desolation."
  - Frozen Shade

September. We're clinging on to the lights. We still think of barbecues and trips to the ocean. But there's a splinter in the back our minds telling us that we kid ourselves. It's a work of desperation.

No need for lies anymore. Heavy hands unsleeve our summer Factories and replace them with autumn versions in our decks. The dark months are coming, and in their wake, BSK will follow.
BSK is one of the oldest annual 93/94 tournaments, second only to the Easter tournament at n00bcon. It started six years past, when it took place in a hotel bar. Five years ago we had moved to hotel rooms, and a couple of years later the tournament took up multiple suites at the hotel. Two years ago, we had outgrown the hotel rooms and moved to the site of the BSK gaming convention for the main tournament. Last year, the tournament that have since become the known as the Northern European championships in 93/94, was eventually taken down by Olle Råde after nine grueling hours of Magic. Olle wrote a report about the tournament two years ago (the year before he won), which you can read here.

The tournament is somewhat special in that it is one of the two tournaments each year that awards the winner a player-signed Giant Shark from The Dark; perhaps the most coveted price in 93/94 Magic. Any player who wins the Shark will be expected to always play it in their deck from that day on to show off their immaculate skill at old Magic.
What: The 7th annual BSK, glorious tournament for bragging rights in old school Magic.

When: Friday the 4th of November, starting at 17:00. Six or seven rounds of swiss followed by a top8.

Where: Sven Eriksonsgymnasiet in Borås, Sweden. The same location as the BSK gaming convention that same weekend. Note that this means that participants need to pay admission to the BSK gaming convention to play in the tournament. Also note that it means that you are not allowed drink while playing the Shark tournament. This is one of the more structured 93/94 tournaments in that aspect. We usually host other tournaments at the hotel rooms after the Shark tournament where alcohol is accepted, if you are so inclined. You can read musing about last years 93/94 sideevent at BSK here if interested.

Who: Anyone who has a deck are welcome to come and play. There is no stated upper limit for this tournament (unlike it was for e.g. n00bcon this year). Last year we were around 55 players.

Registration: The registration fee for the tournament is 100 sek (about €10). Half of the tournament fee will be given to charity. The other half will be used to cover trophies, pins and some random bonus prizes. If you're a member at, post in the BSK 2016 thread at the Old School forum (if you're not a member in the old school forum, send me an IM). Otherwise, send me a mail ( or comment here, and we'll put you on the list.

Prices: The winner gets a Giant Shark and all the glory that comes with it. Winner will also get to give half the tournament fees to charity (no, giving it to Berntsson does not qualify as charity ;)). Top8 gets some sort of trophies. Some random prices will most probably be handed out as well. At least someone should get some Halloween candy and a The Dark booster or two for flavor. Of course everyone gets a rad tournament pin to put on their hipster backpacks or crude playmats.

What else: The winner will be invited to a free Vintage Masters draft at Sunday, hosted by the BSK gaming convention people. Some sort of 93/94 side events will be hosted around the hotels in the area. The BSK Gaming convention will also host all kinds of other tournaments and games, not just Magic. Last year their National Championship tournament in Legacy had 114 players, so if you like slightly newer formats, you should check it out.

BSK mofos!

We'll end today's PSA with Martin Berlin's 5-0 decklist from the From Russia with Love swiss two weeks ago (tournament reports will come):
Tranquility is the new Wrath of God.

torsdag 25 augusti 2016

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 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.


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 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.


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.

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

  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.

  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.