Coding Horror

Garry's Mod is a fascinating study in guerilla programming. It's an incredibly successful mod for the game Half-Life 2 that essentially converts it into a giant sandbox powered by Lua.

There are a large number of Lua scripted 3rd party modifications for Garry's mod. In a server running the Roleplay modification, you have money and tools which enable you to sell items on the map, or to interact with other players. Newer game modes have inventories and highly advanced capabilities including Item Combining and Stock Markets.

Another example is "Wood Wars", where teams make vehicles or buildings out of wood, and then attack the other team's creations with weapons made up of anything from gas canisters with thrusters on, to shells launched from makeshift cannons.

It has also become a tool for users to create music videos, comics and other forms of Machinima.

If Garry's Mod sounds a lot like a full-blown development environment inside a 3D world governed by physics, that's because it is. But it started out as something much simpler. In this recent interview, Garry describes the humble beginnings of his eponymous mod:

Garry Newman: [GMod] was a total experiment. I was really out of my depth in the Source engine at that point. I had no idea how anything worked, but managed to throw version one together by thinking back into Half-Life 2--to work out where I'd seen the feature before. For example, the rope gun. I didn't know how to make rope so I thought back and realized that the Barnacle's tongue was rope. So I just pretty much copied that code into a simple weapon and it worked. Well, kind of worked. This was one of the good things about GMod. I could see the right way to do stuff because a lot of the time Valve had already done it somewhere else in the code. So their code would teach me. I'm not the kind of person that can learn from books, I really need working examples.

Shack: What would you suggest to mod teams to help them avoid getting held up on the details? Start with a simple idea and build on it?

Garry Newman: I would recommend the iterative method to anyone. The main argument against this is that they don't want to release a shit version of their idea and turn everyone off. Fair enough, but it's going to be so much worse if you work your balls off on it for 2 years then release, and your idea is still rubbish. Iterating would have let you know that this idea isn't working out, so you could adjust it. In every update you're picking up more people playing your mod. You build a community.

Garry cites classic sandbox games as his inspiration, such as SimCity, The Sims, and Rollercoaster Tycoon. But I'd say the current version of GMod goes far beyond those games and delves deep into software development territory -- he's created a sandbox for creating new sandboxes.

I previously documented the "Ultimate Developer Rig" I'm building for Scott Hanselman:

• Building a PC, Part I
• Building a PC, Part II
• Building a PC, Part III

I added a little bit of PC quieting magic as a finishing touch. Here's a picture of the final interior, with two types of damping foam -- generic eggcrate foam and thin PAX.MATE style foam. Which one I use depends on how much room I have to work with in each area of the case.

The goal is to build a sound dampening chamber around the motherboard, CPU, hard drives (particularly the hard drives), and video cards. Instead of the typical hard, reflective metal inside a case, the sound now bounces off rough, absorbent foam surfaces instead. You can't see it in this shot, but the case cover has a layer of PAX.MATE foam applied as well to complete the "chamber". If you've ever been in a recording studio with foam damping material on the walls, you know how effective it can be at absorbing and diffusing sound. As I discussed in my earlier article on building a quiet PC, the foam damping is a final, finishing step. It won't magically convert a noisy PC into a quiet one, but it can make an already quiet PC that much quieter. The effect is subtle but definitely audible.

At any rate, the rig is now burned in, complete, and ready to ship to Scott. I was surprised to find that the 64-bit version of Vista produced better Windows Experience scores on the exact same hardware: Scott's system now scores 5.9 across the board, except for memory, which scores 5.8. Go figure.

I hope you found the series useful and fun. I know I did. We also recorded a Hanselminutes episode where we discussed the philosophy behind the build, and answered a bunch of listener questions; listen to the show for background.

But in the meantime, if this piqued your interest, now it's your turn to build a PC. There was a lot of interest in doing a PC build jamboree at the office, and I invite everyone to participate... at least virtually. I can offer the following refined build menu based on my experience with Scott's build-- and recent Intel CPU price cuts.

	Basic		Premium		Deluxe
