Steve-Sedlmayr-game-mechanic-102011

M’B-Bot GDD Notes
——————————-

Summary

A light, social RPG featuring a beat-boxing robot that appeals to all audiences. The game is highly entertaining foremost, but explores social and cultural themes, such as economic justice, the history of jazz, the roots of hip hop, and sustainable communities at the same time. Built in Flex & ActionScript, deployed via Air and integrated with Facebook.

Story Synopsis

m’B-Bot is a beat-boxing robot who lives in BeBopotron, a vaguely American metropolis in an alternate reality where everyone is a musical robot. Think Machinarium meets GTA in an all-ages appropriate and somewhat futuristic setting. m’B-Bot’s age will not be specified, but it is implied that he is an ingenue in the city. His nemesis, though he does not know it when he arrives, is DigiD, criminal impresario of evil in BeBopotron. DigiD stands for all negative values in the game: greed over cultural and community good; gluttony over moderation; short-term profit over sustainability, etc. In short, he represents all of the vices, institutions and practices that have gotten the human race into it’s currently straitened situation.

m’B-Bot arrives in the city penniless and with no professional skills and must find a way to make a living, or his battery will run down and he will shut off permanently. He starts beat-box performances on the street for spare credits. He eventually gets noticed by the locals who realize his unique talents and they send him off on various errands and missions, earning him ever-increasing respect points (RP) and credits, and improving BeBopotron.

m’B-Bot’s adventures involve cleaning up and renewing neighborhoods, connecting communities, creating self-sufficient sustainability, creating alternatives to crime, generally helping people, learning and educating about history and music, and righting economic injustices. Although not always directly, standing in his way around every turn to block, stymie and obfuscate is the ever nefarious DigiD and his DigiDrones.

Milieu

The environment is American urban, rundown and slightly futuristic, but not postapocalyptic like Borderlands, Fallout 3, Machinarium, et al. As the player improves neighborhoods, the environment changes to be dazzlingly futuristic in an understated, contemporary way a la Mass Effect. In the rundown mode the environment might be more industrial and even steampunkish. In the utopian mode, everything is streamlined and plasmic. Will have to avoid looking too much like a shopping mall. In the rundown mode, there will be more chains (all alluding to DigiD indirectly in the name), trash, grime, pollution, traffic, homeless and sick robots, et cetera. In utopian mode these things will be gone. The chains will be replaced by local shops.

The robots of BeBopotron are musical, so it should feature a variety of robot ‘genres’ – jazz, bluegrass, griot, pop, etc. and this should generally inform the game design. Genres should generally be those that contributed to the growth of hip hop. There may also be breakdancing robots in the game.

Basic Gameplay Mechanic

The basic gameplay mechanic consists of essentially a mini-game involving making m’B-Bot beat box with the keyboard and mouse. The player beatboxes in a variety of ways to earn RP and level up. The visible portion of this control will consist of 2 parts.

The first part is a horizontal table at the upper left of the gameplay area consisting of 2 rows of 10 columns. The first row is an indicator of keys: either QWERT YUIOP or the numerals 1-0 or WER ASDF ZXC at the user’s option. The second row consists of symbols corresponding to beatbox moves, which players can configure as they like. The total number of moves might be boosted by unlocked moves or custom moves the user puts together with a simple editor and move system. Users might also have a special move generated by the construction of their avatar. The move symbols will be simple line drawings of a mouth in the position needed to make the sound, augmented as necessary by arrows or icons to differentiate similar moves.

The second part is a circular track similar to the track in Fable II for making expressions, except circular rather than semicircular. Inside the circle will be an animated ‘close-up’ of the avatar’s mouth beatboxing.

To beatbox, the user will hold down one of the move keys. As they do so, a green bar will fill the beat wheel and quickly degrade, revealing a more slowly degrading yellow bar and a static red bar under that. At the same time, as in Fable II, a ball will circle the track rapidly. The user must click while holding down the move key and while the ball is on the green bar for the maximum score, with lesser modifiers for the yellow and red bars. As the user levels up, the ball will move faster and there may be multiple degrading green bars within the beat wheel.

The control is known as the B.U.D.D.H.A, or Beatbox University Downright Digital HUD Apparatus, also known as the buddhatron. The Buddhatron should start out grungy like BeBopotron, and improve to become shiny and plasmic, either gradually as a subtle indicator of game completion, or morphing slowly in response to the state of the current street. Being a HUD, it should only be visible when requested by the user while roaming, unless it is required for a mission, when it will be mandatory. The user obtains the Buddhatron after finishing a tutorial at Beatbox University.

In addition to configured and avatar-native (special) moves, NPCs may also have unique special moves, and users may acquire additional special moves by augmenting upgrade slots with hardware such as scratch tables, EQs, autotuners, amplifiers, vocalizers and the like, and possibly breakdancing moves.

Gameplay Overview

The player beatboxes to earn respect points and improve the community. Ideally the game should be playable in arcade, challenge and story modes. Challenge mode will allow the player to beatbox against friends for respect points. Arcade mode will serve up a subset of available missions for the user to play, but will not save any progress besides perhaps a high score per session.

The main mode is story mode, in which the user engages in a number of different types of missions to improve BeBopotron.

Ideas for different kinds of mission include:

- Simon-says: an opponent does 1 move, player matches; the opponent does 2 moves, et cetera. In story mode the round ends after a certain number of moves. In challenge, the first to fail (host or challenger) loses. In arcade, the round ends when a move is missed. There might be a variation in which the user has to match a percentage.
- Beat challenge: freeform beatboxing but in rhythm to a beat. If a certain number of moves in a row are out of synch, the round ends. Play a certain amount of time or to an RP target, or open-ended for max RP.
- Freeform beatbox challenge – target a certain amount of RP
- Versus beatbox challenge – either timed or first to RP
- Waypoint beatbox race – race to different points and perform the moves specified in a certain time
- Driveby beatbox – pass by a specific location quickly and perform a specific series of moves
- Scavenger hunt – go to specified locations and unlock items with specified moves
- Hidden loot – find grafitti of a series of moves and perform them to unlock the loot

