It's never to late to learn new skills

It is now roughly a year since the last post. It was an interesting year but I won't be writing about it now, perhaps sometime in the future i will. Instead I am going to write a little about my new project in personal development.

Learning some basic coding skills

I realized I have spent the last 20 or so years learning all the basic skills for making games except for programming so it is about time I do something about that and get a decent hunch about how to do the programming part too.

I will primarily focus on learning how to program in JavaScript. This choice is based on three fundamental arguments.

1: JavaScript is sufficiently capable of teaching me what I need about Object Oriented Programming and Test Driven Development. From what little I understand about it these methods of writing code is rather transportable between different languages. It is also rich enough for making fully fledge gameplay although perhaps not the most ambitious scales of simulations such as individually thinking soldiers in big armies or fluid dynamic physics and such but those are not needed.

2: JavaScript is coming very strong in the world of game development. My prediction says that in a few years most people who build games build them with JavaScript, CSS and Html5. And several will be using various webgl libraries so create nice 3D games too.

3: JavaScript has an awesomely fast speed of iteration. Change something and get feedback in the implemented game within about 2 seconds. About the same speed for getting feedback from jsTestDriver for unit tests or FireBug/Chrome console for coding errors. This rapid Cycle Time extends to the deployment pipeline which, by having a git clone in the public area of My Dropbox all I need to do to send a test product to a tester on the internet is:

- Git pull

- Paste the link to the test subject. Or make them refresh if they already are there.

The new version is live and in use within about 10 sec on average a bit depending on how moody dropbox is, the time ranges from about 4 sec to up towards a whole minute whenever dropbox is having problems or suffering from heavy use or whatever it might be that makes it slow during american office hours.

There are a few more arguments I could raise about the choice of tech to study through such as having the internet full of people who are going through the same experience, lots of open source material, plenty of documentation with browser API's and so on. Now i got to go back to figuring out how to replace nasty if sandwiches with less horrible code.

Another good reason is that a good friend and great programmer said something like "JavaScript feels so rebellious compared to C". I like rebellious things.

Facebook tries to implement a global nation

The latest hubbub about Facebook and their plans makes an interesting case. From my perspective they are trying to create a kind of internet government. If they reach any level of success there will be all kinds of systems waking up to protest. The other governments come to mind as an example.

Countries commonly frown upon anyone who creates their own currencies for their citizens, just as one of many examples of things that might become a good drama of scale.

Priorities and dynamics

An interesting problem for prioritizing an agile project is the relationship between what is most important and what is needed. This might seem as a paradoxical problem as the thing which is needed is the one which is important. But it is not, and in this post I will try to note down how this can be.

A crude summary of the concept of prioritization might say it is an activity which prevents you from working on the wrong thing. Commonly a set of features which makes the product reach a critical use case. This activity also takes a look at these features and breaks them down into further prioritization to make the product tighter. Then you start building it.

So far so good, to describe why this is not quite as simple as just figuring out the priorities I will fall back on my usual comparison with music production. When you are about to create a piece of music you will have references, either explicit ones that you talk about with the production team or implicit ones that you are silent about or even innovations. These references help you prioritize. This is practically done by something called music analysis and there are some models for this. The ones I use have a mix of formal and informal properties and I won’t dig into these more than describing the simplest level.

Imagine that you listen to a song, now think about which thing in this song is the loudest. *waits a little* Ok, you found an important instrument, maybe a snare drum, a base or something else. Then think about an instrument that you hear quite often. *waits a little more* Ok, you found another important instrument.

In the world of music production this analysis keeps going on for quite a long time, it keeps on going on during the production and it is also done on the finished song. You might start with the hi-hat which is relatively quiet, then a cymbal appears, then a sidestick, a kick, a ride, a cymbal fill and a snare drum. That’s a reasonable set of instruments used to bring in the drums. And you will use the same hi-hat at a few different intensity levels a lot of times before you are done.

The variation of experienced intensity or even volume is sometimes described as dynamics. A good song will have a lot of almost quiet and very subtle sounds going on which gives ambience, harmony and feeling to the whole song. Without these your music is crippled. Imagine making a song with only the loudest and most intense instruments. Some musical genres almost do this, electronic dance arrangements come to mind but these also contain subtleties which are harder to put your finger on.

