Code.Implant

The Videogame Lifecycle

Caught this on Digg: The Life Cycle of a Video Game. Unfortunately (or fortunately?), it hits on some truths.

The Art of Living

Chinese philosopher Lao-Tzu:

“The master of the art of living makes little distinction between his work and his play, his labor and his leisure, his mind and his body, his education and his recreation, his love and his religion. He simply pursues his vision of excellence in whatever he does, leaving others to decide whether he is working or playing. To him, he is always doing both.”

CarPaint

A few days ago I saw a documentary on Discovery HD Theater called "BMW: An Expression of Joy" where artist Robin Rhode attached paint spray nozzles to the tires of a BMW Z4 and used the vehicle as a paintbrush on a large canvas. You can see the result and more info on this at the Expression of Joy website.

After watching the documentary I decided I wanted to do the same thing. How cool would it be to drive a vehicle that painted with its tires? What kind of artwork could I come up with?

Not wanting to take forever on the project, I moved quickly to create a gameplay prototype. The first problem I ran into, though, was that to reuse my existing 3D codebase would require more work than I wanted to spend on a prototype, particularly since I needed to integrate a physics engine to get the effect I wanted for the vehicle dynamics.

So, I took a look at Flash, noticed that there were a few 3D render engines and a few physics engines, and figured "why not?" Granted, I've never used Flash before, but I went to Adobe's site, downloaded the Flash 30-day trial, and went to town.

A few days later, and I have a prototype of CarPaint: http://www.gamesunplugged.net/CarPaint3D.html. If you check it out, be sure to click the Help button to see the controls and instructions.

It turns out that BMW also created an iPhone App off this idea - something I just found that out as I searched for the name of that documentary for this post. I'm going to download it and check it out. In the meantime, I'm going to let the Flash version cook for a little bit as I look at porting it over to a Windows-based application using my engine - and of course consider I'll consider the iPhone App route.

Small Wins Make Big Wins

I'd like to thank JD Meier for reminding me of the importance of small wins this morning through his blog post "Don't Always Go for the Long Shot". It's a great reminder that success doesn't come all at once.

Everyone wants to be successful. Entrepreneurs want successful businesses. Athletes want to win. Engineers want to build perfect solutions.

The problem is that most of us try to be successful through grand strategies and big plays. Entrepreneurs hold off on starting a business until they have that "killer app" idea. Baseball players try to hit the home run. Engineers try to design a solution that will address any possible situation. Meanwhile, another company comes out with a better "killer app", the baseball player strikes out trying to "swing for the fence", and the engineer ends up with an over-complicated solution that has to be scrapped because it doesn't work.

As JD Meier reminds us, the key to winning isn't the big play. The key to winning is to build momentum off a series of small wins. By focusing on small goals, small tasks, and small features, we allow ourselves to adapt to change, to measure tangible progress, and to celebrate successes early and often.

Never for Duke Nukem Forever

I was wondering how much longer the game Duke Nukem Forever would be in development. But after 12 years of development on the never-ending game, it looks like developer 3D Realms is out of money and shutting down. I was actually looking forward to the game.

3D Realms is one of the developers I wanted to work for at one point in my life, so it's a little disappointing that they've gone down. Then again, if it's taking over 12 years to make a game that will likely never be completed, then it was probably not all that productive of a place anyway.

More on Reuse

Jeff Atwood of the Coding Horror blog posted his latest on reuse with an article entitled "Don't Reinvent The Wheel, Unless You Plan on Learning More About Wheels", in which Atwood advocates reinventing the wheel as a "call to arms for deeply educating yourself about all the existing solutions".

Avoiding the reinvention of the proverbial wheel is a standard bit of received wisdom in software development circles. There's certainly truth there, but I think it's a bit dangerous if taken too literally -- if you categorically deny all attempts to solve a problem with code once any existing library is in place.

I don't think anyone is saying that you should avoid reinventing the wheel at all costs. The reality is that there are times when rolling your own is desirable. As Joel Spolsky said:

And that's where I learned a key lesson in software architecture: for your most important, mission critical stuff, you have to use a tool that is one level lower in abstraction than ideal. For example, if you're writing a cool 3D shoot-em-up game (like Quake, around the same time period) and your key number 1 differentiator is to have the coolest 3D graphics, you do not use whatever 3D library you can find. You write your own, because it's fundamental to what you do. The people who use 3D libraries like DirectX are using them because they are trying to differentiate their games on something other than 3D performance. (Maybe the story line.)

Bottom line: the issue of reuse is not nearly as black and white polarizing as the Coding Horror blog wants to make it.