Goals

- Appeal to all ages
- Appeal to all genders
- Appeal to all ethnicities
- Bust genres
- Bust platforms
- Create innovative gameplay
- Educate about social issues and a little about the history of hip hop without seeming heavy handed

How the Goals Will Be Met

#Appeal to all ages:

- Make the gameplay accessible to a younger audience but challenging enough for adults.
- The alternate reality populated by robots is one that is familiar to and popular with most generations. The anthropomorphizing of machines is a good proxy for a similar device, anthropmorphic animals, without seeming too childish. This makes it a good fixture both for memes targeted at children as well as for exploring more sophisticated ones like the toxicity of the built environment and sustainability. It also allows for the usage of a milieu that is more likely to appeal to adults.
- Encode different ‘rating channels’ in the content. For instance, in the movie The Amazing Mr. Fox, the word ‘cuss’ is used in a Brechtian way to accomplish this very thing. While the content was safe for children, using it anywhere an actual cuss word would be used added an layer of adult humor to the film.
- Hip hop itself has been around nearly four decades, meaning it has fans ranging from roughly 5-10 years old to as old as 50+.

#Appeal to all genders:

- Again, robots are key. Since robots are genderless,

Presentation Tier Tech

Server Tech

Revenue Model

Free-to-play with virtual currency for functional and decorative items; possibly some consumables as well. Plan to use Offerpal.

Social Distribution Channel

http://chitin.googlecode.com/svn/trunk/

http://www.mikechambers.com/blog/

He won’t be announcing his results until next week, but I downloaded the entries from his gitHub repo and did a quick run through in IE8/Windows 7 Ultimate 64-bit on a 2.2 GHz duo core laptop with 4GB RAM, and here were the results I came up with myself (I didn’t do any validation):

//Me -> 24 ms
//import entries.AaronSpjut.ProximityManager; // -> 16 ms
//import entries.AndrewTraviss.ProximityManager; // -> 11 ms
//import entries.ArnaudGatouillat.ProximityManager; // -> 6 ms
//import entries.BertrandLarrieu.ProximityManager; // -> 7 ms
//import entries.CayGarrido.one.ProximityManager; // -> 12 ms
//import entries.CayGarrido.two.ProximityManager; // -> 13 ms
//import entries.DanielKerner.one.ProximityManager; // -> 39 ms
//import entries.DanielKerner.two.ProximityManager; // -> 32 ms
//import entries.GrantSkinner.ProximityManager; // -> 6 ms
//import entries.GregoryPelletier.ProximityManager; // -> 11 ms
//import entries.HuyeTueDao.ProximityManager; // -> 12 ms
//import entries.IainLobb.ProximityManager; // -> 11 ms
//import entries.IanThomas.one.ProximityManager; // -> 13 ms
//import entries.IanThomas.two.ProximityManager; // -> 45 ms
//import entries.JeanPhilippeAuclair.ProximityManager; // -> 9 ms
//import entries.JimCheng.ProximityManager; // -> 7 ms
//import entries.JonasMonnier.ProximityManager; // -> 8 ms
//import entries.KermitHu.ProximityManager; // -> 100 ms
//import entries.MarcinSzczepanski.ProximityManager; // -> 8 ms
//import entries.MarkStarling.ProximityManager; // -> 15 ms
//import entries.MihaiAlexandruBirsan.ProximityManager; // -> 31 ms
//import entries.MikeChambers.ProximityManager; // -> 10 ms
//import entries.PhillipChertok.ProximityManager; // -> 17 ms
//import entries.RossGerbasi.ProximityManager; // -> 26 ms
//import entries.SeanChristmann.ProximityManager; // -> 8 ms
//import entries.VladimirAngelov.ProximityManager; // -> 10 ms
//import entries.WaiLam.ProximityManager; // -> 9 ms

There were a surprising number of entries under 10 ms; I will have to do some digging and learn some new codes this weekend. Ah well, at least I wasn’t dead last; I’m glad I participated .

Before I blog about that, I’d like to post an example-based tutorial about an application modularity/user interface library I’ve written. And before I do that, I’d like to ruminate about a recent post by Joel Spolsky on his well-known blog Joel on Software titled “The Duct Tape Programmer”.

Before I start pontificating, in fact before I even state a position or describe the article, I have to make the obligatory geek obeisances: I highly respect Joel Spolsky, his blog and the Stack Overflow site. Which, of course, is an obvious telegraph that I disagree with his position, since no geek kowtows respectfully to a more senior or accomplished engineer except as a prelude to potent disagreement (unless as a postscript to successfully implementing that engineer’s public code). I also have to say, in the interest of full disclosure, that I have not read the book Joel is referring to in his post, Coders at Work. However, Joel being the talented blogger he is, the content of his post stands on its own, and merits discussion independently of its references.

I highly recommend reading his post first here, then coming back to finish this post:

http://www.joelonsoftware.com/items/2009/09/23.html

If that’s too much work for you, the gist of his article is that quality code (which he appears to think is over-engineered by definition) is fundamentally inimical to timely code. Moreover, he posits a mythical hero, “The Duct Tape Programmer”, a swashbuckling, sort of Errol-Flynn-meets-nerd-next-door type, crossed with Nietszche’s superman, and a dollop of Don Johnson, circa Miami Vice, a la carte, as a magical panacea to every deadline dilemma and architecture imbroglio. These guys are a superior category of coder, mind you; they are “the software world equivalent of pretty boys… those breathtakingly good-looking young men who can roll out of bed, without shaving, without combing their hair, and without brushing their teeth, and get on the subway in yesterday’s dirty clothes and look beautiful, because that’s who they are.” The rest of us are “architectural astronauts”, and if we condescend to consider design patterns, TDD, OOP or “any kind of coding technique that’s even slightly complicated”—basically any forward development in software engineering over the past 2 decades, which, it turns out, are all just fads—well, then we’re bullies, or just plain frigtards.

