The Right Glue

By Dean

(2008-07-30 13:14:59)

Contrary to popular belief, I do still post here. Though I suppose it has been almost two months since I last made an update, you really have to think about why you'd want to read anything I write in the first place. Also, look at qedi — he hasn't updated in more than nine months. Compared to him I'm doing just fine.

While I have been perpetually sick for the last couple of months (something Dr House is working round the clock to solve), that's not really an excuse to not post. Neither is the fact that my parents have discovered my web presence (could be worse — I could have been Maddox). They do contribute, just not as much as the fact that I think I'm really bad at expressing things. You know what happened last time I tried to write when I wasn't in the right mindset to do it (I'm not even going to link internally to it; it was so bad).

So without further delay today I'm going to talk about the most important things in the world: the Internets. The Internets are many and few. They are a series of tubes, not unlike a dump truck.

Because of the nature of the Internets, when one is online one can choose to take on any personality and history one wishes. One can be an astronaut, a superhero or a mathematician. You obviously don't have to have been in space to convince someone you've been in space, and it's even easier to do with as long as you're sufficiently knowledgeable in the area. So using your new astronaut persona you can gain all kinds of notoriety or fame.

Mr Astronaut is now an online persona, and no one knows that in real life she's actually a 12-year-old girl who just read a book about astronomy. This separation of real life and online life is usually referred to as anonymity.

This is not to be confused with, y'know, the definition of anonymity. Our hypothetical space-walking friend is not anonymous at all. All he's accomplished is a separation of person and persona. His persona, if done correctly, is very popular and well known across the digital planes. When he does things online, people think, "There goes the famous astronaut." This is in direct contradiction to actual definition of anonymity.

Stop butchering English. C'mon, guys. Now that that annoyance is out of the way I'd like to apply some of the concepts above to the Internet's true purpose: multiplayer games.

The way I see it, there are four kinds of people with respect to games: the hardcore, the social, the Xbox gamers, and the assholes. (Note that the descriptions I'm about to list are extreme examples. Most people won't be definitively categorized into each group. If you want categorization, go take an online quiz, you weirdo.)

Hardcore gamers are the obsessive ones who play World of Warcraft 10 or 12 hours a day. They're the kind of player who sees the rules of the game as the be-all-end-all. People who side-step the rules by either cheating or having a custom-rules server of some kind are the enemy. These people band together into groups (called clans in videogame talk) in order to improve their skills and/or items in game, and have the most fun when their clan is an efficient well-oiled machine, achieving every objective, every minor goal and securing victory as quickly as efficiently as possible. These guys are no-nonsense and will always mop the floor with your stupid noob face at every confrontation, unless you happen to be one of them.

Social gamers are the opposite of hardcore gamers. These guys play games as an extention of hanging out with friends. They generally disregard the person/persona separation with their online comrades, and know each others' names, interests and whatnot. The rules of the games they play are seen as guidelines that can be broken at any time for the sake of having a good time, to the chagrin of the hardcore folks. They join clans based on interest (hint hint: The Daily WTF Steam community, founded by me) and real-life friendships.

The Xbox gamers go by many names. Fame-seeker, insecure little boy, whiner, smacktard — each describes them perfectly. These guys play games well and make friends (like the hardcores and socials, respectively), but do so differently and for different reasons. Xbox guys want everyone to know how awesome they are, either based on how good they are in game or how cool they are in real life. They complain every time they die, they complain when someone steals a point from them, the complain a server doesn't have a setting they like. They brag whenever they get a kill, they brag whenever they secure an objective, they brag about how nice their stuff is. Their sole purpose in playing games is to feel superior to everyone else. When these guys are in clans, they do it to secure personal power, kicking out anyone who crosses them. You can tell a server is operated by a clan consisting mainly of Xbox smacktards when the server's log-in message is something along the lines of "ALWAYS RESPECT ____ CLAN MEMBERS" where ____ is the name of the whiner clan.

Based on the above description, you'd have to wonder what I could possibly mean by asshole gamers that would be different from Xbox gamers. Assholes don't play games because of a desire to win like the hardcores. They don't play games to make friends or to feel superior to anyone else like the socials and the Xbox crowd. They play to have fun. (Remember fun? It's fun!) You might think everyone plays games for this reason, but then the preceding three types of people wouldn't exist and I would never have written down my observations about them. Assholes will exhibit whatever behaviours are strongest in the particular game they're playing. Assholes will appear social in social games, hardcore in hardcore games, Xboxy in Xboxy games. One thing that is always true is a lack of both fame-seeking and friend-seeking behaviour (hence the name asshole). They won't try to impress anyone to make friends or gain respect since that's not really the point of the game. But they won't get too much into the game itself since that's not as fun. They're just there, unknown and anonymous, having twice as much fun as you ever will.

