You Don’t Know Jack! How Software Gets Developed Part V
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.
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.