However, never fear. Just load up a couple of these beautiful, chimeric cowboy Adonises like proverbial silver bullets into the Colt revolver of Duct Tape Programming (cue trumpets), and fire them with spaghetti-Western-style bravado at that werewolf of looming release dates, and presto-change-o, your frigtard convention will be blown to smithereens, and your product will ship with full functionality and on time. There’s one glaring problem with this allegory: it has almost no correspondence to reality, at least in my humble experience. In other words, to channel Penn and Teller for a moment: it’s bullshit.

The following blogs have done a fairly good job of debunking this myth on their own, with varying degrees of agreement or disagreement (mostly disagreement) with the original argument:

http://blog.objectmentor.com/articles/2009/09/24/the-duct-tape-programmer
http://jeffreypalermo.com/blog/debunking-the-duct-tape-programmer/
http://java.dzone.com/articles/duct-tape-programming
http://www.markhneedham.com/blog/2009/09/26/the-duct-tape-programmer-some-thoughts/

However, the implications of this article are so fundamental to the craft of software development, and impinge on issues that come up so frequently on projects, that I feel compelled to answer them independently, if only to clarify and codify for myself my personal views on these issues, and why. First, I’d like to take the inductive tack and talk about my personal experience with duct tape programming. Before I do I need to make another disclosure: having worked with both, I don’t like pretty boys or cowboys.

Duct tape programmers in my experience

To be perfectly blunt, every single piece of duct tape programming I’ve ever run across has been an unmitigated piece of crap. Actually, make that shit. Steaming, days-old, maggot-infested, rotting shit sitting at the bottom of a construction site port-o-john where the workers—who all have colorectal cancer—eat lunch every day at a nearby taco truck that serves only carnitas burritos with extra salsa and sour cream. I don’t mean by this simply that this code is hard to follow, or poorly commented, or has lots of extra line returns randomly and inexplicably sprinkled throughout it, or that it has oodles of orphaned and commented code, or its member instances and local variables are all named with cryptic and completely unhelpful monikers like “z3″ and “testVar” and “googlySparkleTron”.

I will admit that I’m a nazi when it comes to code cleanliness. Naming conventions and good syntax and formatting habits make for more legible code, and that’s really the point. There’s a misconception that programs are written for devices; they aren’t. If that were true, we would write code in binary. Software is written to run on devices, to be sure; but it’s written for developers. The aim of most of the big advances in coding methodology, like OOP and design patterns, has been to make code easier to understand for developers, which in turn frees them up to build bigger, more complex applications with more features. And legibility is certainly important just from a purely practical angle. It can mean the difference between deciphering a class in a few minutes with a quick glance at its interface as opposed to slogging through it for an hour, wondering the whole time which particular kind of crack the author was smoking when it was written.

But that’s still only syntax, and it’s a minor element compared to the other, even deeper things usually wrong with this code. For instance, class instances that require multiple external calls to do something that could be accomplished with a single external call that encapsulates the remaining operations in private template methods. Or a class that requires a wonky, fragile, externally loaded ad-hoc XML structure to run properly. Why? Because that’s the first thing that came to mind for our shiny, happy Duct Tape Programmer, and he or she just could not be bothered with five minutes of that annoying little trifle we call thinking to tease out an even marginally better solution.

Why? Here’s one possible theory. In my experience coders that fall into the duct tape category are often obsessed with looking good to non-coders. They’re glory hounds. And the easiest way to do that is to make people think that you’re some sort of genius speed coder. Speed coders, by the way, are even more chimeric—I don’t think I’ve ever met a single bona fide speed coder. I’m not saying they don’t exist, I just have never met one. Anyway, this particular kind of Duct Tape Programmer knows that the nuances of actually getting a product to ship will be lost on laypeople. So if the class they supposedly authored to perfection in a half hour flat is actually bug-ridden and requires 4 hours of additional love from another engineer—sometimes more senior, but not always—just to be good enough for testing (let alone release), an engineer who is not a glory hound because he has nothing to prove and doesn’t trumpet his every success loudly to any and all who will listen, but instead toils quietly in the background while the Duct Tape Programmer leaves early for the third time this week for yet another ‘appointment’ or ‘errand’, it doesn’t matter.

In fact, it’s all the better for him, because everyone will attribute the half hour to him and take it at face value that his code was fully functional at the first crack, which he repeats every chance he can, while chalking up the long hours the other engineer has to put in to make it actually run to obsessive compulsion, greed if he’s an hourly contractor, and/or slowness, which to those who don’t know any better equals incompetence. Rarely if ever will a non-technical person credit long hours to something positive like a passion for a bug-free, positive user experience. The more brownie points that can be racked up with the chickens, the more you can make yourself look like the coder version of the late Bob Ross (you know, that white guy with the hippie fro that used to crank out oil paintings of idyllic forests in half an hour on PBS), the better. You can spot these guys easily because they often inject flashy words like ‘rockstar’, ‘ninja’, ‘guru’ or ‘god’ into their titles in email signatures and on personal business cards, as in: ‘UI Rockstar’; ‘Flash Ninja’ ; ‘Java Guru’; or ‘XAML God’. You know who you are. By the way, the douchebag quotient of one of the above titles is the equivalent to wearing a Bluetooth headset in public while rollerblading in spandex. It’s. That. Bad. PSA.

Now, I don’t want to be guilty of the same generalizations I am criticizing and the above isn’t always true; which brings me to the next point.

3 flavors of duct tape programmers

In my experience there are 3 kinds of duct tape programmers.

