Build vs. Buy ... Again?

I didn't anticipate talking about work on this blog. Mostly because of some vague fear brought about by those "Privacy in the Facebook Age" articles. Of course, I have always used my real name on the Internet since the days of Usenet groups. So, if any potential employer does happen to search for my name, they will likely learn all of my darkest secrets. Namely, that I am a D&D nerd, that I once wrote an amazingly unknown PnP RPG many years ago (which I still play) and that I have an unseemly attraction to video games.

I can live with that. Being a D&D nerd is one thing. Ranting about your company's business practices, or your boss, or co-workers in a public forum is another.

So, this isn't a rant or complaint, but there is an issue that regularly comes up for discussion in my company (and I am sure it does in many companies) and it tweaks me enough to feel the need to comment. That issue is the age-old question of Build vs. Buy. When you need a new system for data cleansing, or tracking shipments, or maintaining contact lists, do you buy a "turnkey" system, or do you get your developers started on a new project?

From my perspective as a software developer, I fall heavily into the "Build" camp. I am a developer and I want to develop software, not install, configure, customize and nanny software someone else wrote. On the other hand, software development is fraught with peril and the lore is littered with stories of companies spending years and millions of dollars on failed "enterprise" software projects... So if you are an exec, I can see the allure of buying a package off the shelf and it "just running".

I've noticed that when I talk to folks (in my company and others) about their buy decisions, they often say things like... "We had to have a product NOW, not in 8 months" or "We simply don't have the development staff to deal with a project this big" or "The cost of developing that software would have been to high."

How expensive is the package being considered? How fast do we have to get to market? How complex is the problem we are trying to solve? Are our developers up to the task of producing this software? Do we even have enough developers to produce the software?

Obviously, there is no single correct answer. Every case is complex. However, from years of experience watching how these decisions play out, I have come to this conclusion:

If the system you are considering is part of your core business competency, or is part of a package you want to sell or present to the public, then 9 times out of 10, you should start with the idea of building that system, and fall back on buying as a last resort. Here's why:

Turnkey Solutions Usually Aren't -- One of the big draws of buying pieces of a mission-critical solution is that you can get it up and running more quickly than if you spent the time building it. Sometimes this is true; you install the new package, do a couple quick configuration tweaks and it is producing worthwhile results.

Unfortunately, more often than not the story is install the package, do a couple of quick configuration tweaks, have problems with the security settings on your network, do some more tweaks, call customer support, they blame Microsoft, call Microsoft, they blame the software vendor, post on a forum, retweak the configuration, things seem to be working, but the results aren't as useful as you originally thought, now you have to customize the package, in some goofy proprietary scripting language, why couldn't they just allowed you to write a C# assembly, oh well, customization is done, results are good, users are complaining that system is slow, do some profiling, it is the package's weird batching system, call software vendor, they send consultant out...

Whether you build or buy, there is almost never instant gratification in the software world. You might balk at the idea of giving a team of developers 4 months to deliver a piece of functionality that you need today, but keep in mind that most off-the-shelf packages require lots of setup, configuration, and often outright customization before they can deliver useful results. I call this the "hidden work" of buying, because while you might meticulously track the time your developers take to build in-house solutions, few companies give the same level of scrutiny to the fact that Bob from the data team spent 6 months playing nursemaid to that QuikSolv package you bought expecting instant results.

Obviously, if there's hidden work associated with turning the key on your spiffy new solution, there must also be hidden costs. Whether it is the $250/hour consulting you have to purchase to get the solution customized enough to work in your environment, ongoing support costs, or the fact that years later, your Senior Developer still has to babysit the thing when it is at peak load, you're going to pay a heck of a lot more than sticker price for packages you buy.

You Are Buying What Someone Else Needs -- Another thing to consider when buying a software package is that you are just one customer out of many and your co-customers have different needs than you. You are splitting the development costs with these co-customers, but you are also splitting the development resources and paying for features that they need, but you don't.