Case	Antec NSK 4400	$80	Antec Sonata III	$150	Antec P182	$170
PSU	(Included 380w)		(Included 500w)		Corsair 520HX	$130
Mobo	EVGA 680i	$155	EVGA 680i	$155	EVGA 680i	$155
Memory	Mushkin 2GB DDR2-1066	$160	Mushkin 2GB DDR2-1066	$160	Mushkin 2GB DDR2-1066    x 2	$320
CPU	Intel Core 2 Duo E6300 1.86GHz	$164	Intel Core 2 Duo E6600 2.4GHz	$223	Intel Core 2 Quad Q6600 2.4 GHz	$375
CPU cooler	Scythe SCKTN-2000 "katana"	$30	Scythe SCMN-1100 "mine"	$33	Scythe SCNJ-1100P "ninja"	$40
Video	MSI 8600GT 256 MB Silent	$105	EVGA 8800GTS 640 MB	$350	EVGA 8800GTX 768 MB	$487
HDD	Hitachi Deskstar 500GB	$120	Hitachi Deskstar 500GB x 2	$240	Raptor 150GB	$165
					Hitachi Deskstar 500GB	$120
DVD	Sony 18X SATA DVDR	$34	Sony 18X SATA DVDR	$34	Sony 18X SATA DVDR	$34
		$848		$1345		$1996

Of course, prices are only valid as of the time I write this post. And feel free to substitute any items between the configurations as you deem necessary. It's your PC; build it the way you want.

A previous comment from Bob McCormick summarized my build philosophy remarkably well:

Building a PC at least once gives you a deeper understanding of your hardware. It isn't going to fill a specific checklist item in your resume, but the desire to try it at least once is part of the passion that a true craftsman should have for his tools. I think it's similar to how you'll frequently see the celebrity chefs on PBS go visit a winery, an organic farm, a bakery, and so on. They aren't going to learn something there that will make or break their ability to cook a specific dish. But as master craftsman they're passionate about their tools and ingredients. They want to know everything they can about them.

Building (and overclocking) PCs isn't for everyone. But I hope my series illustrated that it isn't particularly difficult -- and it sure can be rewarding if you have the time and inclination.

Most software projects fail. But that doesn't mean yours has to. The first question you should ask is a deceptively simple one: how big is it? Steve McConnell explains in Software Estimation: Demystifying the Black Art:

[For a software project], size is easily the most significant determinant of effort, cost, and schedule. The kind of software you're developing comes in second, and personnel factors are a close third. The programming language and environment you use are not first-tier influences on project outcome, but they are a first-tier influence on the estimate.

All other things being equal, large projects tend to fail. That's probably not news to anyone familiar with Metcalfe's Law and Diseconomies of Scale.

So if the three most important factors determining the outcome of a software project are...

1. Project size
2. Kind of software being developed
3. Personnel factors

... in that order, what else is left? If you can get those three factors under control-- if you're developing a small, simple CRUD database website with a dream team of tightly gelled superstar developers, are you done? Of course there's never any guarantee of project success, but can you at least say you've performed adequate risk management?

I'm not so sure. According to Bill de hra, you also have to consider the three pillars:

The conclusion I draw from this and my own experience having migrating my fair share of source trees is that the version control system is a first order effect on software, along with two others - the build system and the bugtracker.

Those choices impact absolutely everything else. Things like IDEs, by comparison, don't matter at all. Even choice of methodology might matter less. Although I'm betting there are plenty of software and management teams out there that see version control, build systems and bugtrackers as being incidental to the work, not mission critical tools.

Bill's analysis came as a pleasant surprise to me, because it's exactly the same conclusion I reached while working with Microsoft's Team System. Once you get the three pillars in place...

1. Version control
2. Work item tracking
3. Build system

... it's a major improvement in software engineering quality for any software development project. Of course, you don't have to use Team System to get there, but a huge part of the value proposition for Team System is that it's "software engineering in a box". It provides tight integration between these three pre-installed pieces, with no complex configuration required.