The first kind are simply junior engineers. We all go through this phase in the first few years of our career to varying degrees, especially in the realm of UI engineering in general and Flash platform development in particular, which seems to attract a lot of self-taught software engineers, like myself. I would imagine it to be less common among freshly minted computer science graduates, but who knows. Usually these engineers have 3 years or less of professional experience. They are understandably eager to demonstrate their worth to the team. Their head is swimming with all sorts of new concepts that they are equally as eager to try out, but they don’t have much experience, so their toolkit and instincts are limited. To an extent, this is the perennial state of all software engineers, because the project and the technology is always changing. But you have to start somewhere, and for junior engineers this condition is particularly acute. I can say this with a certain amount of confidence, because with 5-6 years of experience as a developer and another 3 before that as a web designer, I’m just barely considered a senior developer myself.

If this person is humble and open to advice, and most importantly, not afraid to admit when she is incorrect or does not know something, I would argue she is still a duct tape programmer (note the lack of initial caps), but not of the kind Joel Spolsky describes. She codes in a duct tape fashion simply because that is the best way she knows how to do things. If you give her unsolicited advice about how to do something more efficiently, she’ll listen genuinely and say something like, “Wow, thanks. I’ll have to try that out next time.” And the next time she has a chance, she will try it.

If this same person is instead an attention-seeking asshole, who despite his lack of experience claims that he has worked with every technology or language any other developer of any skill or experience level ever mentions in passing on a lunch break, is obsessed with popularity and is a pompous smartass to boot, then you’ve got your Duct Tape Programmer. I don’t know about you, but I often have an urge to punch this person in the face repeatedly for no immediately apparent reason. This person is probably under 25, but if some grizzled old hacker reminisces about playing around with the first PDP-11, he will invariably chime in. “Oh yeah, I played around with one of those too, it was pretty cool. My dad had one of those.” Any one of the claims he makes might be true for all you know, but there are so many of them that the probability of them all being true is so unlikely that it threatens to rip the fabric of space-time asunder. You find yourself wondering, “If this kid is such a prodigy, why is he working here? Shouldn’t he be a professor emeritus at MIT or something?” Maybe he’s just slumming with us ordinary mortals. If ever you make the mistake of offering advice about something, he’ll be visibly annoyed and usually give you the brush off.

The second kind of duct tape programmer is the lifelong hacker. Of course, quite a few geeks come in this flavor, of all ages and backgrounds. The one I’m specifically referring to is usually about the same age as the junior engineer. The main difference between this guy and the previous character is that he really did play around with his dad’s (or more likely granddad’s) PDP-11 when he was eight. You know this is probably true, because he doesn’t advertise it. It just kind of slips out when you’re talking about other things. This person isn’t a pretentious asshole, so again is not a Duct Tape Programmer, but simply a duct tape programmer. This guy, even though he’s much more experienced than the junior engineer, is a duct tape programmer because it’s simply in his nature as a pure blood hacker from birth. Even though he has a day job as an engineer, he isn’t really an engineer; he’s a hacker.

Like Joel Spolsky with regards to the Duct Tape Programmer, this is not an insult; I have deep respect for this person. However, he is prone to making some of the same mistakes that the junior engineer does, because he tends to be a little myopic; all he sees is the project currently in front of him. As a hacker, rather than an engineer, he doesn’t care very much about quality. All he is concerned with is pure function, because that’s how a hacker operates: figure something out, then move on to the next thing. Often, this person’s engineering gig is just a day job to support his hacking habit. He just wants to hammer out his code as quickly as possible so he can leave at 5 and go play with his new netbook he cobbled together out of discarded parts running Debian with a tweaked kernel. The big difference is that if you can convince him there is a better way to do things, he’ll actually give it a go, and won’t complain about it. As a hacker, he can’t resist trying something new. He has an unbounded enthusiasm for new ideas. If, at the end of the project, he disagrees with any part of the methodology, he’ll make it known, but devoid of ire, pomp or rancor of any kind. What he will give you is a reasoned response why. If he learned anything from the new methodology, he’ll make that known too, and you can be absolutely certain he’ll continue to use those parts in the future.

The third and last kind of duct tape programmer is simply a junior engineer all grown up into a senior engineer. Except, unlike the rest of his colleagues, who grew out of their duct tape, cowboy-code-slinging, caveman debugging days, he still clings to his old ways with the desperation of a crack-head down to his last rock. The difference between this character and the first kind of duct tape programmer is that there is rarely a Dr. Jekyll version. This guy is even worse than his junior counterpart, because he has the seniority to throw his weight around, and when he doesn’t get his way he often throws actual temper tantrums. If you run across this guy, run as fast as you can in the opposite direction. Fire him if you can. I’m not kidding. He has all of the flaws of the junior version, but blown up to outsize proportions. This personality is very difficult to work with, especially under tight deadline pressure. So much time is wasted wrangling his ego that your product will probably ship faster without him, and be better in quality.

Now, lest you think the above portrait sketches are derived from my imagination, or are composites of various people I’ve worked with, know that I have actually worked with one or more concrete, in-the-flesh examples of each of these discrete personality types, and although I will not name them, I could quite readily. I’m guessing that most developers with more than a few years of experience could identify at least one specimen of each of the above personality types from their own experience.

And don’t get me wrong: I’ve had positive experiences, not just with the junior engineers of the humble variety and the born hackers, but even with the Duct Tape Programmers (let’s just call them DTPs from here on out) of both the junior and senior varieties. For instance, on one job I had to code a 360-degree viewer with a scrub control from a 30 frame FLV. The logic of my code was perfect, totally flawless. I was very proud of my little widget. Unfortunately, the performance was quite choppy. The problem was that, because it was a video, in order to scrub to the appropriate frame, the video literally had to seek to the appropriate frame. The overhead incurred was enough that there was a half second delay or so, enough to be annoying and register as visible choppiness. Take me at my word that the code was perfect; there wasn’t any room for improvement in the algorithm.