There are times to reuse and times to reinvent the wheel - knowing the difference is one of the keys to being a good software developer. Even beyond that, it really goes back to basic engineering tradeoffs.

In most cases, however, the software developer who embraces reuse as much as possible will be in a better position and have better opportunity than the software developer who likes to reinvent wheels. It's often a missed fact that invention and innovation occurs only through an iterative process of work built on top of prior work, which quite frankly is pretty much the definition of reuse.

Besides, as Jesse, a commenter in the Coding Horror blog post said, "Doing something that you know can be done is not invention."

On Reuse

I believe in software reuse. If you want to release a product in today's world then I believe it's too costly to not reuse as much software and technology as you can within your given context.

Granted, reusing software is not always the best solution, but more often than not it is a very strong candidate. I believe that if an engineer or organization is not going to reuse software then the onus is on them to provide a strong enough rationale why not. And if the engineer or organization can't defend their rationale with good reasoning? Then the argument against reuse is not strong enough.

Unfortunately, not everyone thinks this way. That's not surprising. Engineers like to do fun stuff and reusing software or technology takes away some of that fun stuff. I get it. I like to do fun stuff too. I used to write my own rendering engines and XML parsers and Winsock code, but then one day I woke up from this comatose state.

My world changed when I stopped looking at software development at the technology level and started looking at the product end state where adding value to the product became my number one priority. The how and technology used were still important, but they were driven by adding value.

Now, there are times when reuse shouldn't be used: new technology research, education opportunities, and so on. But most of us live in a world run by businesses that build products for customers and minimizing cost and schedule are important to the business, and reuse is a way to ensure cost and schedule are minimized.

So, when in this world of business I hear something against reuse I just shake my head. Some developers just need to go away. Really. They make the world a less productive place.

To cap this off, here are some actual excuses I have heard against reuse - along with my own thoughts on the excuses.

Mr. No Reuse: Software ABC doesn't provide every feature we need and won't be just a drop-in for us, so we can't use it.
Me: I hope you're joking. Not every piece of software can be written to your liking.

Mr. No Reuse: Our product has special needs.
Me: Special needs? Such as, minimizing cost and schedule so we can make money? No problem or product is so special that we should limit our reuse. We should maximize it.

Mr. No Reuse: I want to learn about XYZ technology and this is the best opportunity for me to do that.
Me: Good for you. I support continuing education. Now go start your own business and you can do that all you want.

Mr. No Reuse: In Software ABC, I don't like the API or how they do things.
Me: I'm sorry they didn't ask for your opinion when they designed it; however, it does the job and thousands of other developers use it already without complaint.

Unfortunately, people like this really exist. Don't be one of them.

Passion

This guy rocks. I like his direct, no-bullshit style. His message? Love what you do. Have passion. You will succeed. Look and listen. He's a living example of his message.

 Gary Vaynerchuck of Wine Library TV:

h/t Jeff Tunnell

Software Development Like Golf?

I'm a fan of analogies. While sometimes they can be like a bad joke, othertimes they can be an effective means for communicating a complex topic.

Software Development is one such topic, and I often deal with trying to communicate the challenges of software with those who have little or no experience in it, so finding good analogies is always helpful for me.

Bernie Thompson took one such shot at an analogy in a post entitled "Software Development is like golf...". His premise is that your chosen path to the pin is always the problem, and to succeed you have to weigh your capabilities (people), the course (technology), and the conditions (the market).

As a (very) amateur golfer, I can agree with this analogy and it's one I may even use myself. The only disagreement I have with it is that this analogy can be applied to most engineering disciplines. That is what engineering is about anyway: balancing factors and making tradeoffs.

Still, it's a good analogy. In engineering you can't always "go big, or go home" as I like to call it on the golf course, and to be successful you have to be willing to adapt to changing conditions in your design, market, and customers.

In fact, in most sports the most successful teams and individuals are the ones that can adapt to the evolving situation of the game, and the way to adapt to the situation is to constantly assess tradeoffs like the ones Thompson chose to address in the game of golf.

Some Principles of Design

I'm trying to document some basic, yet ever-important software design principles into a list that I can reference and expand on in the future. You often see these principles discussed individually, but I believe that they need to be considered collectively.

So, this is what I have so far:

• The KISS principle - Keep It Simple Stupid
• Iterate early, often
• Create Functions that fit on one screen (20-25 lines max)
• Create Classes with one role and purpose
• Usefulness first, usability later
• Plugins for extensibility when possible

It's nothing groundbreaking, but it's a start of basic principles software developers should consider. Any others?