In my experience, this is evidenced in two main ways. The first is the "Everything to Everyone" package. You just needed a sleek, web-based grid, so your company purchases "Ulti-Grid" based on a demo page and a quick trial. Once you start digging deeper into Ulti-Grid, you realize that it has this horrible, 100-page API and a host of features you will never use... and that ultimately make the features you will use more fragile. Whereas you just needed a web-based, grid with some shift/ctrl click capabilities, you got the titanic AJAX-enabled, super-scripty, WPF, WCF and WTF-capable grid from Hell.

Oh yeah, and when they update the package, all of your code breaks :P

The other issue is when you need support, or a hotfix, or would just like to see a set of features implemented, you aren't at the top of the queue. To be fair, most companies are pretty good at handling critical issues quickly when dealing with production systems, but if you find an issue during development, especially if it is a subtle issue, or is performance-related as opposed to just an outright exception... good luck.

Even Worse, You Aren't Buying What You Need -- If buying a package that has too many features doesn't bother you, then how do you feel about buying a package that fails to meet your needs? Software development is often a moving target. The business' needs change and our understanding of the problem changes. When that happens, don't be surprised if your plug and play package is all of a sudden lacking key features needed to integrate it with the rest of the system and then you are stuck waiting for a new feature release, adding complexity to the parts of the software you ARE building, and/or customizing the package... which is great business for the $250/hr consultants, but stinks for you.

Sometimes You Need To Know How To Make a Wheel -- The old saying goes, "Don't reinvent the wheel." Obviously, there are a lot of cases where this makes sense. Reusing code is the prime example and purchasing a package as opposed to building one is just another form of code reuse.

However, Jeff Atwood had an interesting take on this on his blog which was, "Don't reinvent the wheel unless you want to learn about wheels." To me, this makes a lot of sense, even in a cost and time-conscious business environment, there are skills and techniques your programmers need to have and they can't get those skills by taking classes, or reading, or implementing someone else's solution -- they need to build software. So if you want your software to have a nicer UI, you better start letting your developers build UI. If you want better data processing, you should give them a chance to build the data process and so on.

The decision to build or buy a piece of software is hard and it is often much easier for a non-technical manager to understand the benefits of buying a package (and the risks of building) as opposed to the converse. Do I believe you should build everything? No -- there truly isn't enough time or money to build every component in a large software project. However, the next time your company is faced with this decision, I hope that the hidden pitfalls of "buy" are exposed and "build" gets a fair shake.

Turns Out I Hate The Skill Guy

3rd Edition D&D, including 3.5 and its successor Pathfinder is pretty clear on how it deliniates the focus of a character. Ignoring specific class features, each class relies on a specific part of the game mechanics to define its role in an adventuring party. For instance, fighters have the best Base Attack Bonus and are the "Feat" class; mages and clerics are the "Spell" classes and rogues are the "Skill" class.

At first glance, this seems reasonable. Of course fighters have the most options in combat. Of course, wizards and priests solve problems with spells. And of course, when it comes time to pick a lock or disarm a trap, you are going to rely on the skills of the thief. Makes sense -- each class has a role and gives up some other important abilities to excel in its role.

But, over the years, I could never shake the idea that there was something inherently wrong with this mechanical split. The first thing that struck me was the fact that if the rogue was the "Skill Guy", there wasn't much room for anyone else in the party to have skills. At 2 skill points per level (plus intelligence bonus, of course), once you take spellcraft and maybe knowledge: arcane, there isn't much room for the wizened wizard who wants to be a history buff. Priests have it even worse, since they likely won't have INT as a primary stat. Because the rogue's niche is skills, the other classes just don't have enough skill points to go around, leaving wizards and clerics among the most uneducated characters in the game.

Then there is the concept of "class skills" which seriously limit which skills can be reasonably taken. The fighter’s class skills are climb, craft, handle animal, intimidate, jump, ride, and swim. You can take other skills, of course, but only at a penalty... and as noted before, skill points are already at a premium. Good luck if you want to be a warrior who is also a diplomat.

Certainly multiclassing helps with this situation, but it too comes with its share of pitfalls. In the case of mages and clerics, taking a level of rogue for the skill points makes no sense at all. Stylistically, it does not work for many characters and mechanically, the spellcasting level is inifitely more valuable than 8 skill points... especially when you take into account that many of the rogue's skills can be made obsolete with the proper choice of spells.