To make matters worse, this was at an ad agency, and as designers do at agencies when these sorts of issues occur, one particular designer apparated, Harry Potter style, out of thin air to bug me about it at intervals of roughly 27 seconds. I literally had not seen this guy for like 2 weeks prior. “Why doesn’t it wooooork?!” he intoned, with a whiny tone of voice meant to indicate how incompetent he thought I was. When I tried to explain that it had to do with the nature of the medium itself, and the overhead incurred from seeking to individual frames in a video, he would have none of it. Suddenly an expert on software development, he said, “Tsk. Something’s wrong with your code.” I didn’t know what to do; there literally was no room for improvement in the code. I had gotten out of touch with my own duct tape days as a junior engineer and forgotten that an FLV can be imported into a timeline; then, instead of seeking a video, you can simply jump to the appropriate frame in the SWF. I had forgotten the easy solution.

Luckily, this occurred to one of our resident junior DTPs. He imported the FLV into a FLA, published it out, and voila, it was perfectly smooth. Cool. He saved the day, which I acknowledged every time I had the chance. What wasn’t cool, and which I did not talk about for political reasons, was that he did it behind my back, without consulting me first, and rather than reusing the existing code and simply swapping out the video for the SWF, which would have been a very simple refactor and taken about 5 minutes, had he bothered to ask, he gutted the whole thing and recoded it from scratch, which took him more than an hour. The important thing to him was that he got his brownie points, and he could now claim full authorship (not to mention an extra billable hour of work).

Any good team requires a diverse variety of personality types to be successful, and as much as I hate to admit it, that includes DTPs; as long as you keep them on a tight leash and keep them in your sight at all times. But they are hardly a divine gift to coding and saviors of the universe. And that’s true of all engineers, including the architectural astronauts and the design pattern frigtards: they are all necessary, as a category, but no individual category is indispensible in and of itself. The parts don’t work without the whole, just like in an engine. There are no spare parts in an engine: you need all of them to run. And it’s hard to say which of those parts is the most crucial, since losing any one of them will cause the engine to stop running.

And that’s really the biggest beef I have with Joel’s post. It’s not what he says, but the unequivocal way he says it. Any time someone claims to have a Swiss Army knife solution to every possible situation, you should be very skeptical, because the reality just is not that simple. Shipping is obviously a necessary feature for an application. But it’s not enough to just ship any old garbage out the door; it has to be scalable, maintainable, and relatively defect-free as well. If a couple features have to be postponed until a later release because they just don’t work well, then so be it. This can and does happen all the time. Sure, the client tends to be a little peeved, but if you’ve ever been in the alternative situation, you know it’s far preferable.

Because the alternative is that you ship on time with every feature, but full of bugs. Which is fine until a VP from the client calls your boss at 3 AM from the east coast and chews his ass for an hour because he found a glaring, gnarly defect in a core feature that any retard could have caught before it even went to QA, but somehow this bug made it through development, QA and UAT, completely intact, and into production. What usually follows is a round of additional, high-level ass-chewings behind closed doors, eventually culminating in an all-nighter or two for one or more members of the development team, and finally grim debates about how much of the emergency work the client will pay for, if any, and how much is covered in the SLA, which means your company has to swallow it. Whoops. There go the margins. Maybe we’ll make a profit on the next project. And the potential damage to your reputation is even worse. Often, business relationships end permanently over these sorts of mishaps. I’ve seen it happen.

The myth of the DTP occurs frequently on software projects. It’s a common response to the unique pressure software teams are constantly under to deliver working products in complex circumstances. Despite the fact that tools like OOP, Agile, design patterns and TDD were all created to address these very circumstances, one symptom of this response is to blame the toolkit. The reasoning seems to be that, under tight deadline pressure, there isn’t time for high-falutin’ distractions like… engineering. Engineering is just another obstacle to kicking the app out the door. Just bang it out and launch it, already, for fuck’s sake. It’s sort of like having to build an airplane in 3 months from scratch and deciding that, under the circumstances, aeronautic engineering is just too much of a distraction to employ for the task, despite it being your best hope of accomplishing your goal, so instead you’ll use duct tape. I don’t know about you, but I wouldn’t fly in that plane if you paid me. I’ll take the titanium frigtard version, thank you, even if I have to wait an extra month or two to get it.

Let’s examine Joel’s version of this argument, how he puts it together, and why I think it’s wrong.

A straw man: frigtard engineering

Joel’s argument starts by positing a straw man: frigtard engineering. He cobbles this fallacy together out of various other fallacies: appeals to ridicule, emotion, tradition and popularity with a sprinkling of ad hominem on top to seal the deal. The net result is the conjuring of a figure we’ve all run into, and some of us may have even embodied at some point: the enthusiastic architectural tinkerer prone to gold plating every line of code that crosses her path. Like the hacker, this is simply in her blood, and like both the junior and senior DTPs you have to keep an eye on her, because she is prone to re-writing other people’s code without asking, and given half a chance will apply the Midas touch to every bit in your application that isn’t nailed down. She will often strike up random, half-hour-long architectural conversations that she will largely dominate and from which it is impossible to extract yourself from in a socially acceptable manner. In fact, she can’t extract herself. You can tell that she knows she’s been prattling on for too long, and may even make self-deprecatory statements to that effect, but she just can’t stop. Eventually you have to take charge and save the both of you and just say, “Cool. Well, back to work…” with a well-timed raising of the eyebrows while making full eye contact. Ordinarily she will be just as grateful for this bit of salvation as your immediate cubicle neighbors or office mates who have to listen in on the whole thing.