However you get there, it's just plain good software engineering to have these essentials-- the three pillars-- in place before proceeding too far on a software project.

So if we set up our dream team of tightly gelled superstar developers working on our small, simple CRUD database website with an outstanding best-of-breed integrated set of source control, work item tracking, and build tools-- are we done? Have we mitigated all the major project risks and set ourselves up to effortlessly, weightlessly fall into the pit of success?

Sadly, no.

Bill notes that choosing a framework poorly suited to your problem domain can have a crippling effect on your productivity, too.

The relative verbosity of programming languages isn't the interesting thing; nor is typing doctrine. What's interesting is the culture of frameworks and what different communities deem valuable. My sense of it is that on Java, too many web frameworks - think JSF, or Struts 1.x - consider the Web something you work around using software patterns. The goal is get off the web, and back into middleware. Whereas a framework like Django or Rails is purpose-built for the Web; integrating with the internal enterprise is a non-goal.

ETag support is just one example; there are so many things frameworks like Rails/Django do ranging from architectural patterns around state management, to URL design, to testing, to template dispatching, to result pagination, right down to table coloring that the cumulative effect on productivity is startling. I suspect designing for the Web instead of around it is at least as important as language choice.

So maybe the real lesson here is that software project success isn't about doing any one particular thing right; it's the much more daunting task of not doing anything wrong. It certainly gives you a new appreciation for those rare successful software projects that somehow managed to snatch victory from the jaws of defeat.

Paul Heberli and Bruce Karsh proposed something they call futurist programming in 1994:

We believe there is a great opportunity for Futurist principles to be applied to the science of computer programming. We react against the heavy religious atmosphere that surrounds every aspect of computer programming. We believe it is time to be free from the constraints of the past, and celebrate a renaissance in the art of computer programming.

We find that many of today's computer systems are hopelessly wasteful and inefficient. Computer hardware has realized performance increases of a factor of more than 200 in the last 20 years, while in program design very little progress has been made at all since the invention of the subroutine. We would like to see the science of programming advance as quickly as other fields of technology.

We believe that undergraduate education spends too much time conveying dogma, instead of teaching a sound theory of program design that helps programmers create good programs. Universities should provide students with less religion, and much more practical experience in making and analyzing small, fast, useful and efficient programs.

Futurism was a primarily Italian art movement in the early twentieth century; the most succinct summary I've found is on this Futurism resource page:

Futurism was an international art movement founded in Italy in 1909. It was (and is) a refreshing contrast to the weepy sentimentalism of Romanticism.

The Futurists loved speed, noise, machines, pollution, and cities; they embraced the exciting new world that was then upon them rather than hypocritically enjoying the modern world's comforts while loudly denouncing the forces that made them possible. Fearing and attacking technology has become almost second nature to many people today; the Futurist manifestos show us an alternative philosophy.

The 1994 Manifesto of the Futurist Programmers is wholly based on the 1910 Manifesto of the Futurist Painters. But perhaps the best explanation of what futurist programming actually means is tucked away in the Futurist Programming Notes:

We REJECT

• COPIES of work that has been done before.
• USER CONFIGURABLE software.
• PAPER documentation.
• Any program that WASTES users' precious MEMORY.
• Any program that WASTES users' precious TIME.
• System administration and ADMINISTRATORS.
• Anything that is done for the convenience of the programmer at the expense of the user.
• Extensibility, Modularity, Structured Programming, Reusable code, Top-Down Design, Standards of all kinds, and Object-Oriented "METHODOLOGIES".
• All additional forms of USELESS and IRRESPONSIBLE WASTE.

It's an admirable set of goals. Of particular interest is the futurist reverence for programs that dynamically generate code; this presages the current renaissance of dynamic programming languages, ten years later. Apparently the future is now.

The core futurist philosophy that religion and dogma of all kinds should be examined critically is an important one. I've written many times about certain accepted "wisdoms" in software development that are counter-productive if not downright dangerous. I think you should be constantly questioning the status quo, and solidly skeptical of so-called best practices. But this, too, can be taken too far. I intentionally omitted the last sentence of the futurism summary on the Futurism resource page:

