You don’t know Jack! How software gets developed/translation to crowdfunding

AKA: Complexity and Software Development: A (mini!) Treatise

Part I

Background and Introduction

I’ve been following game development on and off for quite a while now. While doing this, I’ve noticed in a lot of places that comments and critique often display a lack of knowledge about the software development process in general. Since I’m now a semi-published journo of limited renown, I thought I’d tackle this subject in a way that may educate people who have an interest in the topic. Of course I know that the subject matter of this article is unlikely to set hearts pounding like the latest AAA title in the run up to the holiday season or a new graphics card rumour but I feel the subject is an important enough one that I should try to address it, if for no other reason than I can point people to this series of articles when I have online arguments XD

Throughout this article, I’ll make (hopefully!) relevant comparisons to crowdfunded development for your consideration, particularly Star Citizen.

This series of articles is (a bit!) long. I hope you’ll read them, but understand if you don’t. This first piece focuses less on software development and more on the general concept of complexity as it’s a very important factor in pretty much everything I’ll discuss across this series.

So that you have an idea of what to expect (and can skip any bits you’re not interested in!), I’ll list out the parts of the series due to be published below:

(This article!). General complexity introduction. Several topics including: General complexity and its relevance to crowdfunded game development. Complexity in software. Basic introduction to scope creep. Intro to the Software Development Life Cycle (SDLC). Couple of topics including: Software complexity and SDLC relevance to crowdfunded game development. Simple introduction to the concept of diminishing returns. Budgeting and its relevance to crowdfunded game development, CIG rumour debunking. Waterfall vs. Agile software development process.

Who the hell do you think you are?

Ok, so I don’t make videogames. I’ve never made a videogame in my life. I’ve never even attempted to make one and given up. I’ve not really even had the ambition to make a videogame. Would I like to try my hand at it? In all honesty, I’m not a creative in that manner so have a high level of confidence that I’d be terrible at it. I’d be happy to consult on a game that needed some element of my expertise for maybe a trading or economy simulator component, but make a game? Nope that’s not for me.

So why am I qualified to write an article like this? Well, for most of my professional career, I’ve worked in what is one of the biggest games in town. Namely financial markets software development. Several of the products I’ve worked on are pretty big, multi-year, hundreds of millions of dollars software development projects, primarily focussed around trading activity whether it’s stocks and shares, fixed income, foreign exchange or commodities systems that cover everything from you calling up your broker to buy a couple thousand pounds, dollars or euros worth of shares to high frequency derivatives algorithmic trading. It’s a complex area and can be a lot of fun.

I’ve actually worked with a few developers from the games industry over the years who have made the jump into finance and there’s some degree of similarity, although obviously a lot of differences too.

I don’t develop the software myself, but I’ve done everything from design the software for the developers to build, run agile software development project management for multiple globally distributed development teams, run implementation projects that span continents, networks and companies among other things. Is everything I say to be taken as gospel truth no matter the circumstance? Absolutely not! Is it worth a read if you want to learn a bit more about development as well as some theory-crafting as to how that translates into the crowd-funded game development model? I think so, you be the judge.