However, like the hacker and unlike the junior DTP, this person is usually completely devoid of rancor or negativity. She’ll be happy if you just indulge her for a few minutes, and she’s probably one of the nicest people you’ve ever met. She’s certainly no frigtard; she’s just enthusiastic about what she does. And while a lot of the things she ruminates about might end up in the garbage, she will often come up with innovative solutions in a pinch that save the day and would never occur to a DTP, and in fact would not even be possible with a duct tape programming approach. In a rush, she’s cognizant enough of her own penchant for over engineering and will modify her coding style accordingly, so she’s no real threat to shipping a product on time. But she’s also capable of thinking in the long term, and doesn’t think that reusable code and shipping code are, or ought to be, mutually exclusive, and she’s correct of course.

You need at least one of her on your team, because without her, your codebase very well might devolve into a morass of spaghetti. She’s one of the few people on your team with the vision to imagine how your product will evolve through its full life cycle and beyond. And when it comes to serious engineering problems, she’s the person you want at the helm. Let’s say you have to retrieve a single element from a collection with 3 million entries. The DTP will say, “Just iterate over an array. It’s easy. Der.” But our garrulous architect knows that searching through all 3 million records just to get to the one at the end is too slow and inefficient and will incur quite a lot of overhead on the server. Having memorized a text book on data algorithms, she will appropriately opt for a linked list or binary tree, and cut the maximum number of iterations down to something like 500. If you’ve read Joel’s post, I know, I know, he makes a specific example of a DTP using a linked list, but he’s talking about C++ DTPs and I’m talking about ActionScript DTPs, who generally don’t know what linked lists are. Anyway, you get the point.

But to the DTP and his worshippers, she’s just a dorky frigtard. Having successfully conjured a personality most developers are familiar with, he proceeds to set it up as the foundation for the real straw man: not the frigtard engineer herself, but frigtard engineering. The convenient thing about straw men is that once you’ve set them up in the background—sort of like a semantic scarecrow to reason—you can proceed to make all sorts of other generalizations based solely on the implication of the scarecrow’s existence. You never have to reference the straw man directly once its established and accepted. And the first generalization he makes essentially throws the baby out with the bath water. Because apparently, frigtard engineering includes any methodology that should qualify simply as engineering.

From there, he goes on to invoke a number of false dilemmas that usually go along with this myth cluster. It’s often referred to as the “build it ugly” philosophy. This dichotomy of opinion seems so to be as old as software engineering itself. It’s embodied particularly well in the differences between how Apple and Microsoft release products. Both companies release product on a relatively stable schedule. Both companies are successful at shipping and selling a lot of product. But whereas Microsoft has to chuck out every other operating system it releases and start over from scratch, Apple consistently releases robust operating systems that build on previous accomplishments. And while Microsoft still has more market share, even diehard PC users would be hard pressed to say that Microsoft produces a higher quality product than Apple. Why? Because Apple polishes its code to perfection before releasing it, instead of “building it ugly”. And they build their code to last. Objective-C has been the underlying language for mac development for a quarter of a century. Yet they don’t seem to be plagued with the perennial delays that Microsoft suffers. So much for building ugly.

An ugly build is just that: it’s ugly. Eventually, it will either have to be completely chucked out and re-written from scratch or tolerated and become an endless patching nightmare. Understand also that “building it ugly” isn’t the same as something like TDD. Refactoring will always be a fact of life for developers; it’s just not possible to put out a perfectly optimal app with the first release on most projects. There isn’t enough time, and hey, developers are human. Sometimes the optimal solution doesn’t occur to you until your baby is released into the wild and you see how it really interacts with the environment. But refactoring stable code to a more optimal pattern is different from just cranking out some crap and dumping it on your users, then rebuilding entire portions of it from scratch because they are so buggy or poorly performing that half of your user base commits ritual suicide after using your product for the first time.

Yet the build it ugly myth persists. Like DTP code thats gets grandfathered into an app because the feature it touches is too sensitive in production even to risk a refactor—or a cockroach—it just won’t die, no matter how many times you stomp on it. Here are the false dilemmas that it consists of, both in Joel’s post and in the world at large:

False dilemma 1: quality versus timeliness

This dilemma is pretty much the crux of the build it ugly ethos, and hence receives the lengthiest attention in this article. The argument goes something like this:

Premise 1: Ensuring quality takes a long time.
Premise 2: Being lazy does not take a long time.
Premise 3: We don’t have very much time, and we’re good at being lazy.

Conclusion: Therefore, we have to sacrifice quality to release on time.

To be valid, a deductive argument’s conclusion must be necessitated by its premises. In other words, its conclusion must follow from the premises. If any other conclusions are possible, or the premises can be proven to be incorrect, it can be said to be invalid. If premise 3 were able to stand on its own, the argument might be valid, but it’s purely a derivative from the first two premises, both of which can be demonstrated to be incorrect.

The first premise is wrong for a couple of reasons. First of all, to reiterate this point once again, all of the methodologies attributed to frigtard engineering were created with the intention of improving productivity in the first place, not impeding it with unnecessary structure. TDD, for instance, while reviled in Joel’s article, is specifically structured to produce the simplest solution in the briefest period of time possible. The solution of the design is then evolved in future iterations of the code. Design patterns are intended to solve known issues with a known solution, rather than requiring the engineer to reinvent the wheel every time he encounters the same problem. It’s true that the first time you use any of these methodologies there is a little bit of additional ramp up time, just as there is when learning any new technical skill or process. However, once you know the methodology and are in the habit of using it, the initial ramp up more than pays for itself in the time saved performing quotidian tasks.