And before anyone comments about it, I do not keep a blog to gain fame or respect (not that I even receive any of that as a secondary effect). I do it for my own purposes, mainly because every so often I feel like writing and the best way to get over that feeling is to write something, no matter how pointless it may be. No matter how few people read it. Enjoy your Xbox.

Comment on this post (1 comment so far)

Comment by Jess (2008-07-30 23:36:54)

The Web

By Dean

(2008-06-07 13:06:30)

Today I'm going to tell you that the Web is being used incorrectly by both its users and especially by companies hoping to leverage it for profit. Hopefully by the end of this post you'll believe me.

Let me first introduce the concept of a thin client, if for some reason you're reading this blog and don't know about them. Back in the day, computers were huge, expensive machines whose processing capabilities rivaled those of my pocket calculator. Individualized computers as we know them today were not possible. So we came up with a centralized computing model using machines known as "dumb terminals" or, more accurately, "thin clients". The thin client contains only enough hardward and software to accept user input and display feedback. Everything the user sees and does on the thin client is processed by a central server via a network rather than on the client itself. This was the cheapest computing model at the time, allowing each user to have his "own" computer, while not paying through the nose for computing power.

This was first done with the text-only screens of systems like IBM's AS/400. Each thin client was just a monitor and keyboard, and text positioning and other information was handled by the central server. Since text computing is cheap (relatively), there was no reason to try and offload those calculations to the thin client itself. In more modern centralized computing models, such as a centralized Solaris Unix environment, users demand a more robust graphical display and input capabilities. The modern thin client in this environment offers a keyboard and mouse as input, and runs a distributable graphical display system, such as the X Window System. In this model, the central server handles the back-end computing of what the user wants, and the thin client handles the display, input and event processing.

This is still a very cheap computing model, since you still have a centralized server doing most of the work and a set of thin clients which are effectively nothing more than graphics processors. All of the user-specific graphic events are kept off of the central server, freeing up its cycles for the (optimally) important calculations the users need to run.

The opposite of thin clients is what most people think of when they think of "computer". The desktop or laptop or PDA or cellphone you use to do things on a daily basis. When running things like games and office productivity software, the PC's hardware and only the PC's hardware is used to run all of the calculations involved. When the computer isn't being used, all of its cycles are being wasted on nothing. This makes it a very, very expensive computing model. Only gamers and professions in certain design and engineering occupations can make full use of such individualized hardware. One need only remember that a computer with a processor weaker than that of a modern pocket calculator used to be able to support dozens of concurrent users doing their work over thin clients to see that we're wasting our thick-client CPU cycles. (Also, software bloat contributes a great deal to this phenomenon but that's another discussion entirely.)

HTTP, the hypertext transfer protocol, is very similar to the modern distributed system of computing. In its original inception (that is, just transmitting HTML without any extras) all it did is transmit the information required to display results and transmit user input to the server. The browser (analogous to a thin client) handled display calculations and the server managed everything else. Then other things were added to the Web, such as images, CSS, more well-defined HTML and even small scripts that were run on the client to manage some display calculations. HTTP was still very much a centralized computing model, with nothing more than display code being run on the client. The big difference is the fact that HTTP is sessionless: once a web page is delivered to the client, the server forgets about that client. So if you wanted to make an application that reacts to every input the user gives, the client has to tell the server everything every time. This results in a great deal of network bandwidth being used to communicate information that the server technically knows already.

So we did the worst thing we could have possibly done. We tried to mash HTTP into a sessioned protocol by lumping entirely new frameworks on top of it on the server side. Then we even warped HTTP into micro-requests for interactivity instead of sending the whole page every time. AJAX is the name given to this practice. The end result is more and more computing is offloaded from the server and onto the client. Web pages are now not so much individual documents meant to be read as they are miniature dynamic distributed applications. Instead of moving toward a centralized computing model, we're putting more and more of the actual calculations onto the client. This works because the client usually has cycles to spare, and companies want to do it to reduce the work their servers have to do.

The problem is the Web isn't being used in a thin-client model. Rather it seems to be moving more and more toward a distribution system for tiny applications. Web pages are often warped into single-serve software. Things like web-based e-mail and office productivity suites (I'm looking at you, Google) are the best examples of this. It would be better (in terms of efficiency and bandwidth usage) to have office software installed on the client rather than all of the individual screens, scripts and other information transmitted to the user over the Internet every time he wants to use the software.

We should have come up with a lower-level protocol than warped session-HTTP for this kind of thing. It's really nothing more than a hack on top of a system that was specifically designed to do the opposite of what we want to do with it. Instead of bending HTTP to our desires we should have created a sessioned sister protocol to HTTP that could reflect a thin-client model, and leave HTTP to its original site-distribution purpose.

