Recap

Last week, we started looking at what complexity means. If you missed Part I, I encourage you to read it to understand the context of what follows. You can find it here.

This week, I’ll delve a little into what complexity means in relation to crowdfunded development, as well as with regards to software itself.

General Complexity Relevance to Crowdfunded Development

It’s no secret that I’m a big fan of Star Citizen. CIG have upscaled from a few people working on a dream project in their spare time to a several hundred employee/contractor, globally distributed software development studio in less than 3 years. What kind of complexity do you think comes with that? Forget about the coding of the game itself for now, but just the complexity of running the business. Some considerations:

1. Different legal and tax jurisdictions for offices (California, Texas, UK, Germany, just for the in house studios) which have to be dealt with for:
   1. HR (employee contracts).
   2. HR employment law.
   3. Corporation tax/any associated tax breaks.
   4. Company filings.
   5. Foreign exchange risk/hedging/fees.
   6. Finance and budgeting.
2. Different legal and tax jurisdictions for raised funds in countries where CIG doesn’t have a legal entity etc.
3. Infrastructure to allow for collaborative development between locations:
   1. Leased lines/internet circuits.
   2. Routers, switches, firewalls, VPN’s.
   3. Code repositories.
   4. Access permissions.
   5. Servers
4. Procurement of hardware.

So, there’s a lot of complexity already in just the day to day running of the business. These things need staff that are specialists in their given areas. Lots of people had to be hired and trained in the given areas above and likely in others that I’ve forgotten. Offices and hosting need to be leased, accountants/lawyers need to be hired as well as sysadmins, network admins, support people, accounts need to be filed, exemptions need to be completed, circuits need to be installed etc.

All these new people that are getting hired need to be trained in their chosen area of employment by the original few employees who likely bodged their way through whatever they could to just get the basics up and running. This is the initial growth phase of the company and likely when the company went from 8 employees to 20-30. Chances are that the future department heads were hired in this phase and entrusted with the future of their specific areas as the company and funding drive progressed.

As these people get hired and start laying the foundations for how the company can scale up further, this is likely a 3-6 month period as people get hired (interviewing and contract offers take time!), they come in and learn how things are currently structured and start to map out their vision for how stuff will be structured once they’ve put their “more professional” mark on the area they work in. Budgeting (more on this in Part IV!) plays an important part here and given the (at this stage) relative unpredictability of the company income, plans will need to be made for everything from a base minimum to a fancy setup as well as how and under what conditions stepping up from the initial minimum to the more expensive setups will be judged.

Complexity of Software

Now we come to the really important bit. Complexity of software (both code and design) is something which is difficult to keep in check, particularly when the vision for what you want to do is big, grand and complicated to begin with. What I will do though is let you in on a little known industry secret.

WITH ENOUGH TIME AND MONEY, ANYTHING IS POSSIBLE!

The thing is, as most people who have spent any time in the software development industry know. Project management is an important function. Why? Let me give you an intro to project management 101. PM seeks to control the four key aspects of any large undertaking which of course are:

1. How long will it take you to do the project?
2. What is the project going to achieve?
3. How much will the project cost?
4. How good will the end product be?

Project management is itself a somewhat complicated discipline and there are people who dedicate their entire careers to project management of one sort or another, but ultimately it is recognised that in many areas, the above 4 constraints are intricately linked. There are also variations on the above, some don’t include quality, some include quality and customer expectations etc. However, we’ll stick to a simple model for now.

If the scope (the “what” of the project) is huge, does that mean it’s impossible? Generally not, what it does mean however is that the amount of time and money it will take to make the end product will be MOAR! Most software projects in a business environment have significant constraints around time to deliver and cost (budget), so it is the project manager’s job to make sure that none of the other factors adversely affect the time and money factors. Here, we come across our first “There be BEASTIES here!” sign.

Oh no it’s Scope Creep! RUN FOR YOUR LIVES!

Scope creep to a project is like kryptonite to Superman. Why? Well, change of scope (in particular once the project has already started) is one of the big things that can blow a budget and timeline right out of the water. Additionally, it’s one of the major things that can add complexity to the software. Some people will go on about differentiating between scope creep, feature creep, descoping etc. The bottom line is that most commercial projects have very strict controls around change management for an agreed project which usually include:

1. Formal written notice of intention to change scope.
2. Detailed written description of what the change is and expected behaviour of overall system in light of new scope.
3. Assessment of change from a technical perspective.
4. Estimate of change to initial timeline and cost.
5. Agreement/abandonment of change and addendum(s) to contract created/signed off.

As scope creep is such an important factor, it’s so important to make sure that you get as much of your scope locked down as possible in advance in projects. This doesn’t just affect commercial projects, but also crowdfunded ones since it has the potential to significantly impact the fundamental design of thing you’re building.

Take Volkswagen as an example. Now, putting aside the potential fines they face for the emissions cheating scandal which is currently ongoing, they now face having to do a worldwide recall of ~11 million cars. The costs of that recall alone will be staggering. They have to pay people to find out all the cars which are affected. Then they have to contact all the owners of those cars, probably by letter so need to pay postage. Then they have to pay the dealerships to bring the cars back in and make the change to the cars. Even if the total cost is just €200 per car, that’s still €2.2 billion. Imagine how much it would have cost them to have figured out during the production of those cars that there was a problem? Still a lot, but a lot less than having to send all those letters and pay all those dealers to bring the cars back in and do the work. Imagine if they’d figured out there was a problem and they shouldn’t try to cheat emission tests during the design of the engines? Well, all it would have cost them is the time and money they’d spent designing the engines and to make a change in the design. Of course, the best practice here would have been to not try to pull the wool over the eyes of government regulators and customers around the world. I’m sure their costs will run much higher than any numbers I’ve put here taking into account fines, lawsuits etc. But the point remains, the earlier in the life cycle you make a change, the cheaper it is to do so.

There’s a lot more than that involved but those are the basics. Simply put, change of scope is a biggie, not just for software, but for most projects. Why is this? Well, you need to understand the lifecycle first…

Software Development Life Cycle (SDLC)

There are a few basic stages that most software projects go through. At a high level they are (in chronological order):

1. Requirements gathering/analysis.
2. Design.
3. Implementation.
4. Testing.
5. Deployment.
6. BAU (Business As Usual or maintenance).

The above can be an iterative process of course with the first project being a phase 1 and subsequent functionalities being developed in future as a version 2, version 3 etc. Further, this iteration to a certain extent can be productionised within a smaller timeframe called Agile or Scrum (coming in part V!). Additionally it’s also important to keep in mind that if future phases are known and planned for, they can be catered to during the design phase, even if the actual development of those functionalities is not included in the initial project scope.

The basic premise is that the later in the lifecycle you decide to change the scope, the more expensive it will be to implement (in terms of both time and money). This is because as each stage progresses, more of the original scope becomes “set in stone” so to speak, because you’ve already figured out what it’s going to do, how it’s going to do it and maybe you’re already working on creating it (implementation). Software projects usually have some kind of milestones associated with them which are used to gauge progress as well as demonstrate to the client/stakeholder/(or crowdfunding backer!) how the development is going. As development progresses, more of what you’re doing relies on the basis of what you’ve done in the past. These are known as dependencies. You can’t develop an online game without having some network connectivity code in it. If you implement the network code, start working on the game and then all of a sudden realise that you need to change network protocols, that’s a pretty fundamental change and the chances are you’re going to have to unpick a lot of existing code to implement that change. This isn’t just a software thing, same applies in lots of industries.

I’m using network protocols as an obvious example, however network protocols are pretty constant and the benefits/disadvantages of the common ones are widely known, but the impact remains. This argument takes place to varying degrees depending on whatever aspect you look at in your design. Maybe you designed your framework to use a certain type of back end. Ok so you build your back end, but then you realise you forgot to include a reasonably easy way to expand that framework so to add it you have to go through vast swathes of (hopefully appropriately commented!) code by hand looking for pieces that call the part you’re looking for. If your initial designers were smart, there is an appropriate document sitting around somewhere on the company intranet which explains how to go about adding new component ABC into the existing framework and it’s a snap job. One of the comments on Part I was particularly good and we featured that comment in the article. I encourage you to go read it but the number one rule that "Patrick Proctor" put in the top 10 ruled of programming?

Design for easy expansion both in modularity and functionality. If your framework is poorly designed, your programming experience inside it will be even worse.

In short. Design is important. Extremely so. Pay attention to your design, lest it come back and bite you somewhere inappropriate!

Some people will include other things I’ve missed out, some of which may be relevant to game development (namely prototyping) but these are the main areas of SDLC and we’ll look at prototyping in Part V.

In part III next week, we’ll look at how software complexity and the SDLC impacts crowdfunded software development!

Follow Wccftech on Google to get more of our news coverage in your feeds.