I have often also heard the argument that using these methodologies doesn’t make sense with regard to a particular project because its lifecycle is only intended to be a year or so. I call this the lifecycle fallacy. This isn’t really an honest argument. For starters, modern coding practices are designed to scale to whatever size the developer requires. There isn’t any particular penalty incurred on a small application for using them, and their benefit doesn’t fail to kick in until some particular economy of scale has been reached. Secondly, even these short-lived and small projects occasionally need updates, whether that be in the form of changes, bug-fixes, repurposing, porting to a new platform or so on. And even when the latter is not the case, small projects, because they are less complex, are more likely than large projects to benefit from code reuse, because they are more likely to resemble, in whole or in part, applications that have already been written. Also, while one or two small applications written in a duct tape fashion might not be that difficult to manage, if you work in an environment where dozens or hundreds of small applications need to be managed, lack of standards, best practices and reuse can be a particularly large pain in the ass. Having worked at an ad agency, I have experienced just this situation firsthand. A corollary to this argument is that with such small applications, it’s just too expensive to employ all of these fancy techniques. This too is fallacious. When you have to spend 4 or 5 hours familiarizing yourself with some spaghetti code to do something that should take half an hour, I fail to see how this is more cost effective.

The second premise is also wrong. To demonstrate why, I’d like to invoke an analogy I call the “reverse snowball effect”. This analogy also reinforces my position on the first premise. When you start a project, being lazy—i.e. building it ugly, or duct tape programming—is indeed very easy, and yields quick returns. As the project progresses however, the application becomes more and more Byzantine and you start to experience exponential slowdowns in productivity. Eventually it gets to the point where the codebase is so fragile that it isn’t feasible to introduce even basic features without a substantial investment of new time. At this point, old bugs often reappear and/or new bugs are introduced into the system very easily when a new feature is added. Instead of gathering speed as it increases in size, like the proverbial snowball, your project gets slower and slower as it gets bogged down with the unnecessary complexity created by all of that spaghetti code. A well-managed project, on the other hand, starts slow, but picks up steam as more and more mundane tasks are encapsulated in a fashion that allows developers to focus on developing new features. New modules are easily added with a little bit of cut-and-paste. So, ultimately, laziness does take its toll, while quality pays increasing dividends over time.

False dilemma 2: quality versus elegance

Another argument levied against modern coding practices is that they are gold-plated. Sure, you could use MVC to separate your data and logic from your view, but why do that when you can just munge it all together into a single, 10,000-line class? Isn’t a single class more minimal, more elegant? The short answer is no. There are certainly several trade-offs invoked when using best practices to create quality code. For instance, while design patterns solve known problems with known solutions, they also require your team to be fluent in which design patterns are appropriate to which situation, how they work, et cetera. Likewise, a highly structured OOD that is broken up into 10 classes instead of one giant class will require your developer to potentially be familiar with all of those classes and their relationships to one another. There is a point when OOP can become overkill. There are some OOP fanatics who believe in one line methods. I think most developers, DTPs and the rest of us, would agree that is overkill.

However, fewer classes does not automagically equal elegance, simplicity or ease of use. Sifting through a 10,000-line document to find the one method you need to modify isn’t the most developer-friendly process. On the other hand, if naming conventions are well-utilized in your 10-class design, and a developer knows she needs to modify, say, the text formatting logic in the view where new bands are listed, then she can easily hone in on the code she needs by browsing the codebase. “Oh look, there’s a NewBandListView with a method called formatViewText(). Guess that’s what I’m looking for.” She doesn’t even need to know who calls the method; she’ll probably want to check just to be safe, but she can be relatively confident that she’s in the right place. Compare this to CTRL-K’ing through the call stack in your 10,000-line mega class written by a former Perl slinger to find the right code, because the code is so confusing and the class is so lengthy you don’t even know where to begin. “Let’s see, init() calls doOtherStuff(), which calls formatUpdate(), which calls newBand(), which is also called in like seven other places embedded in massive nested conditional logic statement. Hm. I guess that’s what I want, but I’m not really too sure. Fuuuuuuuck.” Both approaches require implicit knowledge. One kind of implicit knowledge can be learned by any developer with a quick web search or reading a couple of pages in a programming manual. The other kind can only be found in the head of a single crack-smoking DTP who is probably too busy or too smug to give you the time of day.

False dilemma 3: quality versus function

Another fallacy leveled at quality coding is that, “Hey man, it just needs to, like, fucking woooork, okay? The user doesn’t care if I use design pattern X or not.” That’s true: your users don’t give a tenth of a damn whether or not you used some technique or other to write the application they’re interacting with, just that it does what they expect it to, reliably. However, it has been my experience that duct tape applications are much more prone to defects and slow performance. And that’s something users definitely do care about. And while they may not care whether you use a specific technique, they probably would like to know that the product they are using is well-built and reliable. This is true of any product, digital or not. For instance, when someone buys a dresser, they probably don’t care whether the carpenter used a biscuit joint or a miter joint. But they know poor quality when they see it. “Damn, these drawers are just banged together with finishing nails. They didn’t even use any glue!” Of course, the inner workings of your application aren’t exposed to your user the way they are with physical products. That is, until it doesn’t do something they expect or crashes the browser because of a defect or poor optimization. Once again, applications are not written for computers. Computers just run whatever set of instructions they are given, even if the instructions are flawed. Applications are written for humans: developers and users. And while a banged-together application might function, writing it in that fashion is essentially like shitting in your co-workers’ (and your users’ and client’s) corn flakes.

False dilemma 4: testability versus function

Another false dilemma, which is sort of a corollary to the last one, is that gee, testable applications sure are nice, but it just doesn’t matter as long as it functions. Again, that’s true, but writing testable applications helps your team deliver quality products.

False dilemma 5: maintainability versus function

The last false dichotomy is between maintainability and function. This is another corollary to the third false dilemma. Writing code that is easy to maintain means that your co-workers can quickly address defects and changes, and spend the time saved writing new applications and features.

Spock versus duct tape

In the final analysis, the choice presented by Joel Spolsky and the advocates of Duct Tape Programming is between Spock and the rest of us. As is usually the case with reality, in actuality there is a spectrum of choices between those two poles. Yes, the Spock option is always available, and in some situations it is appropriate. But design patterns and TDD—or anything even slightly complicated—hardly constitute rocket science or brain surgery for a talented developer. I would agree with Uncle Bob:

