Time and again lately I’ve been hammered at work regarding software schedules. Whilst it’s difficult enough to explain this to management that don’t understand software, maybe it would be possible to explain it to anyone else. I thought it would be interesting to put down my thoughts on how it is possible to generate a software schedule that is realistic and achievable.

Civil engineering is a great analogy to draw on, so let’s start by setting the scene with a project where they’re building a road. The designers start by doing investigation and determining the requirements for the road (testing soil, how many cars per day does it need to carry, how heavy are those cars etc). Once this is done and agreed the design work begins - detailed drawings, specifications and reports that are handed over to a constructor. The constructor takes these drawings, orders the bits they need and they start building. Unfortunately it rained on and off for weeks and they were unable to lay any pavement so there was a big delay. Once the road is built and the finishing touches are put on (lines, barriers etc) it needs to be tested to ensure it’s the right thickness and consistency and complies with the design. Once that’s done the road is finished and everyone is (hopefully) happy.

Still with me? I hope so because now it’s time for software development.

First the programmer defines the scope by investigating the requirements for the software: this includes the interfaces to people, other software/hardware systems, databases etc. Once these basic requirements are agreed the basic framework design begins: how they will break the code down into objects (blocks) as well as specifications describing how the code will be finally assembled and then tested. Once this is done the programmers then begin the task of programming the objects. When the objects are done they are tested and then the objects are all assembled together into larger, functional pieces of code. These pieces of code are then tested and once the finishing touches are done the final system is acceptance tested and then hopefully everyone is happy and we are done.

The similarities are clear enough, so why is scheduling software so difficult? I think there are two drivers behind the problem: 1) Because software can be easily changed, it often is - even though the change can have massive implications; and 2) Time for “inclement weather” is rarely allowed for in software schedules. In software it doesn’t rain but bugs are found that need to be fixed. Think of it like someone raining on your otherwise perfect piece of code. This time needs to be allowed for. In Civil projects weather delays are often included in the schedule from the very beginning, but time for code rework in software projects isn’t.

If one was building a road and it was discovered they forgot to cover a big hole in the ground and put the pavement over the top of it, they would have little choice but to rip it up and start again on that bit of road. So it is also for software. If we find a bug it needs to be fixed. Let’s say the road constructor was doing their final testing of the road when they discovered the hole - they would have to fix it before they could finish the road. The same is true of software. Allowances must always be made for rework - no matter how good the programmer is or claims to be, they will always make mistakes and there will always be some rework. Like the weather, the size of the delay is hard to quantify, but some delay is a guarantee.

In the land of Civil Engineering there is a well understood concept that late changes to the design like, “oh we wanted the road to a bit to the left around this forest” at the 11th hour are just impossible. The roadbase is likely done, some pavement is laid, and you well, just can’t change it right? Even if there is scope change earlier in the design once the road clearing has begun, there is usually a big cost involved in making a change. The problem with software is that there is belief that “it’s not a physical thing I can touch so I can change it.” Perhaps the problem is similar to typing a document on a typewriter and typing a document in a word processor. We have become so used to fixing typographical errors in a Word document with a simple keystroke or two and a fresh print-out, we think that changing software is just as easy.

Wrong.

There may well be some changes to software design that are minimal in impact, but every change should be assessed for its time and cost implications. If objects are already written and tested and are ready for final integration, if a change is then made all of that code needs to be regression tested again and this must be costed. Schedules should be adjusted and extended in time in that instance as well with every change to the scope of the design - no differently to a Civil schedule.

The other problem comes back to design vs implementation. Some people say that the code is the design, but in that sense it is also its own implementation. The problem is how does one separate design, implementation and testing in software? In the Civil world it’s clear: the hole you just dug is your implementation and you only dig holes when your design is done and you only test the hole is correct when the hole is finished.

The problem with software is that in this day where multiple programmers are usually needed to complete a project and programs are quite large - there is no choice but to break it down into objects and smaller pieces. This means that not only do the objects have design, implementation and test stages for each object, but so does the overall final product delivery. Add to that the fact that good programmers test continuously as they program and it gets difficult to track time.

How does one track hours? Tracking software as one blob of time (like most projects do) will artificially blow out the time taken to develop the software. If it is broken down into costs for object development and overall development and those are broken down into design, implementation and testing, the hours spent can be correctly tracked. Certainly piecemeal testing of sub-functions within an object are not always formally, rigorously tested and this testing may well be counted as code development - no system will be perfect.

There are also common things to all kinds of scheduling such as accounting for staff turn-over and retraining of new staff, illness, loss of data etc. That said, if one accounted for all of the real-world issues in a schedule and used that schedule as the basis for final project costing in a tender response, there is a good chance the company would not win the job based on their price alone. This doesn’t mean people shouldn’t try and cost things accurately. If the project is won for a cheaper price and the allowances have been removed to win the job, in the end the managers need to understand that costs were cut and they should not take it out on the programmers who are just trying to finish the job.

Thoughts; advice; venting; now over. I hope this helps someone in the future…