Now imagine that you have very little experience with music but the company you work for has decided that it is strategically important that you manage the production of the music played in the marketing campaigns for the coming five year. It has to be about five minutes long and sound a bit like a disco song made in the 70’s, and you have a budget which affords you two people working for about a month.

This is a relatively easy mission for an experienced music producer, but it’s quite challenging to the beginner. When you meet your two musicians that will make the music for you during the coming month and you describe your mission they will start asking unpleasant questions. Maybe, so which of the 70’s disco songs should we take our influences from? Since there are vocals in 70’s disco we’ll have to figure out who will sing and what that will cost. How good of a singer do we really need? Is it ok if the singer is a bit flat? Or maybe better to remove the singer and then aim at a more instrumental arrangement? Oh, since you can’t answer these questions for us let’s just listen to this reference and prioritize the parts you think are the most important, then we’ll put them in the song one after another until we run out of money.

So now we have figured out that the base, the kick drum, the organ and the vocals are the four highest priorities. Which one should we finish first? This is a kind of question that will kill you if it happens in the music industry. In this particular example case it is a symptom of a conflict which is based in lack of understanding between the customer and the production team. The two musicians know that they can’t reach the goal of the client on budget and starts to force the client to reduce the scope. To successfully navigate out from this problem the client has to budge on something which was defined in the strategy.

If this happens in the music industry you got a decent solution, just buy the song you want from whoever made the original in the 70’s. In the world of interactive software you don’t have this luxury, your options are limited and all of them are unpleasant. The statistical solution is to start answering the questions and actually building the prioritized things until the money is spent. The market will treat your product as it deserves.

Interactive software, just as music, is riddled with challenges of a dynamic nature. I’ll pick the easy part and talk about feedback here. An example of very intense type of feedback in interactive software is a shaky camera movie. The user clicks a button and then a movie starts playing where the camera shakes and there are loud sounds. A less intense type of feedback is a slight highlight on the button which lights up when the player places the mouse cursor above it.

Imagine that you need to prioritize these two against each other. Which is more needed, which is more important? The answer to this question will depend on who you ask. From my perspective it really depends on the dynamics of the overall production and your concept but the general notion is that increased dynamic range is better than a focused one.

The other day I came upon a tactical production technique which helps with this problem but it appears to have been invented for another purpose, which was to help the team finish within budgetary restrictions. The tactical solution is to bring in items from the whole spectrum of priorities to each product iteration, aka sprint. This has to be done with some consciousness of course, pick suitable low priority items to go with the high priority ones.

This way your metaphorical “music” will end up having Drums, rather than a Snare and a hi-hat. But who is the drummer? ... that's another topic.

Corollary definition for design

If design is a process which develops the value of an idea. Then a corollary to this might be:

- Design is aimed at reducing waste.

Maybe this lean perspective is the source of the first definition but I would not know.

Erlang vs. Metcalfe

In the life of Game Designer we can get a better understanding for the concept of quality by combining two old and trusty mathematical properties. I have hinted at these concepts in older posts but I have put off writing this one for a while. I'll try and make it quick.

Erlang says that quality is 1 when something does what it is supposed to do when it is expected to do it. Things that do almost what it should do, or for less than all the time when it is expected to do it has a quality which is somewhere between 0 and 1.

Metcalfe´s Law says that the number of links in a connected system increases exponentially with the number of connected nodes.

At this point I'll introduce my own definition of antiquality.

Antiquality is what you have left after you subtract quality from 1. Such as if you have a telephone line which has noisy crackles for 0.6 seconds every minute of a phone call your quality is 0.99 and antiquality is 0.01. At this level the amount of antiquality in a simple phone call is not a problem to the user. Its a minor annoyance at worst.

The interesting thing begins to happen when you connect a bunch of phone lines to each other. Imagine the phone call as a conference call with all phones connected to all other phones. If one line crackles the crackling is broadcast to all the other phones. You don't need a whole lot of phones in this system before the quality level needs to be a lot better than 0.99 to get any kind of useful communication going.

When we look at games and other experiential constructions such as a brand, we as humans have the tendency to connect every bit of the experience with every other bit. Our brains are like a super network which categorize every bit of antiquality with every other bit of antiquality presented beneath the same symbolic structure. For any product which is more complex than the most simple of things we will quickly label the whole experience as useless antiquality, unless the actual quality is a true 1.