But still, your party probably needs a rogue, if only to gather information and deal with trapped chests and locked doors. And let's say your party is heading into an adventure littered with stuff for the rogue to do. There are NPCs with which to negotiate. There are traps to disarm and locks to pick. There are dangerous dungeon corridors with lots of listen checks and stealthy scouting...

All of which is a lot of action for the rogue. In the meantime, everyone else sits aound and probably waits for a blundered stealth check to thrust them into combat.

I call it the Netrunner Syndrome. When cyberpunk games were popular, almost all of them had a fairly detailed set of rules for hacking virtual reality computers. Netrunning was almost its own minigame, complete with skills, gear and mechanics. It was all very cool... for the player who was playing the netrunner. Everyone else's character sat around waiting for JimmyL33t to either return from his solo adventure with the ciritcal piece of data, or for his head to explode into jelly. Either way, all but one player was bored.

Scouting and other rogue duties aren't as bad as netrunning, but they can come close. When it is the rogue bartering and the rogue scouting ahead and the rogue listening at doors and the rogue disarming the traps and the rogue searching the room... it can get boring for the other five people at the table.

So after running Pathfinder for a few months, it turns out I hate the "skill guy" as a class concept. What would happen if we got rid of the rogue (and probably ranger) class, gave everyone something like 5-6 skill points each level and got rid of the idea of class skills. Class features for rogues would become feats (possibly with a limitation on the armor worn). That way, everyone would have part of the "skill guy" job. Mages and clerics could take many of the skills and knowledges they really ought to have. Scouting, stealth, negotiation and trap duties could be more evenly distributed among the PCs in a party and those wanting to be sneaky, fast killers could still do so by taking the proper feats.

Would a rogue-less Pathfinder game work? I'm not sure, but I may certainly try it.

D&D 4th Edition the next great supers game?

As I was chatting with a friend about the pros and cons of 4th edition D&D and how I could not possibly run a fantasy campaign with it (I will get into that later), an interesting thought struck me. Out of the box, 4th is remarkably close to a superhero game! All of the trappings are there. You have tons of powers, all of which are very mechanically similar, but with lots of status effects to differentiate them -- thereby simulating guns, lasers, claws and mutant powers with the same set of rules. With healing surges, you have very resilient characters (though you would have to find some way to activate them without a healer archetype). You have minions!

Heck, if you just renamed the classes and powers, you might be able to pass 4th Ed as written as a superhero game.

I wouldn't do that though. I think some modifications are in order to truly complete the transformation. I would likely ditch the concept of a single class/character and go for some kind of dual-spec system for a more mix and match approach to characters. So you would not be a "Fighter". You would be a Superstrong/Fire Blaster. I think this would allow more flexability and synergy in character builds. I think a slick way to handle super stats would be in order as well... not sure on that one though.

Otherwise, most of the rules would work as written. Sounds like a side project!!!

Doppelganger

I have a guilty habit of occasionally Googling my name... probably a bit out of narcissism (though as I near middle-age man, I am not sure there is much left to be narcissistic about), but also due to a morbid curiosity about the intellectual debris I have left in cyberspace, especially because I generally use my real name in my posts. Indeed, there are posts and questions on technical forums and gaming forums that strike up a twinge of embarrassment today.

Now keep in mind, my name isn't all that common. There just aren't that many Magouns in the world. So, I was a little surprised to find that there is in fact another Chris Magoun out there, living out west and working in various capacities in the gaming industry.

I was amused until it dawned on me: this dude is in his 20s, is single, living in California and working as a game designer... My God, my namesake has my ideal life!!! Stranger still is the fact that at this very moment, the other Chris Magoun is writing a blog post about how his namesake, the 40-year old programmer with four kids, is dragging him down!

Or not.

But that would be pretty funny, wouldn't it?

What is Wrong with The New X-Com?

Recently, 2K Games announced that they would be releasing a new X-Com game. At first, this sounds like great news. X-Com is a beloved franchise and its mix of base building and turn-based man-to-man combat has never truly been matched. Certainly, in a market filled with sports games and first-person shooters, a modern version of one of the best turn-based tactical games ever made will be an exciting release.