Too bad they were all Fascists.

You have to be careful that rejecting dogma doesn't itself become a kind of dogma. Sometimes, a bulleted list of best practices can be helpful, too.

Ned Batchelder shares a complaint about the Mac application installation process:

Here's what I did to install the application Foo [on the Mac]:

1. Downloaded FooDownload.dmg.zip to the desktop.
2. StuffIt Expander launched automatically, and gave me a FooDownload.dmg Folder on the desktop.
3. At this point, nothing is happening, so I opened the folder, inside was a FooDownload.dmg icon.
4. I opened that, a license agreement appears.
5. I agreed to that, and a window appears with an application icon, and instructions to "Drag this icon to your Applications folder".
6. I have to find the Applications folder, and drop the icon into it.

At this point, the application is installed. To clean up, I had to:

1. Close the Applications folder.
2. Close the window with the dragging instructions.
3. Close the FooDownload.dmg Folder window.
4. Get rid of the three (!) things on the desktop: The dmg, the FooDownload.dmg Folder, and the FooDownload.dmg.zip file.

To me, that seems like a lot of manual steps. In the Windows world, you'll sometimes find shareware where the author gives two options: an installer, or a zip file where you can do everything yourself. The Mac installation process is like the Windows do-it-all-yourself case.

Again, I'm not trying to slam the Mac. I genuinely do not understand why on a platform that makes things really simple, where the mantra is that stuff "just works", ordinary users are expected to do all these manual steps.

I've often wondered the same thing-- why does the Mac require the user to jump through a bunch of manual hoops to install an application? Why not use a traditional installer (a.k.a. setup.exe) that automates this manual work for you?

To be fair, Windows applications aren't always delivered with installers, either. One of the apps I use is Kenny Kerr's excellent Window Clippings. It's delivered as a single executable in a compressed ZIP file. It's a pleasingly simple arrangement, but it's also more work me, the user. Consider how I "install" Windows Clippings:

I have to:

1. Extract the executable from the ZIP file.
2. Create a WindowsClippings folder in the C:Program Files folder
3. Move the WindowsClippings.exe file to the new folder I just created
4. Create a start menu shortcut for WindowsClippings

That's a lot of tedious, error-prone steps I have to perform before I can run the application. And no two users will have Windows Clippings installed the same way. Some may opt to run it from their desktop, or a temporary folder, or some other inappropriate location. Is this really what we want to subject our users to?

Even as a power user, I find this level of control not only unnecessary but onerous. That's why it's so strange to me that the "normal" Mac install parallels the sophisticated "power user" Windows install. A typical user doesn't want this level of control, and they certainly don't want to learn about disks and folders. They just want the application to work. Wouldn't a big giant button that says "Install Me" be a better experience for the user?

Traditional Windows installers may be easier than a Mac-style manual install, but they aren't exactly model citizens either. Most installers ask users dozens of questions across multiple wizard pages, along with the inevitable end user license agreement you get strongarmed into accepting.

The WinAmp installer is fairly typical. It's five pages long, and asks me to decide the following:

• Do you accept our EULA?
• What program options do I want installed? Visualization? Extra Audio Output? User Interface Extensions?
• What icons do I want installed? Start menu? Desktop? Quicklaunch? System Tray?
• Do I want to associate WinAmp with audio files? With CDs? With playlists?
• Where do I want WinAmp installed; at what path?
• Do I want shared settings for all users or individual settings?
• What are my internet connection settings? Do I have a proxy? Do I want to download needed codecs?

That's a whole lot of thinking necessary to install a tiny little music player. And that's the minimal install-- the lite version that the WinAmp site does its best to hide from me!

Perhaps a better approach is the "No-Questions-Asked" installation featured in JGSoft applications.

If only more applications-- Mac or Windows-- made it this easy on the user. That's about as close as we can get today to the big giant "Install Me" button I think most users are looking for.