Not that there's anything you or I can do about this. It's just a fact of the Web now. What it means is that as we move more and more into the Web-as-distribution-agent model, web pages are going to be expected to look and act more and more as thick clients and will therefore have to rely on more and more hacks to accomplish this. And all this time we should really just have looked back to those AS/400 dumb terminals for guidance. Really I didn't want to do anything more than bring this to your attention.

Comment on this post (2 comments so far)

Latest comments:

This by L to the Abe (2008-06-26 02:30:45)

First time actually reading something here by Nemuri (2008-07-01 05:33:34)

On the rain-slick precipice of darkness (and medics)

By Dean

(2008-05-27 19:35:05)

I am torn between my dislike of every little person on the Internet reviewing a new game in a pathetic attempt to seem trendy and original for playing a popular game and my own desire to review a new game in a pathetic attempt to seem trendy and original for playing a popular game. Guess which side of me won?

If you've been paying attention to my Steam account recently, you'll see that in addition to my love of sand I've been playing a great deal of On the rain-slick precipice of darkness episode 1, a game brought to the world by Penny Arcade's prose-elemental Jerry Holkins (known to the world as Tycho) and his artist cohort Mike Krahulik (Gabe).

As you'll recall from my web comic post, Penny Arcade is my favourite comic. After nearly a decade of mercilessly mocking games they set out to make their own series of games based on their own comic. They sold 16 500 copies (scroll down to Gabe's first post) of their game over Xbox, and who-knows-how-many more through their distribution company Greenhouse. In spite of years of being hardasses on their fellow game reviewers, the game is getting rather positive reviews, with better reviews being published as time goes on.

The game itself is designed around a comic look and feel; a design which succeeds tremendously and not just because all of the drawn and written content is from Penny Arcade itself. The 3D graphics are cell-shaded to give it a comic-like look. The in-game dialogue is speech and thought bubbles. Most impressive are the cutscenes. Each cutscene is two-dimensional instead of three. It's difficult to describe, but it's as if each frame in a usual comic were animated, and a page of such an animated comic makes up a cutscene. The cutscenes blend flawlessly with the regular in-game graphics, and indeed your customizable character is featured in full action in the cutscenes.

A game without action and adventure is hardly a game at all, and Precipice is not without its combat. The game plays as if it's meant to be completed, with hints readily available whenever necessary. The story is not so complex that one would ever become confused and there is little to no thinking work required in completing any puzzles. The game's difficulty (and indeed more fun) comes from the combat. Anyone who's played Chrono Trigger is familiar with the active-time battle system Precipice employs, though it introduces a new idea of "tiers". Each character can either use an item immediately, use a weak attack after waiting a short while, or use a very strong attack after a long wait. The strong attacks are augmented with small minigames — the better you do in the minigame, the stronger your attack. The combat is the second-best part of the game (second only to the writing), and I greatly look forward to seeing this system fleshed out and taken to its limits in the future episodes in the series.

The writing is, well, exactly like Penny Arcade. Off-the-wall humour and completely deranged characters are par for the course in this game. If you're the kind of person who can see humour in the more paranormal effects of urinology or perhaps a sack of hoboes, then chances are you're reading Penny Arcade already. If you're not, well, On the rain-slick precipice of darkness is not for you.

While I'm talking about games, I want to revisit my rather pessimistic view on unlockable content in online games. I'm not going to repeat myself and I haven't changed my mind: unlockable content serves to do nothing less than alienate players and create tiers of players based on what they've completed in the past rather than current skill.

Valve has released its version of unlockable content in the multiplayer-only team-based FPS Team Fortress 2 for the medic player class. Players must complete 36 achievements, from relatively easy to nearly impossible, in order to unlock three new medic items. At the time of this post, only 1.4% of TF2 players have completed all 36 achievements.

When Valve released the patch that enabled the new achievements and medic items, servers began to fill with medics. In a typical server at the time, usually about half the players were medics (previously there would be at most two medics on a team of 10-12 players) all trying to get as many achievements as possible with little regard for the game at hand. This overabundance of medics upset the balance of power in many maps, giving teams several easy wins. After a few weeks, this medic flood died out and game balance was restored for the most part. However, in response to the new content, several dozen "grind" servers were created which bent the rules of the game in order to help people get their achievements as fast as possible. I don't know about the rest of the 1.4% of players who got all of their objectives, but I and many others used these servers to great advantage.

I wish I could take pleasure in saying "I told you so" to Valve, but I can't. The hit to the game was too great. Too many players playing one class (out of a total of nine) when that class wasn't the best class to play from the point of view of the team upset the game a great deal and managed to suck the fun right out of some of it. I'm very thankful for the grind servers, since their very existence lets those of us who want to play tell the achievement kiddies that if they want to grind achievements they should go join a grind server.