“I found myself annoyed at Joel’s notion that most programmers aren’t smart enough to use templates, design patterns, multi-threading, COM, etc. I don’t think that’s the case. I think that any programmer that’s not smart enough to use tools like that is probably not smart enough to be a programmer period.”

These sorts of concepts are just part of being a developer. If you don’t want to learn them, then pick another career. It’s that simple.

I would also agree with Uncle Bob that the specific suggestion in the Spolsky article can be ignored, but that the spirit of simplicity should be embraced. But again, that doesn’t mean hacking together a piece of crap. Simple and intelligent are not mutually exclusive categories. And simple means as simple as possible; sometimes abstraction is called for and simplicity is defined in the context of multiple requirements.

Duct-tape programmers: smart or not? … or: Duct-tape programming: hard or not?

Ultimately the Joel on Software post on DTPs is confusing. He starts off singing the praises of DTPs as down-to-earth, no-nonsense guys, not too brainy—the sort of guys you might go on a pub-crawl with, but would never expect to hold their own in a conversation comparing the existentialism of Sartre to that of Kierkegaard—sort of a geek version of frat boys. And he specifically opposes them to frigtard engineering and Spock. But he ends the article by positing them as some sort of genius supermen:

“Duct tape programmers have to have a lot of talent to pull off this shtick. They have to be good enough programmers to ship code, and we’ll forgive them if they never write a unit test, or if they xor the “next” and “prev” pointers of their linked list into a single DWORD to save 32 bits, because they’re pretty enough, and smart enough, to pull it off.”

Wait a minute? A linked list? Doesn’t that qualify as more than slightly complicated? And isn’t xor’ing pointers into a single DWORD kind of frigtardish? So which is it? Are DTPs smart or aren’t they? Is duct tape programming hard or not? Maybe they’re smart enough to use Spock-frigtard-ineering, but they choose not to. They’re like the Autobots: they are powerful enough to destroy us, but instead use their power to protect us from evil. Those evil Decepticon engineers, meanwhile, led by the nefarious Frigtardotron, are plotting how they can bury us in unnecessary gold-plating and odious over-engineering. The rest of us are just helpless humans. Golly, I hope the Autobots save us.

Fuck the Autobots; we can save ourselves. I certainly won’t say that DTPs are unintelligent, although I think it’s difficult to argue intelligence from a position of being opposed to anything remotely complicated because, “It’s just too dang hard, man.”—a paraphrase of which I’ve heard actual DTPs actually utter. I will say that duct tape programming is not difficult. Anyone can do it. Most developers don’t choose a particular technique just because it’s cool or makes them feel brainy. They choose it for a reason. That reason usually has to do with scalability, or maintainability, or something else. Sometimes it’s not a good reason, which is why teams are important. A dirty little secret about coding is that it’s not that hard. Most of the people intelligent enough to work in a professional trade could probably do it if they set their minds to it. What redeems this dirty secret is that coding well—which we call programming, development or engineering—is hard.

Programming iz hard

Programming is hard. That’s why they pay us the big bucks. Why is it hard? To answer that, I’d like to address the meaning of a few words we tend to use synonymously but which, I think, have much more specific meanings in the real-world sense. Those words are: coder; programmer; and developer.

What is a coder? That word is fairly easy to define, I think. Without looking it up, I would define a coder simply as one who codes. If you wanted to be a little more descriptive, you could say a coder is someone who authors code in a particular programming language, but that’s about as complicated as it needs to be. More or less anyone can be a coder if they choose to. A high degree of competence isn’t necessarily required beyond basic syntax. This is the category I would put DTPs in whether out of inherent talent or due to a conscious choice. The only thing that differentiates them a little from a coder is that they are a little more clever; they know some cute tricks.

Up next is programmer. Programmer is a little more complicated. I would say a programmer is someone who authors software applications that run on a particular platform by authoring code in a particular programming language or languages. Notice that the concept of a programmer is a superset of the concept of a coder. It is implied that a programmer codes, and a certain degree of competence is also implied.

What is a developer then? I was asked this question recently in an interview, and it put me off a little. I’ve never been asked that, and I was hard-pressed to define it briefly, because I don’t think it can be. To define what it means to be a developer requires paragraphs or pages, I think, regardless of what the dictionary definition is. Being a developer is comprised of everything in this article, for a start, and much more besides. For instance, knowing how to code isn’t going to help you when you have a shotgun deadline and you have to deal with a senior DTP who refuses to go along with the team because he’s butt-hurt that he isn’t the lead developer, even though he was hired explicitly as an extra set of hands, albeit a senior one. That’s something that can’t even be taught; it has to be learned on the job. Being a developer is a complex daily balancing act that requires you to continually make, evaluate and re-make hundreds of little decisions based on multiple variables. Some of those variables are fixed; some of them change several times in the course of the project, only to end up where they started. That constant state of flux is what most of us both love and hate about the job.

So if you want a coder, follow Joel’s advice and take it to heart. If you are looking for a developer, ignore it. And if you absolutely, positively have to oversimplify things, or simply can’t afford many resources, I ‘d wager good money on a hacker and an architectural astronaut against a pair of DTPs any day.

A point of clarification regarding the title of the blog: it is entirely for comic effect. For instance, I am not Bavarian, although my name is. The ‘cream’ comes from a saying I made up at a previous job: “That code is creamy,” meaning: “That’s some smooth code. It works the way it’s supposed to, is well encapsulated, easy to extend, and low on defects. Delicous. Goes down easy.” Hence, Bavarian Cream. Even though I’m not Bavarian. I am proud that although I don’t know any of my German relatives, which surely I must have, but from whom I am entirely estranged like a typical US native, the Sedlmayr family is a significant part of the operation of Spaten Brau, one of the finest German beers I know (Spaten Oktoberfest is the official beer of the actual Oktoberfest in Munich, and the first beer tapped to open the event), and for a time in the 17th century, even owned it.