You Don’t Know Jack! How Software Gets Developed Part II
Intro to the Software Development Life Cycle
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):
- Requirements gathering/analysis.
- 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!