Except that it seems that the modernized version of the best turn-based tactical game in history would just happen to be a first person shooter!!?! Huh?

Yeah, the new XCOM game (hyphens and lower case are soooooo 1990s, or British, not sure which) will be a heavily story-drive FPS, along the lines of 2K Marin's last title, Bioshock.

Now, of course, this news tweaked the old, crotchety gamer in me and elicited the usual rants about "ruining the franchise", "dumbing down" and an old standby, "kids these days". But then I thought, "Well, Bioshock was an ok game, maybe a good game with the X-Com label, whatever the genre, will be neat."

Then I thought about X-Com Interceptor and Enforcer and threw up a little into my mouth...

Seriously though, there is nothing inherently wrong with a top-notch game maker scooping up an old franchise and reimagining it. If you think about it, the highly enjoyable hit, Borderlands, is pretty much Diablo skinned as an FPS. It is a great game because it is an FPS, written by a dev studio that specializes in FPS games, and it adds other elements that twist the formula just enough (looting and character development) to put the game over the top. So ultimately, it is ok for 2K to rethink XCOM and the result might be a pleasant surprise.

On the other hand, to those of us who know this venerable classic, the announcement of the new genre is still disappointing and part of me can't get over the fact that this seems like a cynical attempt slap a known franchise on a game that would otherwise have a hard time competing in a glutted market with the likes of Gears of War and Modern Warfare. Certainly the buzz of the licensing announcement... good and bad... cannot hurt the future sales of this game.

And the name XCOM sure beats Yet Another Shooter as far as titles go.

Perhaps someday the tables will be turned and someone will buy the rights to the name Modern Warfare and remake it as a puzzle RPG. Until then, it seems someone IS creating an honest-to-goodness remake of X-Com. Check out http://www.xenonauts.com/ and hope they make their release date of Christmas of this year.

After Action Report (PCs at War Part 3)

I spent last Thursday night running through some tests on my Risk-like battle system and we ran the game the next night. How did it go?

Well, the playtest went OK. I printed out some hex paper and cut-and-pasted two sheets together to make a map of the battlefield. I grabbed some color counters from my old copy of Stellar Conquest and started moving pieces and rolling dice.

The first lesson is that if you are going to use minis, you need BIG hexes. I printed 1" and 1.5" hexes and neither of these could deal with the number of units on the board. Ultimately, I went with counters and that worked fine on a 1" hex.

I played the first 6 or so turns over and over again, trying to get a turn sequence that worked. What I came up with was this:

1. Alert Phase -- In my particular scenario, the defenders are unprepared for the attack and are generally undisciplined. I divided the city into zones and every turn, I rolled to alert a different zone. For each hex in the zone to be alerted, I rolled a d6. On a 3+, the hex got a unit. When all zones had rolled to be alerted (after about 4-5 turns in), the palace would alert and the King and his guards would head out to battle.
2. Initiative -- Both sides roll a d6 and the highest roll can move its units first.
3. Move/Pin -- Each side can move all of its units one hex. The advantage to having initiative is that if you are in a hex with an enemy, or move into an enemy hex, you can choose to pin that enemy stack and they would be unable to move that turn.
4. Combat -- Any contested hex has a combat round. The combat is resolved in a Risk-like fashion. Each side gets a number of dice and then you compare dice highest to lowest. Maximum number of casualties in a round is 2.
5. Reinforcements -- If your side is eligible for reinforcements, you roll a number of d6 and on a 4+, you get a unit. For instance, if the allied forces attack through the main gate, they would be eligible for 4 dice and up to 4 new units each turn.

PCs could move and resolve an encounter any time during stages 2-4. Thus, they could wait and see how things progressed before moving, or they could preempt the larger units and move first. Each hex, I would also roll on a random encounter chart to see if they encountered anything "special" during the battle.

Thinking about it now, I think that pinning is a little too powerful, since a single unit can pin a whole stack. Also, there is a tendency for the forces to blob up a little too much. The most effective tactic would be to gather your forces into a single hex and just pound through your opponents' separate stacks. I think both of these issues could be tweaked out with a few small changes.

