It's all about Energy.

Defining Success or Failure.

I've been a professional software developer since the mid 90's and I've seen my fair share of success and failure. Success is nice, it gives us a sense of accomplishment - of power - for a brief moment, we feel that we can do anything and emboldened we charge onwards to our next project.

We don't usually learn a great deal from the successes, but damn - failure hits home harder than baseball bat. Sure success teaches you some technical skills to add to your book of tricks, however it mostly just reinforces operational tactics used on the project. Good or bad tactics can look similar - glazing bad tactics with an artificial mask of success - which can be dangerous later on. But enough about that for now.

The thing is though, there really isn't much difference between a successful project and a failed project from the outset, otherwise we'd be able to spot them early on and either divert them onto the path to success or abandon them early on knowing that any further investment in the project would be a waste.

But we don't. The fact is, failure is not the state of a project, it's the state of those creating the project. The failure is often triggered by an external constraint kicking into effect but always failure is caused by a lack of energy. No enough energy to complete the project within the set constraints.

Creative Expression requires Energy

You can create anything your mind can conceive - Given enough energy.
The amount of energy available to an individual at a given moment is limited and while this vessel of energy can be increased through training, it is not infinite and will eventually deplete, requiring refilling.

Refilling the energy store takes time and while this process can be made more efficient for a time, it too has limits.

So an individual has a limited amount of energy resources which take time to replenish. So as we can create anything our minds conceive with enough energy, it also equates to time.

Understand what you're building

Failure on a project is often down to the estimate of how much energy is required to build the project when faced with a finite amount available. It may be in the form of an unexpected obstacle which takes more energy to overcome than was anticipated meaning that not enough energy reserves are available for the remainder of the project. It may be in the form of a complete failure to grasp the complexity of the project and how much energy it would need in the best case scenario.

So how do you avoid this? Is it simply a matter of throwing more bodies at the project to harness their energy levels? Often the temptation is to throw more people at a project to try to increase the pool however each person added to a project comes with a tax on the project's available energy. This tax is in the various inefficiencies which come from management and communication between team members as well as a gradually reducing "Getting up to speed" tax per new member which always takes it's toll on the project's available pool of energy.

For more information into this, you should look into a book called The Mythical Man Month.

A Reality Check.

What does this mean to the budding developers of this world?
Probably not much. Budding developers are typically young and have a seemingly infinite source of energy coupled with a drive to make something. Some of the best software is created this way. However it's also where the unexperienced developer can land themselves working on a project destined to fail when viewed by more experienced eyes. Harsh? Yes. Jaded? Possibly. True? Unfortunately.

An analogy

Think about running. Think about sprinting. If someone knows that they are able to sprint, it might be tempting to believe that a trip to the shops won't take much time; because they can sprint there and arrive in no time at all. This belief is quickly squashed after the first time they sprint to the shops and either arrive exhausted - or have to stop half way to catch their breath. Following that experiment the impatient shopper might try just running instead of sprinting and may find that they are less tired. However even if they ran to the shops, they spent a lot of energy where a simple walk was all that was required. The rest of their day will be altered by their decision to run instead of conserving their energy and walking. The trip to the shops was not an emergency and after walking the shopper can make an educated decision for the next time whether to quicken the pace or not.

This has strong parallels with development where the developer is managing a project themselves.
It is tempting to try to cram as much work in as quickly as possible to get results in a short amount of time. While this can work, the end result will almost always be a rush job unless the project was extremely simple and the vision was very clear.

There's a high chance that a design change mid way through can have disastrous consequences because not enough thought was put into the design at the start. Or even that the developer will achieve 80% completion and give up because they ran out of energy and need to catch their breath.
Where giving up is not an easy option - It may be that a long torturous slog is endured to finish the project - late and loveless.

Simple projects can be rescued fairly simply - a little rest followed by a concerted effort to complete it, the project can be finished to a satisfactory level. The more complex the project, the harder it is to endure.

It's all in the scope.

The problems come in with any changes to the Scope of the project. There are two things which happen with regards to scope.

Scope creep and Scope Shock. Often the two are related - but not exclusively.

Scope Creep is a well studied and documented phenomenon it is when changes to a project add to it's required energy levels over time. Small innocent looking changes or decisions add to the project. While this can be a creative force for good on a project, the cost in energy must not be underestimated and the knock on effects may not always be easy to identify until they arise naturally.

Scope Shock is a term I use to talk about the fear of the scope one you see it stretched out before you. It is the real killer. It's the headlights to the startled rabbit. It's the seeing the killer at the window. It's when you suddenly realize that you don't have enough energy available to complete the project for one reason or another. Perhaps the scale of the task was underestimated. Perhaps many simple items multiplied out took more energy than expected. Perhaps a team member leaves reducing the energy pool.

Scope Creep is usually the biggest cause of Scope Shock, but it's not the only cause. It's usually the point when the developer realizes they have bitten off more than they could chew. that they're undertaking a task they are ill equipped or simply inexperienced to handle.

I see this all the time with new game developers. The conversation normally goes like this:

Hey everyone, I am NewDev2013 and I'm going to write a game, I'm hoping to make lots of friends here and make something really cool.
Welcome to the forum NewDev2013, we're all friends here - what kind of game are you making?
Thanks, glad to hear it. I'm going to make a [Call of Duty][MMO Like World of Warcraft][JRPG like Final Fantasy] game has anyone got any advice?
... cricket sounds ...
Make something smaller like Pong, Tetris or Pacman first and see how you get on.

The new developer then either:

a) Heeds the advice and gives up their solo dream of making a game which took a team of hundreds three years to make and makes something simpler - and even then beyond them, but enough lessons get learned that they come back again and try something more to their solo skill-set.

b) They plough on regardless and depending on their actual level of skill and available energy their either:

• Fall at the first hurdle after spending all of their energy making soldier or monster models, 
• Make a working prototype but take it no further, 
• Make a working prototype and over time improve it or 
• finally make it to a completed project.

However in all of these cases, the first project a developer works on will be bad. Sorry, but it's true. It's the sprint to the shops. Yes, you can sprint to the shops to find out how tiring it will be, but you'll just arrive at the shops tired. So it's always better to walk first.

When I say it will be bad, I don't necessarily mean that it will look bad or play badly - but it won't be polished or well received. It may have some really good raw mechanics or a nice look and feel - but it should be used as a jumping off point. Practice if you will.

Prototyping is not wasted time.

It is always better to prototype small things as a part of a larger whole. Make small throwaway examples to try gameplay or ideas before putting them into the game if the immediate solution isn't obvious or has the potential to break something. The only way to know how long something will really take is by doing it and understanding the pitfalls. You can estimate based on small chunks of experience however putting a finger in the air over a large set of work never works unless that large set of work has been done over and over by the estimator. Games aren't like that though, they need to be broken down into chunks and estimated accordingly.

Without a good plan, you will always have scope creep - however the creep goes unchallenged because there's no formal design to speak of. Once you have a reasonably comprehensive plan, you can estimate based on the sub tasks.

Without a good estimate, you will always have Scope Shock. It is inevitable. Even without a deadline, your own personal energy levels will deplete and without constant tangible progress, the fear of the unending project will manifest and just like the rabbit in the headlights, you'll stop and that will be that.