Why crunch will break the best and brightest in the industry.

I’d have you consider that we can’t just keep developing software in the same way as we move into the future. The burnout and destructive way crunch gets a project to its end is just not sustainable.

In this article, I’ve listed some of the content from my book “Zero Crunch – The Best Way to Ethical, Cost Effective Software Development. It explains how and why we can find ourselves in a position of damaging crunch. Many possible factors include poor efficiency and effectiveness concerning project management, maintaining quality, and managing change.

We find ourselves compelled to say yes to most opportunities and to develop ‘at any cost,’ this is neither ethical nor sustainable for studios, teams, and developers irrespective of the financial gains. There are some learning takeaways in this article that will help you to explore better, more ethical, and cost-effective development.

The reason I developed a “3-Stage System” is that there is a different and better way. I can live with the fact that traditionalists will develop software their way, I used to be one, so I understand.

There will be industry and development veterans out there that have a different viewpoint regarding crunch and delivery, we all need to take a view.

My view? I can live with the fact that I can help studios and developers finish projects on time and budget while traditionalists still crunch. I can live with showing studios a more efficient and effective way to move through projects, while traditionalists scrabble continuously to finish.  I can live with the idea that the whole team can have fun delivering projects, while traditionalists apply pressure, fear, and blame to meet deadlines.

I can live with the fact that with this system, a studio and its team can say no to a project because it can’t be done or isn’t right for the studio. While traditionalists, search and take as much business development work as they can and then try to work out how to deliver it.

Most of all I can live with the fact and feel proud that any studio and team that utilizes the 3-Stage System in their particular way are making their journey in software development a fun, comfortable and successful one.

There are several significant side effects of teamwork and development in this way, that only add strength and fortitude, giving us that bravery to take risks and not be reckless or driven by fear. To push the boundaries of what we know and develop, to continuously improve.

In my experience it is. I have no doubt that it reduces creativity, drives burn out, it affects everyone, and it destroys teams. The worst part? For many studios and corporates, it’s the only way they want or know how to build software.

It’s time for you to take back control, develop software ethically and sustainably for you, the teams you work within and to safeguard the industry that we are part of, for generations to come.

Making software is complex, understand that, and we are already winning.

Let's just get through today …

Acceptance of the role you play and the development challenge.

As an engineer in my previous working life I understood the difficulty regarding physically tiring work, and in harsh conditions; when it's so cold outside, and you can't even feel your hands but have to put a spanner to good use.

Sitting in a warm office (well, unless you are under the air conditioning blower, we all know how that feels) seems more comfortable. It is, but development isn't about physicality, it's about keeping your brain engaged.

It is being able to think logically, creatively, consistently. To be able to understand what all the others around you are doing, how that affects your work, and how you change theirs. It's about focus.

Feeling like you are achieving for the project, the team, not being a burden, being recognized for a task well done.

All that is just challenging! 

I'm not going to list the “White Papers” out there that prove diminishing productivity with additional hours worked. Adding creativity into the mix, logic, and problem solving, it's worse.

As a leader, you need to give space to those that are being creative, thinking, exploring, building. Those that fix, do tasks, they need time to grasp logic, to see the loops of development in the game. Build those core loops that mean the code is robust and lasts the test of time.

As a developer, if you have the time to be the best you can be, to defeat the biggest challenge for the studio, which is creativity hitting immovable deadlines, you need to be as accurate as you can with forecasting.

Be clear about where your knowledge is most reliable and the weakest. Be open about learning or where expertise is required so that it can be provided.

Team, team, team.

You're all trying to build something new, something unique, add that “secret sauce” that could make us all successful.

Be clear though; I’m not talking about the randomness of games like “Flappy Birds,” you can't plan for that!

Two types of “unknown activity” to plan for, within the development process.

When we are trying to be creative, I think there’s a desire to come up with something so different, so radical that creating that original element becomes a mountain to climb.

More often than not, and in an age of disruption (loosely, doing an acknowledged thing in a new way) the most successful software is based on something that has been incrementally improved. Windows, Apple iOS, are great examples.

The easier projects are those where a more significant amount of the code base, assets, design, have been created for previous versions. The choice for the next version is then generally about adding convenience, additional features for competitive advantage (to make people buy it) and a new look.

This way means that development is generally a balance of the “known unknown” (we’ll use what we have but in a slightly different way) and “unknown unknown” (all the new functionality we will have to build from scratch).

I can’t take credit for those descriptions, I’ve heard them a few times in the industry, but I believe they are good to use.

In video game terms we are talking about titles like Fifa, same fundamental game code base, new features, improved gameplay, new players and teams. A proven formula that means consistent release dates with better-understood development cycles.

You’d think they wouldn’t have to crunch, well ….

The point is the more significant the “unknown unknown” component of your project, the more creation and change will occur as you are developing it.

Additional unknown elements need lots of planning up front! Let’s accept that it’s going to be challenging, that it’s going to be time-consuming, that you will need to learn as you go.

The fact is, if you want to make something wholly new and innovative from a standing start, ground-breaking and genre-defining, it will take longer than you initially think to plan and execute.

A great example of what I think of as “late but amazing,” is the original Max Payne. Arguably two years later than it should have been, groundbreaking in its realism and game mechanics.