Achievements would be nice if many players were, like me, stable and understanding enough to grind when on grind servers and play the fucking game on regular servers. I can't tell you how many times I've been screwed over by medic teammates who were just looking out of opportunities to get achievements rather than actually playing the game and helping the team. Good job, guys.

Comment on this post (6 comments so far)

Latest comments:

SUCCESS by Dean (2008-05-28 17:51:50)

I disagree! (drives off) by Jess (2008-06-02 01:14:36)

NO. by Abe full of ANGER (2008-06-02 15:48:06)

The engineering knack

By Dean

(2008-05-19 09:48:32)

I've been putting this post off for a long time for several reasons: my previous post was probably the best post I've ever written and ever will write, so I wanted it at the top for a while; I'm not a very creative person, and creativity only comes to me in waves, and I haven't experienced a creative wave since my last post; frankly, I'm a terrible writer; it will be difficult to write this post without making me sound like a jerk who holds nothing but contempt for everyone on Earth.

I finally decided to write this one for several reasons: it's been a freaking month since my last post; my readers will probably still read even if my writing is drab because, frankly, I'm so great; this post is really just an excuse to link to some pictures from high school; sounding like a jerk would make me more like my hero (there's that obligatory link to Wikipedia).

So without further metablogging, today's topic is this magical distinction that makes some people more adept at technical tasks and thinking than others. I personally call this thing "the engineering knack". To be specific, I am using the study that shows some people just naturally "get it", while others, no matter how much education they receive, just slip, as a springboard, as well as many of my own verifiable observations of the world. In my mind, there is precious little discussion on this topic. My goal is mostly to summarize a set of ideas that have been floating around in my head with the hope that someone will see them and make a psychological or creative leap that I'm afraid I'm not capable of making, or at least expressing.

Without going into where the knack comes from, I'd like to focus on some observed effects. First and foremost, I think we can all see that those with the knack tend to be driven to create, learn and explore the world from the ground-up. That's the reason I call it the engineering knack, because it seems to me that such a drive is the very definition of "engineer". Why would anyone become an engineer if he's not passionate about it?

It's strange that only a subset of the human population has the ability to "get" the idea that computers (and indeed all devices) are nothing more than machines that follow their instructions to the letter. People who don't understand this idea right from the start never will (and are hilarious). I can think of no evolutionary advantage or disadvantage for early humans with the knack which would have caused it. Indeed I can't think of any such advantages or disadvantages in today's world. Perhaps this is an argument that developing minds pick up the knack in early childhood and cannot acquire it later. It does seem that those with the knack are simply wired differently from others.

The focus of attention of a passionate engineer is nearly always on the thing he's creating itself, and rarely does it extend outward. Those with the knack make terrible marketers, salesmen and entrepreneurs, since they tend to think that having a well-engineered idea or product is merit enough to become successful. (In all seriousness, having such an idea really ought to be good enough, ideally. Too bad the world is a real place and not just in theory.) So the knack-havers (I really need to think of a better term for that) end up making things like open-source software, pouring years of effort into fantastic products and then giving them away for free. An economist that I know laughs heartily at this idea. It's not that the effort was wasted, it's that people aren't profiting enough from it.

So I would say that "marketing" (at least in this sense) and "engineering" are opposites (or perhaps only orthogonal). Those that are brilliant engineers scoff at the idea of making personal gain from something that should benefit everyone. Those that are brilliant "marketers" probably think that not squeezing every last cent from an idea is insane. (Or something like that — I don't know how to think that way. Frankly I don't really like marketers.) Engineers are terrible at making money, because they don't care. They'd rather be paid to do cool things all day than turn a profit.

Engineers do things just for the shit of it, such as converting a high-school locker into a working slot machine. Once an idea pops into our pointy little heads we generally want to see it to completion. Now I'm sure that's true for most people, but with knack-havers it seems the ideas are more outlandish (read: insane) and the drive to create and learn is stronger (read: obsessive). At least, I hope it's not just me. I admit I am extrapolating from too few data points, so maybe this is just a window into my own insanity. In either case, this entire post was just a thinly veiled excuse to post the images of my high-school locker. Isn't it awesome?

See what I mean about me being a terrible writer? This is why I don't write anything until I'm in my groove, because it makes me look fucking insane.

Comment on this post (3 comments so far)

Latest comments:

A Comment. by Abe (2008-05-19 18:48:54)

Look here boy by Ahab (2008-05-25 15:18:46)

I don't think you read the study by Dean (2008-05-25 15:22:07)

Metaphors

By Dean

(2008-04-23 19:20:04)

Metaphors are used by software engineers to help users relate to the software that they're creating. For instance, the name "desktop" for the screen Windows and other systems present to the user comes from the desktop metaphor, which was designed originally to help users understand the nature of the two-dimensional space displayed on the screen. Metaphors are also used by software engineers to talk to one another. Many computer-science terms stem from metaphors, such as structures, trees, tables, indexes, et cetera.

However there is a more overarching metaphor that applies to all software development, encompassing everything from the initial conception of the users' needs to the final, tested and installed product. This metaphor is mostly unused by software engineers when talking between themselves, because for the most part (since it is our profession) we don't need to resort to metaphor to describe what we're doing. The overarching metaphors are used to communicate what might be difficult to do and what might be trivial.

The problem is when you compare software engineering too strongly with its metaphorical counterpart, people start focussing more and more on the tangible metaphor rather than the hokus-pokus of software.

I am going to take this time to describe the current most-popular metaphor used today and explain what problems it has caused. Then I'm going to present a better metaphor and tear it down as well. Ultimately my conclusion will be never to adhere to a metaphor too strongly lest you foster misunderstanding.

Today we use the "architecture" or "construction" metaphor of software development. Indeed, the very terms "software engineer" and "software architect" come from this metaphor. We often say that we are "building" software. Software runs on "infrastructure". This metaphor has shaped the terminology we use to describe these ideas.

The metaphor owes its strength to the age and wisdom of building structures. Humans have been building shelters (or at least finding and improving them) since before recorded history. Though not everyone is a civil engineer or a design architect, we're generally very good at looking a building and deciding whether or not it was well constructed. Even though not everyone can build a house, nearly everyone lives in some kind of man-made construction. Therefore drawing an analogy to construction literally hits home with everyone.

Everyone in the software engineering business knows that spending an extra hour designing a program will save an extra week of coding time. This came from the construction metaphor. Architects and civil engineers spend as much time as necessary poring over every minute detail of the construction plan before even considering moving forward with it. After all, if they get anything wrong the building may not last for hundreds of years. Or worse yet it may collapse and kill everyone inside. Indeed, if everyone approached software design with the idea in mind that flaws could prove fatal then we'd surely try to go the extra mile to make sure everything is perfect.

Because of this attention to detail, the metaphor draws a lot of strength from the higher-ups, whoever they may be. They like to think that we programmers are doing everything we can to construct perfect software that will last forever. And who can blame them?

The metaphor is flawed in many subtle ways that lead to a great deal of frustration when dealing with people very far removed from software development. While I could go on for several pages enumerating them I will stick to the most obvious and problematic.

The concept of "maintenance" as it is used in software engineering is the complete opposite of the equivalent term in civil engineering. Once a building is erected it will slowly degrade by no fault of the engineer who designed it. It's simply a matter of fact. Things in the real world degrade over time. This is not the case with software. If there is a problem being observed with software, it was not "damaged" or "corroded" by some outside force. Rather the one who designed the software forgot that particular detail and no one noticed until now. Software "maintenance" is the programmer changing the logic and design of the program. That is nothing at all alike real-world maintenance.

It takes a great deal of time and effort to change the design of a physical structure once it's built, or even if it's half built. Therefore you have to completely understand what your customers want and tell them, "OK. No more," before the first hole is dug. Nothing could be further from the truth with respect to software writing. New-but-similar requirements and even most new-but-completely-unforeseen requirements can be added to a piece of software in a matter of hours. In fact we, as diligent software engineers, specifically design our software in such a way that adding, removing and changing details is as painless as possible. Now, obviously there is a limit to how many and what kind of changes that can be made to a design without needing a lot of effort, but that threshold is much, much higher than most would imagine.

This misunderstanding of software is so pervasive in the minds of non-software engineers that often teams are specifically told to go to great lengths to avoid "hard coding" things into a system. The act of avoiding hard coding anything is called "soft coding" and it is nothing but trouble. Nothing is more prone to error and bad design (and, ironically, inflexibility) than soft coding, at least as far as I'm concerned. The separation of logic (i.e. code) and what the logic works with (i.e. data) is good enough to guarantee the least amount of effort needed from each party involved (most of the time).

To reiterate my point (which I really can't stress enough), consider the effort needed when I added a completely new piece of functionality to KevBot. KevBot was never designed to do anything remotely similar to a Markov chain. Its data structures aren't designed for the deep searching required to build it. I had never written a Markov chain algorithm of any kind before. In fact, we had only covered them briefly in my intro to AI course in university. It took about an hour, maybe an hour and a half, to get it up and running and live and interacting with users. Same deal with this website. About two hours from having an idea to having a full site written up in a language (PHP) I had never used or seen before.

Now, I'm not boasting my ability or claiming that KevBot or this website are at the same level of complexity as most business applications; rather I'm claiming that software is highly malleable, with previously inconceivable features added in mere moments. I'm claiming that had one adhered to the architecture metaphor, one would think that this kind of thing would take weeks or even months to complete. That is because the metaphor is flawed.

A better metaphor for software engineering that clears up these important misconceptions is Lego. Lego, the children's toy of colourful little blocks that fit together is more similar to software development than architecture. And I can prove it.

First of all, given enough of it, Lego can build anything. Right there, Lego is more robust than civil engineering. Name everything you can do with a house. You can live in a house, and that's pretty much it. Everything else you do in a house is done with supplements to the house itself like beds and televisions. Civil engineers don't build beds and cool robots. But you can build beds and cool robots and much more out of Lego. Just like how you can do more than just build websites with software. Software and Lego can both do anything.

Lego requires careful planning, in fact all of the careful planning that civil engineering requires, to make something right. Just like construction, every hour spent planning saves days once you start snapping the pieces together. Lego blocks also don't degrade over time. If you build something out of Lego and it stops working, then it's because you didn't squeeze the pieces together tightly enough, or you didn't build it structurally sound enough to keep from falling apart during use. If it breaks, it's because it was always broken, just like software.

Anyone can use Lego. You don't need a degree in Lego science to build a rocket ship with Lego. You don't need 15 years of experience designing cool Lego toys in order to make a neat robot. Just like programming (and very, very much unlike civil engineering) Lego is very easy to pick up. (Not that this is necessarily a good thing, since you generally don't want to set up a production Lego construction that was assembled by someone who's never used Lego before. Just like software design!)

Changing a Lego construction is easy, too. You want to add a third arm to your cool Lego robot? Just snap it into place! You don't like this colour of block? Take it out and put a new colour in. It's that easy. Just like software.

But even this metaphor has issues. Building an algorithm isn't anything like snapping colourful bricks together. It's not that easy. Also, the importance and difficulty of debugging is completely lost in this metaphor. It's generally very easy to see what part of a Lego robot is flawed by looking at the broken wreckage. Software not having physical form makes this much, much more difficult. Lego also requires a surplus of bricks to create something, often requiring the cannibalization of previously-built cool Lego robots to get them. Software has nothing like this. Code has no physical form, after all.

No matter how cool Lego is (it's very cool), it can't serve as an adequate metaphor for software development. It's not Lego's fault, though. This is the problem inherent in all software metaphors. Just like how no one has a physical "taskbar" or works by moving "windows" around on his desk (the "desktop" metaphor). No one metaphor is going to fully explain any discipline. It's not that we shouldn't try to use metaphors to help describe what we as software engineers do, it's that we shouldn't let these metaphors drive the nature of the discipline.

Software engineering is software engineering. It's not civil engineering, it's not architecture, it's not Lego. Never forget that.

Comment on this post (2 comments so far)

Latest comments:

a slight problem by Jessica (2008-04-23 21:09:11)

Hah by Dean (2008-04-23 22:00:41)

Gehn

By Dean

(2008-04-17 19:40:29)

Let me tell you the story of a man named Gehn (and link to Wikipedia excessively in the process).

In the Myst series of games, there is a civilization called the D'ni. In their vast underground caverns, the D'ni created a way to "link" to different worlds and civilizations using a precise system of writing.

D'ni civilization was based around various guilds. One of these guilds produced special books, one guild made special ink, one wrote worlds into the books using the ink, and one verified that the writers were doing a good job.

Using the precise language of the writer guild, the correct ink from the ink maker guild and the right book from the book maker guild, a D'ni could create an entirely new world, complete with flora and fauna, and visit it. Each book was a work of art, bringing its passenger to the imagination of its writer. (Technically the books didn't create new worlds, but rather "connect" to existing worlds that match the precise descriptions in the books — though most of the time there is no distinction between creating and connecting.)

If the writers are careless, then a simple out-of-place word could mean the destruction of the world on the other side, and everyone living there. That is why only the writer guild was allowed to create worlds, and even then only under the scrutiny of the guild masters. If even one feature of the world was described too vaguely, then anything could happen. For instance, the planet's star could go nova, or the planet's weather could be too hostile to support life. When playing god anything and everything can go wrong.

Without going into the details of the games' stories, the D'ni civilization fell leaving a young would-be ink maker named Gehn to fend for himself in the ruins of the once-proud D'ni capital. With access to countless left-over books and inks, Gehn took it upon himself to bring D'ni back from the grave by writing new worlds and teaching the people there the ways of the D'ni.

But Gehn was too proud of his heritage. He didn't take the time to fully comprehend what he was doing, believing his D'ni blood would show him the way.

He started writing books.

Since he didn't have a firm understanding of the creativity involved in creating worlds (nor the immense level of detail and precision required to keep them stable), he never wrote a sentence of his own. He simply "copied and pasted" sections from books still scattered around the remains of the capital, having only a rough idea of what each one was meant to do.

Needless to say, the worlds Gehn wrote all ended in ruin. Each one ripped itself apart in one way or another. Even his best world, Riven, was doomed to be, well, riven. Because the passages he stole from other books were a small part of a greater whole that Gehn never cared to understand, they did not work out of this context as well as they should have. Every spliced citation caused a new problem in Gehn's worlds.

Gehn embodies a rather disturbing fact of life, which is that people who don't know what they're doing are incapable of knowing that they don't know what they're doing, and indeed believe they are doing the right thing. Gehn truly believed that he could bring back the D'ni civilization, and that he was doing the best job possible, even though everything he created was riddled with flaws.

That sounds a lot like software engineering, doesn't it? We have programmers who create, infrastructure guys who give the programmers the tools they need to create, and testers to make sure the programmers' creations don't kill everyone. And just like Gehn we have countless people who believe that programming is nothing more than taking code written by other people without taking the time to fully understand it (or, as it is in this case, without even bothering to read it in the first place). At least as long as this is the case we can still laugh about them and their silly beliefs on such sites as The Daily WTF.

The lesson today is don't be Gehn, lest all of your creations crumble in front of your disbelieving eyes. Don't put yourself in a situation away from people who can tell you that you're doing something incredibly stupid and naive. A little bit of self doubt can go a long way; and it's much better in the long run to have asked someone for advice and succeeded than to have pushed forward stubbornly toward your own doom. The worst thing you can possibly do is assume you know everything.

Comment on this post (3 comments so far)

Latest comments:

Comment. by Abe (2008-04-19 01:04:08)

Once more to wiki once more. Hope it comprehendable. by Baronen (2008-04-20 20:40:17)

Dean. Save my purgid Text. by Baronen (2008-04-20 20:51:37)

Kane's Wrath

By Dean

(2008-04-05 11:36:55)

So on April 1, at around 0830 hours ADT, a guy named Doug hacked into my website and converted it into a LiveJournal. Luckily I was able to save the day using regular expressions!

Now that the world is safe (and blue) once again, it's time to write a post about C&C 3: Kane's Wrath.

I built my computer, Diaeresis (photos available), specifically for the game Command & Conquer 3: Tiberium Wars. Well, that's not entirely true. I was planning on purchasing a new PC in 2007 in order to play the games Bioshock and Portal, which were due out in the middle of the year. Then I heard news of C&C 3, yet another game in Westwood's original (and amazing) series of games. Even though the retarded monkeys had long ago purchased Westwood, dissolved most of its employees and crushed all creativity within a 10-kilometre radius of its headquarters, I somehow remained hopeful. So I built Diaeresis about a half a year ahead of schedule.

Needless to say I was disappointed by C&C 3's terrible plot hole-heavy story and decidedly un-Command & Conquer-like gameplay. Somehow EA with its many simian minds came to the conclusion that Tiberium (a toxic yet valuable substance that science-fictionally is eating away at the surface of the Earth, transforming it into something inhospitably alien) should be made into an inorganic crystal, instead of its previously almost-alive look. That's definitely my biggest gripe with the game, and indeed the source of the majority of the game's plot holes.

At the end of C&C 2: Tiberian Sun, Tiberium was in the process of converting all unprotected life into horrific monsters. During the events of C&C 2: Firestorm, very little recognizable life remained on Earth. Nearly all of it, be it plant, animal, terrestrial or aquatic, was converted into a Tiberium-based equivalent. Tiberium itself spread like a plant, indeed mutating terran plants to suit its proliferation.

But then suddenly in C&C 3, Tiberium is just this mostly inanimate crystal. The Earth itself is mostly fine. There are no horrible mutants flying around, no Tiberium-based life at all. Suddenly there are vast regions of the Earth that are not at all exposed to Tiberium. Suddenly the oceans aren't teeming with Tiberium to the point that ships can't move at all. It's as if C&C 3 weren't based in the same world as C&C or C&C 2 at all.

This and many other plot holes were not resolved in Kane's Wrath. (Ha! I bet you were expecting me to say the opposite of that!) I'm just as disappointed with Kane's Wrath as I was with C&C 3. The story itself was interesting, since everything happens from the point of view of Kane, the primary antagonist in all C&C games. Kane is a very charismatic and intelligent character, so it's always a good thing to see him on screen. Kane's Wrath did not fail to deliver.

Apparently realizing that C&C 3 was full of holes, EA made the story of Kane's Wrath take place before, during and after the events of C&C 3. This allowed them to fill a few of the less glaring holes, such as what happened to certain characters behind the scenes, or indeed how Kane managed to survive his own death in C&C 2. Some of the events in Kane's Wrath fit so well into the main story of C&C 3 that it almost makes me wonder whether EA left plot holes there on purpose in order to magnificently fill them in later. Honestly, though, I don't give them that much credit.

Kane's Wrath was fun, albeit short. I found out that the computer cheats in the later levels, and that really ruined the experience. But its story was good enough and fit disturbingly well into the main story, so I was definitely entertained by it. That is, afterall, the point of games.

Gameplay is exactly the same as C&C 3, except with these new special units called "epic units". All of the epic units are terrible wastes of money except for the GDI epic unit, which is utterly overpowered compared to the other two. I don't know how that slipped through the cracks, but maybe there will be a patch to balance things out.

If you liked C&C 3, then you'll like Kane's Wrath. It's exactly the same.

Comment on this post (1 comment so far)

Global conquest mode by Dean (2008-04-07 07:44:08)

Feelin' emo

By Doug

(2008-04-01 08:25:36)

Currently listening to: Touhou GST

Dear LiveJournal,

I was feeling sad, and I was feeling lonely. So I decided to go down to Wal-Mart on the weekend to end these dark times of my life by filling my computer with software provided by the retarded monkeys. Those monkeys were hard at it again making a new game, just for me. I'm not going to tell you what it's called or link to it or anything. Just that it's about a man named ~~Kane~~ Jeff and his ~~wrath~~ dirigibles. Yeah. Jeff's Dirigibles.

So I drove Jeff's Dirigibles around for a while, dropping bombs on everyone and everything but then suddenly Jeff gets him away from something I'll make fun of the marking ship is basically what started out in the whole comic if it looks like obviously drawn further jeaportizing the first 150 ARE showing her penis is not VERY very attractive from the desktop 3-D scene is it becomes implies What wake to go! I'm really happy about the 3-D scene because all of Jeff's Dirigibles look really well modelled.

Still listening to: Touhou GST

Later in the day, I played some drunken Guitar Rock Hero Revolution at the party. You know. The party. It was awesome. The girls were doing the non-video. I could have a requirement for their four feet all night long, if you know what I mean. Unfortunately that dick Todd came out of nowhere and stole the show with his Xbox. I guess in the end I can't really compete with Xbox. Not even after I showed them my Longcat.

That got me pretty depressed, which is why I bought the aforementioned game Jeff's Dirigibles. Dirigibles are cool. Me and the guys take Steve's dad's dirigible out on the town all the time. I love it when we pick up fly honeys (bees, that is) in that thing. I love all of my friends.

Except Jim. He's not even my Facebook friend anymore after what happened at Todd's Guitar Rock Hero Revolution party. Can you believe he actually fit all of that into his mouth? Pshaw. I know, right? C'mon. You gotta be kidding me.

Speaking of rodents, Janice needs a new source of mice to feed her pet snake since the pet store got the restraining order (thank you, Jim!). If anyone knows where she can get some, leave a comment up ons so we can hook Mr. Slithers up with some chow.

So as I was saying, at Todd's Guitar Rock Hero Revolution party was awesome. I got like a triple high score. I even beat Nick's high score. That was the highlight of the evening. Nick was right there, too, bragging about his bitchin' score to all the ladies. I whipped his ass what how! Zam! I was feelin' pretty good 'till Todd brought out his Xbox. The bastard.

So I was like, "Fuck that shit." And I took Nick's beer and drank it down and ran the hell out of there. High-tailed to the next city with my dad's dirigible. I think Matt was driving. I don't remember much since I was too wasted. I think someone must have slipped something strong into Nick's beer.

I don't remember much after that, but I woke up with the taste of stick tack in my mouth with my shirt on backward in ditch. Dunno where Matt went.

In short, it was the best $30 I ever spent.

Doug OUT

Comment on this post (4 comments so far)

Latest comments:

hey by jim (2008-04-01 09:12:48)

that's it by jed (2008-04-01 10:44:48)

What? by Doug (2008-04-01 12:13:25)

This is some kind of footnote. This webpage is awesome and can be viewed in any browser. Even ones that suck ass like Safari and Firefox. Isn't that awesome? This site is best viewed with browsers that aren't maximized on large-resolution displays (> 1024 pixels in width). But then again, if you are running a large resolution and browsing maximized, then you're a terrible person so you don't really deserve to see this site at its finest. Jerk. I mean, seriously. I spend all this time making a nice site and your silly browsing habits ruin its look. That's really cold, man. If you're using IE6, then in order to see the cool avatar effects you need to enable JavaScript. No rights reserved by Dean Whelton (who is awesome) of any of the content, images, design, backend or electrons used in this site. Steal at your convenience. None of it is worth stealing anyway, so there. I have even made an RSS feed for more efficient theft of my intellectual property: CLICK IT NOW!!! Now, don't say I'm not generous. I guess if you want to know more about me, you can visit the about page. It's not really an about page, though. It's just one of the first posts. I don't feel like making a real about page. Are you really wasting time reading this? Go outside or something.