Reply to post: I was old school and most of the bugs came out during the flowchart breakdown..

Everyone cites that 'bugs are 100x more expensive to fix in production' research, but the study might not even exist

Steve B

I was old school and most of the bugs came out during the flowchart breakdown..

On my important projects, I used to flowchart them, then break the flowchart down and down.

I once ended up with a complete 12 ft by 6ft wall covered in a flow chart linked by ribbons.

It highlighted enough issues and so I knew which questions to ask to finish it off.

It caused a panic at the Home Office when I asked the questions as apparently I was months away from finishing the product.

They arranged an emergency meeting with the managers to discuss a new implementation timetable, meanwhile I had finalised the flow chart and typed in the code required all in less than a day.

My boss was well aware of how I worked and took great pleasure, after hearing their put downs about not hiring professional companies and needing months extra etc, when he looked across to me and asked when I would be ready for testing and I stated the booked session in the morning!

Cue lots of red faces when they admitted they had cancelled the sessions thinking we were months away.

It sailed through the testing as well!

Developing in C was the closest thing to that method as one could just create a stub routine and then expand on that later, breaking the code down to cover all possibilities.

The biggest issue with testing is that if an input has to be between 0 and 5, for example, the programmer will work in the presumption that the input is a single digit with largest value 5 and smallest 0, this can cause issues when the input is empty or a non numeric string.

Is this what most of the current windows problems are? buffer overruns.

The fact that data is being allowed to overwrite code is both a hardware and software design flaw that we actually overcame back in the 70s.

When I got to Visual Basic, I found that to be awful as there was very little comprehensive timeline linking.

It was there but hidden in the presentation which meant most new developers didn't have a clue how things actually worked underneath.

This means that most of the bugs found after the product has been released require a redesign, which doesn't happen. So welcome to the US patch city.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon