Recap

Last week, we took a slight off topic look at budgets and how money is used/projected to be used during the course of a software development project. Part IV can be found here.

Part III looked into software complexity and the SDLC in relation to crowdfunded software development along with a diversion to look at the concept of diminishing returns in software. Part III can be found here.

Part II looked at complexity in relation to crowdfunded software development as well as introduced the SDLC and can be found here.

Part I introduced the concept of complexity in general and can be found here.

The Finale!

This is the final part of this series of articles. I hope you've enjoyed them and perhaps learnt a little about the process of developing software. As ever, leave your thoughts in the comments below!

In part V, we’ll look at some of the basic methods in which software development projects are run. Pretty much everything here is relevant to crowdfunded software development so I’ll not draw out a specific section to point it out.

Waterfall vs. Agile

Waterfall and Agile are the two main methods of running projects in a software development environment. Waterfall was used for a long time and was a carryover from the manufacturing and construction industries simply because that was what everyone used. It’s a sequentially modelled process where you complete one step and then move onto the next step and is fairly synonymous with heavily upfront documented requirements.

The difficulty with this method is that if your requirements are incomplete, have an error in them etc, it’s very costly to go back and modify things. Imagine if you were making a new tower block building and you had documented all your requirements, designed the building and were in the process of building the tower block but then realised that the structural integrity calculations for the foundations of the building were incorrect and too weak. Fixing that problem is going to be costly and you may not even be able to do it without ripping the entire building down and starting again (who knows, I’m not in construction). Same, if you run a manufacturing plant. You order 5,000 machines to automate assembly, but when you designed the machines, you made an error in the size or shape of one of some aspect of the machine. It’s going to be costly to fix.

Agile is an attempt to get past the inefficiencies of the Waterfall process design for an environment that doesn’t rely on hardware and more frequently has changing requirements, as well as to allow for a more iterative production model which also gives more accurate forecasting capability than the traditional ask your head of development who sucks a finger, sticks it in the air and comes up with a man day/timeline estimate with no real basis in reality.

There is a huge amount of documentation on both of these topics online for free and I’m not going to go in depth into all aspects of them but will touch upon a few of the very important concepts of both agile and general development here.

Relative Estimation

One of the first things anyone with a stake in a software development project wants to know is “When will I get it?” The trouble is, people are pretty bad at estimating. The concept of relative estimation came about as a way to try to allow for a better estimation model, as well as to decouple the basic question of “When?” from the developers mind. Instead, the developers are asked to estimate sizing using something called “Planning Poker” and any one of a number of different “measures” of the complexity and difficulty of a given user story that they may be working on. I typically use Fibonacci numbers on my projects.

The point of estimation is that the number the team comes up with during the planning poker session (called “Story Points”) is purely thought of by them in terms of the complexity and ease/difficulty of developing what is being asked of them. NOT tying it to any false notion of how long it is expected to take by the client, stakeholder, management, whatever. If you can get your developers to do this and above all to be CONSISTENT in their application of their own definition of complexity, the rest falls into place. This is one of the key difficulties of agile, particularly when a new manager comes in and doesn’t understand the concept of relative estimation. Starts putting pressure onto developers to change their estimates of stories, trying to get them to commit to timelines for delivery etc. Of course this then breaks the entire process and you’ll very quickly find that you start delivering likely behind schedule again.

This is because one of the key aspects of Agile or Scrum based development is the concept of Velocity, which is a measure of how many story point a team works through in a given sprint (work period).

If your sprint length is 2 weeks and you can see that over a given period of time your development team typically burns through 20 story points per sprint and your backlog consists of user stories (requirements) which have been estimated at 300 story points, you can be pretty confident that it’s going to take about 15 sprints (or 30 weeks) for your team to work its way through the rest of the backlog.

The concept of relative estimation is so important because it’s one of the key things that takes away the human inability to calculate all tasks involved when working out a timeline.

It’s also very important in relation to our examination of Star Citizen. Certain people (whom shall remain nameless!) try to make a big song and dance about how:

“Star Citizen has been in development for 4 years because they said they started a year before the kickstarter!”

And even if this was the case, it’s pretty irrelevant, even if you estimate projects in terms of man days rather than story points. Why? Well quite simply, Story Points are a way of figuring out the man day run rate based on observable performance rather than less accurate forward projection trying to account for all variables. But either way, ultimately a project is still measured in terms of a currency unit cost and this is represented by man (or person) days. Why is this important? Well, it should be pretty obvious by now. But just in case a certain someone is reading this article, I’ll spell it out for them:

THE AMOUNT OF MAN DAYS OF DEVELOPMENT 8 PEOPLE CAN DO IN A YEAR IS (IF SCALED LINEARLY) 3.2% OF WHAT 250 PEOPLE CAN DO IN A YEAR!

What this means of course is that as CIG have grown, their development efforts have scaled up (although as we know from earlier, not in a 1:1 fashion as it does when going from zero to one developers). I don’t know how many people CIG have hired and in what capacity when, but it’s pretty likely that if you took the entire code base as it exists now, you may find that those original few people who were coding in the first year would have created a tiny portion of the overall code base as it exists now. Simple example:

Project “MakeGameXYZ”

Year 1: 1 developer. Work accomplished? 1 man year.

Year 2: 2 developers. Work accomplished? 2 man years (keeping the example simple, but remember in the real world, output is likely to be less than 200% of what 1 developer produced!).

Year 3: 5 developers. Work accomplished? 5 man years.

Year 4: 10 developers. Work accomplished? 10 man years.

How many man years of development have been accomplished in total? 1+2+5+10 gives 22 man years. Your first developer who started things managed to do a meagre 4.5% of the total group output in that first year.

So yes, of course CIG did some work before the Kickstarter started. How much of the overall project does that represent? In all likelihood, virtually nothing in code as it stands today. Arguing they should be done by now because they’ve worked on it for 4 years is just complete ridiculousness. What should be looked at is how much time in man years is taken to develop your average AAA online game, because that is what CIG are doing with Star Citizen.

Reprioritisation

One of the other key aspects of Agile based development is that aspects of the development can be reprioritised on the fly. The user stories taken into a sprint shouldn’t be changed, but given that sprint length is (usually) short, this means the team(s) can change direction as needed by the product owner within a short period of time, so whether a new contract comes in that we have to work on as soon as possible to get the deal, or whether a blocker has been discovered on a current user story that needs some other piece to be developed first, these can be reprioritised with relative ease.

Makes sense right? At the end of the day, it’s not like we can’t build the top floor until we’ve built all the ones underneath it. Software development has different needs, different requirements and a sequential model constrains where it doesn’t need to.

Prototyping

I touched briefly on prototypes in parts II and III, but it’s an important aspect of development whether it’s a physical thing you’re designing or a piece of software you’re building. The way some people have talked about Star Citizen (had to get the mention in somewhere!), it sounds like they think a lot of the development has been wasted and the money that was spent on that development was also wasted. I simply can’t stress enough how untrue this is!

Software Prototyping is an extremely important part of the development process and in particular with anything that is looking to break new ground! The other important thing to keep in mind is that for a visual piece of software like a videogame, the visual elements are just one aspect of what is being created in the prototype where many other aspects may end up being reused! So fine, maybe some of the initial hangar art is no longer used. Maybe the original damage modelling in arena commander has been advanced. What about the back end code to deliver you your hangar? Tell your client which ships are in it? Let you login and authenticate? Connect to their servers? This or some form of it is of course all still in place.

The other key thing prototyping does is gives you the ability to learn and evolve the software you are developing.

In many ways, stuff we see today is a prototype. As we all know when it comes to Star Citizen, everything is subject to change! Ship balancing, missiles, torpedoes, controller balance, netcode, login client/patcher, damage states. All of this can change, they’re developing it and most importantly, they’re learning from it. Not just from the code, but from us! The backers! Every time we post a thread in the forums giving them constructive feedback. Every time we vote on something in the issue council, every time we tell them that controller balance of mkbd vs. hotas sucks and why, this is all information for them to take onboard and use to potentially evolve the prototype.

Conclusion

This series of articles has been pretty long. I’d be pleasantly surprised if anyone read the whole thing. If you have, I hope you’ve been able to learn something and feel it was worth your time. Maybe it’s given you an insight into software development, maybe it has turned you off the whole subject completely. I just hope that you keep in mind a few key messages from this series:

Software development is hard. Some people reach for the stars and try to push the envelope. These are the people who progress us as a species, whether they succeed or not. I’m not just talking about Star Citizen, but whatever the chosen field of the dreamer is. Maybe it’s flying cars and hoverboards, particle accelerators and exploring the big bang. The invention of the wheel, the internal combustion engine, wind energy, splitting the atom, antibiotics. You name it, somewhere along the line there was someone who laughed in the face of someone who was trying to push the boundaries and telling them they couldn’t do it. Don’t be that person. Listen. Be respectful. Maybe you’ll learn something. But as always keep in mind: It’s easier to destroy than to create. Creativity is hard. In a discipline as complex as software development, even more so. If in reading this article, you appreciate that a bit more then I’ll be happy. Please let me know your thoughts in the comments!

Remember our mantra:

WITH ENOUGH TIME AND MONEY, ANYTHING IS POSSIBLE!

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