So how can you use this understanding to build a product with true quality?

That is a different story. But it begins with understanding what the product is supposed to do and when it is supposed to do it. If need be you adjust these parameters and you make sure your user is well informed about this framing or you will quickly be labelled as junk.

Agile Failures

There has been a lot of almost mainstream media whining about how projects fail despite using an agile development methodology. Lots of blog posts about how agile cause trouble and how scrum fails in companies.

This post aims to start a journey which looks at my perspective of this trend. The journey begins with looking at the businesses which invest in projects and we’ll begin with separating these into two major factions.

Faction 1: Profitable business.

The profitable business has found a way to reproduce a profitable sale. Steve Blank uses the phrase “repeatable sales model”. My interpretation of this is that there is a potential market value which is reliably converted into money through the business activities. The repeatability causes a reliable equation to play out where you have a high chance of staying on top of positive revenue through conducting very low risk maneuvers until the equation changes when you have the option to adjust to maintain your profits.

Faction 2: Not yet profitable business

The not yet profitable business has bigger costs than earnings. This is quite simple and includes everything which is not yet profitable. In many cases you can see a profitable business include portions of this in the profitable equation, for example by making design improvements or product line extensions. The more common scenario is however attempts at creating a profitable business out of an idea.

Now that we have these two major factions we have a tool for understanding several ways to achieve failures which will make any methodology fail. Since everyone has learned that the typical waterfall project is going to fail by default it’s not that interesting to talk about, but we’ll try and stick to general failures which can be blamed on Agile.

To predict how you will fail you can start with asking yourself: where does the money that finances the project come from? If it is financed by an already profitable business you have a particular case. If it is financed by venture capital you have another and if it is financed by yourself, often as some type of hobby, you have a third. Among these three candidates you have one in particular which spells uncomfortable failure louder than the others. The least loud failure is when you are paying yourself. No one expects success from a hobby. If you are funded by venture capital you are expected to fail about 90% of the time. No one is surprised when investments fail to find a return. The loudest failure is when an already profitable business invests in unprofitable projects. These also seem to be the ones which plays the blame game and tries to blame agile methodologies for their failures.

If you look at an already profitable business from a capitalistic perspective you would think they should not invest in a new “not yet profitable business” and rather send that money to their investors. But for various reasons they generally don’t operate this way but attempts to reproduce profitability in new innovative manners. These become complicated matters.

A profitable business has generally spent a great lot of effort to achieve their profits. As a game designer knows you will be conditioned by expending effort at achieving a goal. So the profitable business has been conditioned by its own success. This conditioning is cultural within that company. This culture tends to have an agenda which prioritizes protecting the profitable business against risks. The practical implementation of this protection is commonly called bureaucracy.

Bureaucracy causes risky product experiments to have such a great cost that they have to be cancelled before they reach the market. It is better to send the investment immediately into the trash bin than to use it to cause a potential harm to an already profitable business. This also has the benefit of creating plenty of work for bureaucrats who thereby can be hired to handle the paperwork.

Eventually this causes polarization within the company where creative forces such as marketing eventually is urged to brute force the bureaucracy to revitalize a now aged brand. They can see their market share slowly being poached by competitors. At this point in time the culture has set really well. The creative forces rally enough of a budget to overcome the cost hurdle set by the bureaucrats and begin their project.

Since times change and you learn that using “traditional methodologies” will cause failure this project must begin to work with an Agile methodology, they usually try to work with scrum.

The root of the problem here is that scrum does not remove the cultural conditioning which practically has become embodied within the bureaucratic parts of the company. There will be plenty of reasons to interpret the new project as a risk to the profitable business and thereby justifying interference.

I don’t know if there is any particular solution to this problem but I do believe that a better understanding of this structure will reduce the costs of failure for any business which is investing in any type of projects. And this is just the beginning.

To propose a practical solution to this I will recommend making investments into new business areas at a healthy distance from currently profitable businesses. Mere proximity might increase the cost of failure.

From my experience with scrum I interpret some of the rules as engineered to refuse interference from bureaucracy. These rules cause a kind of cultural power struggle within an already profitable business when scrum is introduced. Power is usually owned by the bureaucrats and scrum becomes the loser and an embodied target for the blame game.

Time

Writing posts gets low priority when many things needs to be done.