Forty-two playthroughs completed on Max Payne, working on the title directly, I still loved the “Bullet Time.”

You’d think I’d be sick of it! Well … no chance, I loved it!

Reducing the amount of “unknown unknown” will mean you have more chance of hitting deadlines and avoiding crunch.

So why do we make it hard for ourselves?

Later on, when we discuss managing change because when done poorly, is a significant driver of crunch, it will become clear how important understanding the volume of all unknown work is.

The critical mistake, leaders can make when saying yes.

Generally, when a studio is looking for work or has a great concept they want a publisher to pick up or an investor to finance, there is a tendency to go into high powered meetings with a tremendous amount of fear.

A bit like crunch, it becomes an “at any cost” scenario.

The promises flow! Saying yes to all the requests from around the table, “how about this?” and “it needs to be as successful as that.”

Your whole focus is to put some cash in the bank so you can pay the team, keep the lights on and heat in the studio.

The trouble is, during that conversation, that you went in well prepared for (or so you thought) you hit a point where what you are nodding and agreeing to, is now outside the scope of your teams’ knowledge and capability.

However, it’s okay! We can recruit, we can move office, John (your industry mate) will help out.

None of which is true at that point, but how do you say no?

Well the problem is, and this is the mistake leaders make, you are now talking about planning, time, resource, cash, not just for creating the game but for all the additional setup items you’ve just made very simple - in your head.

Nine times out of ten you will:

As you put your perspiring hand out to shake the cold, calm flesh of the most important person in the room, in effect giving a resounding yes, you feel like you've had a win!

Why then, as you walk back to the car, aren’t you as happy as you should be?

In reality, you have signed up to their deadline for your delivery method, their milestones for their assumed development cycle and their release date based on other agendas and spending in which you have no say or part.

 You did secure the money, right? All of the above is part of your “unknown unknown” project management process. Managing the lack of knowledge is the hardest part of the planning. If you have milestones to meet to get payments, did you actually secure that cash? Can you really deliver?

If you have experienced this situation, or if you fear this happening then read on, because the 3-Stage System will mean you can remove or reduce this effect.

If you manage to smash those meetings, in your favour every time, great! Still, read on because there is always useful incremental improvement.

Does all this sound familiar? If not, be warned.

The one thing I have learned after 20 years in software development, is that most development studios are built to be temporary.

Why? Because the real value is in the Intellectual Property that's created and the team that does the creating.

The rest? Rented office space with purchased technology: desks, chairs, and a fridge.

Inanimate objects have no value alone. Together they have the capability, but just like a car with the engine as its beating heart, development needs people at its centre.

So why, in an industry where the beating heart is its creative people, its creative capability, do we insist on smashing them on the rocks of crunch like a ship in a storm?

For those lucky ones reading this that haven’t experienced crunch, but work in the software industry, take this as a warning that it has very little value in its most destructive form.

We are encouraged to grab any opportunity, but this can lead to overpromising and being woefully unable to deliver.

No good for reputation, repeat Work for Hire, or the team itself.

You'll read in many places in this book, that doing some overtime to get a project finished is pretty reasonable. 

Creativity needs flexibility, and it is why Agile project management works; tasks, sprints to catch up, managing the “unknown unknown” aspects, giving creativity the space it needs to be amazing.

Later I’ll tell you a story of the tipping point I know we reached as a team working on GTA San Andreas. A personal tipping point that every developer, whole team, and leader has.

The story example at the very beginning of this chapter applies to any position in a studio, and whether you’re managing or making assets for a project, emails become not only a distraction but a fear point.

For a coder, it could be an email from the Team Lead, for a Studio Head it could be an email from the Publisher.

During crunch, the fear is tenfold, because you are already working at your limit …

Learning Takeaway 1;

When developing software, we need to accept that there are many moving parts and change is inevitable. The most important thread running through this first chapter is people. It’s people, including you, that choose the project, fund the project and build it.

If any of these people are without the correct knowledge, operating with fear, or believe it will be easy, then you are already starting from a negative position.

Learning Takeaway 2;

A real team has the training, knows what it’s capable of and why it’s doing it. Every team member understands the particular part they play within the whole. Team members cannot be coerced. They need to want to be part of the team.

Learning Takeaway 3;

If a team needs to work harder and do more than usual to achieve a goal, it needs to have a collective, agreed and communicated purpose — one that is both motivational, and intrinsically or extrinsically rewarding. 

Learning Takeaway 4;

When the team rallies to overcome adversity, it galvanizes them in a way that regular work doesn’t. Individual and team capability is enhanced; the learning is locked in from the situation. Be warned; constant adversity is not sustainable for most individuals and teams.

These excerpts are taken from my new book - "Zero Crunch - The best way to ethical, cost effective software development"

If you want many more great ways to avoid crunch, better planning, quality and teams, get a copy, I have no doubt it will start you on a journey of improvement. Learn from my journey, without all the pain.

Available on Amazon.com and Amazon.co.uk (the reviews are on Amazon.co.uk)

https://www.amazon.co.uk/Zero-Crunch-Effective-Software-Development/dp/1091752516/ref=sr_1_1?keywords=zero+crunch&qid=1558015477&s=gateway&sr=8-1