⋮    ⋮  

You Don’t Know Jack! How Software Gets Developed Part II

Oct 31, 2015
22Shares
Submit

Software Complexity

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…

Submit