Friday's game, I have to admit being a little hesitant about my system, but decided to go with it in any case. The players decided to attack the harbor and the allied forces took two stacks -- one went straight toward the palace and the other protected the flank and the way back to the harbor.

The PCs traveled ahead of the flank protecting stack and hunted lone enemy patrols, each patrol we played a little battle using the Pathfinder rules. To scale the battles, I determined that the first enemy unit would be 1d4+2 enemies and that each additional unit would add 1d6 to that number. The PCs stuck to lone units (remember the enemies were alerting piecemeal) and moved from hex to hex, killing them... but using valuable spells and healing bursts in the process.

One thing that I like about this simple mini-game is that it does produce interesting situations. In our battle, the main force heading to the palace got stalled and bogged down, forcing the players to consider how best to support that stack and protect it from being overwhelmed.

Ultimately, the King and his cohort stormed out of the palace and forced the allied forces to pull back and regroup before throwing everyone into an epic final battle. We broke up before resolving that battle and we will resolve it next session in a giant Pathfinder battle...

Enemy Force

• Admetus the Corrupt -- 4th level fighter, riding a chariot drawn by 2 Shadow Hounds
• 2x Commander -- 2nd level fighter
• Commander -- 2nd level mage
• 46 troops

Allied Force

• 5 PCs
• Peter -- 2nd level cleric
• Orc Commander -- 3rd level fighter
• 55 troops

We are playing this man-to-man scale... should be fun.

Ultimately, I was happy with how it went. I think the weakest part was the individual encounters had by the PCs. The fights with the patrols were quick, but not very compelling and not enough interesting random encounters really appeared.

I do think the overall system is worthwhile as an easy way to put characters in a war situation without having it overwhelm the game. I will put together a copy of the rules and post them soon.

Where D&D Meets Risk (PCs at War Part 2)

Yesterday, I talked about the difficulties of putting PCs in the middle of a larger battle. I have such a situation coming up during this week's game and ideally, I'd like to give the players the feel that they are part of a large, chaotic battle involving hundreds of combatants, but still keep the game focussed on their characters.

This is not necessarily an easy task. My Pathfinder players are not interested in a wargame scenario and I am not excited about a "Covert Ops" scenario. I am hoping that somewhere in the middle of those two ideas is the right solution.

What I intend to try is to merge the concept of a super-light, Risk-style boardgame with a string of encounters for the PCs. So, this gives the players an idea of how the battle is progressing, where they are in relation to the fighting and where they are in relation to the major NPCs in the scenario. However, the underlying mechanics of the battle at large will be highly abstracted and the game will play out just like a series of encounters in a module.

As I write that, it strikes me as either a very cool idea, or a horrible failure waiting to happen... So, onto some specifics.

The map of the battlefield will be divided into 16 hexes. The allied forces can enter the board at one of three spaces, each one having certain advantages and disadvantages and each one requiring different levels of PC intervention. For instance:

• Main Gate -- Requires PCs to sneak into town, have an encounter with the gate guards and open the gate for the main force. This approach is the best from the standpoint of getting the most troops on the board quickly, but is farthest from the main goal, the Palace.
• Scale the Wall -- Requires PCs to fight a "Protect the Ladders" encounter with guards on the wall. This approach puts the allies in a tough starting position, but is very close to the Palace.
• Sea Approach -- Requires no PC intervention, and puts a number of allied troops on the board, but also alerts the enemy and gives them the ability to react to the allies very early.

Each turn, both forces place reinforcement units and move units on the board one hex. All special units and the PCs (which are represented by a single figure) can then move. The PCs draw or roll a random encounter and resolve it and then all other combat is resolved.

The random encounters are the meat of the scenario. They are based on whether the PCs are in allied, enemy or contested territory and they have the potential to change the disposition of the battle by adding or removing units from the map. PCs might ambush an enemy patrol and thus remove a unit from the board, or they might come across civilians willing to take up arms against the corrupt king, adding an allied unit.

I am going to write up encounters this evening and do a quick run through to see how it works out. Unfortunately, I have given myself only a single night to determine how this is going to play. We'll see...