Our Blog

where we write about the things we love



Software development, action hero style

Hollywood is awesome at modelling reality. Not only do they model the existing world over and over again, they often make it better. So I started thinking: Is there anything we can learn from Hollywood's improved model of the world when it comes to software development? And the answer is, of course, yes!

When you want to learn something, you try to learn from the best. So I have decided to focus on two of the most powerful forces in Hollywood – Steven Seagal and Chuck Norris. Chuck and Steven offer a lot of valuable information when it comes to software development. But contrary to what most developers think, you want to follow the ways of Steven and not Chuck.

Chuck Norris' main feature is his legendary slow motion repeats of perfectly executed round-house kicks. And however mesmerising they might be, they are one of the worst things one can do when developing software. A perfectly executed round-house kick will of course tear down a building if needed, but Chuck's focus on the slow motion repeats are just plain wrong.

You want to stick with doing one thing once. If you need to "take care of a problem," do so efficiently, but only do it once. If we keep making repeats of something, however perfect the solution might seem, it will most likely cause maintenance issues. Just imagine if Chuck realises that he can kick higher, harder or faster. Replacing all his old scenes with this new-improved kick will take a lifetime, and we might still find an old kick in some of his lesser-known masterpieces. And even if Chuck's round-house kick looks perfected, we should never underestimate Chuck's ability to perfect the perfect.

The same is true with our code. However perfect our code might look, we might be able to improve it in the future. And replacing code in many different places can introduce subtle bugs. Highly repetitious code can also point towards lack of cohesion. A lot of repetition can indicate that several pieces of code are needed to do the same thing. This can, in a lot of cases, be "fixed" by packaging our code differently, making it more cohesive.

Chuck has another feature that should also be avoided in software development. Nobody mocks Chuck Norris and gets away with it. Everyone knows that. Those who don't, however, will not be around to tell us about it. This is a huge problem when it comes to software development. When building software, we should enable “mocking”. Not by commenting on the developer’s mother.

In software development, “mocking” is a technique used to “fake” objects.  By abstracting away parts of the application, it can then be “mocked.” That means that a fake version can be created, one that we can control thoroughly. By making pieces of our code "mockable," we open up a whole host of possibilities. It becomes possible to implement very powerful testing scenarios. By mocking pieces of our application, we are able to test small units of code without depending on other chunks of code. This makes our testing much more granular and reduces the risk of introducing bugs. But there is more to it than that.

Testability is obviously the main drive behind mocking objects for most people. But it also makes it possible to mock application features that could make it impossible to run the application in certain situations. Say, for example, that the application relies on a central database. If a developer decides to work on the application from home, he or she might not have access to this database. This might make it impossible for the developer to work and therefore force them to spend time with their family instead. Or maybe the application needs some specific piece of hardware, such as a flux capacitor or continuum transfunctioner. Since these are very rare, most developers will not have access to them. By being able to mock these pieces, he or she can still work on the other parts of the application.

These features of mocking are very good, but there is one more feature that is often forgotten. That is the ability to build our application piece by piece. By defining interfaces for discrete pieces of our application, we can initially mock these parts and get the application up and running without having all of it completed. This makes it possible to initiate user testing or client demonstration before the application is completed. It also makes it possible to delegate work in a completely different way. One team can focus on working on the DeLorean, while another team can focus their energy on creating the flux capacitor. And as long as the interface has been well defined, connecting the two pieces when they are complete should be very easy.

So, Chuck can teach us a lot about what we should avoid, but what can Steven teach us?

Well, Steven is a devoted follower of the efficient Eastern ways. His focus is on simple and efficient solutions. There are no big round-house kick gestures. He focuses on small movements with maximum effect. He takes every large problem and divides it into small pieces. He efficiently handles one assailant at the time, just as a developer should.

When creating software, one should focus on breaking down each problem into as small a piece as possible and then tackle them one at a time. This makes the code easy to read and very flexible. Just as when Steven has to modify his defence when the bad guy pulls out a knife at the last minute, we can easily modify a small part of our code when the problem changes. If Steven had his entire fight predefined, a change in variables would potentially throw him completely off balance, potentially ending the movie ahead of the one hour and thirty minutes that were planned.

The same is true for coding. If a problem is solved by one big, rigid piece of code, and the problem changes, all of the code must be revised. If it is instead written as a lot of smaller pieces, it might be possible to handle the change with a much less invasive procedure. Maybe the execution just needs to be branched. Or maybe we can compensate for the change and keep it going.

Steven has also taught us one of the most important rules in software development. Assumption is the mother of all stuff-ups. Building and designing software is always going to include assumptions. Unfortunately, assumptions are often the reason that we introduce bugs. We will always have to make assumptions during software development, but we need to be careful about what we assume. The difference between a senior developer and a junior developer is often a lot more than just technical knowledge. To be perfectly honest, a grad might actually know more about the latest technologies than a senior, as he or she has probably studied it recently. But the senior developer will have more experience and should therefore make better assumptions.

Somebody once said "knowledge is the sum of all the failures you have gone through." A senior developer has probably failed a lot more and, thus, gathered a lot of knowledge. So by using the senior developer during the initial stages of a project, he or she should be able to make some well thought through assumptions and also highlight any potential problem areas based on those. Through thorough evaluation and informed assumptions, the number of problems should be greatly reduced. Steven's movies have taught us this.

When somebody assumes a person is dead, they should evaluate that assumption before going forward. Was there a body? Was there a huge amount of blood that would indicate bodily injury beyond repair? Was the person a bad guy? Was the person Steven Seagal? If there is a body, the assumption is good. If there is enough blood to fill a pool, it is also good. A bad guy is also much more likely to die from being stabbed by a toothpick than a good guy is to die from a serious gunshot wound. And finally, if the person is Steven Seagal, the assumption that he is dead is obviously wrong. So, assumptions are necessary, but try to evaluate them and do so using the best resource available.

Posted by: Chris Klug, Senior Developer | 23 March 2010

Tags: Software Development, Chuck Norris

Related blog posts

Blog archive

Stay up to date with all insights from the Intergen blog