|
Wow! How things have changed!
I am very 'Old School' when it comes to coding and intergration. I always used a 'top-down structured' approch, but then again, I always used procedural languages, rather than OOLs. Top-down meant, you wrote the top level procedures first, and any lower level procedures were 'stubs' either returning a dummy value, or would print something like "Module X called". When the top level was done, I would work on the next level, using the same stub techinque until, eventually, the entire program was done. Unit testing was done with a 'best guess' approch to creating data sets, or, when things got more sophisticated, automated testing programs (I designed and wrote a kewl language back in 1988 called "Jaberwocky" that produced test data sets based on the DDL for all input data structures. I modified it about 1992 to test both client and server code. It was able to generate incorrect data on occasion, to test error handling, and could actually be used for stress testing creating a mix of server requests, based on estimated proportion of each type of request that would actually be processed. My proof of concept was designing a major financial system from the ground up - including hardware. My little 'science project' was able to project required hardware, comm lines, etc. for full roll out from a very miniscule pilot system. I was able to predict almost exactly (I was 5% high) worst-case scenarios (about 100,000 TPS) and saved my client some mega-bucks by keeping them from buying unnecessary hardware - this was in the time of "Big Iron" and we were talking $1.5 - $2 million per unit. My management actually had to cancel the order for this stuff because they didn't believe my numbers. As you can suppose, I'm big into statistics. )
A good design, with good specs, saves a lot of $$$$ - I've seen some projects be delayed for weeks because the specs were ambiguous - a module was to return an integer value, and was coded to return a string value. The specs said "Module Y will return the value of .....". The caller thought 'integer' and the sender thought 'string' (it should have been a string, BTW). To digress, Fred Brooks, in "The Mythical Man-Month", talks about a programmer that got called because a system failed on the first night of production. He looks at the data, and saw an "&" in a field that was being tested - no 'special characters' allowed. He eliminated that record from the input stream and reran the program - which failed again with the same error - another "&". He looked at the input queue, and found that almost all input records had an "&" in them. He called the system designer (this was 3am) and asked about this - "You told me that there are no special characters in this field in your input - what's going on?" The designer said "There's nothing special about ampersands - we use them all the time!"
Unit testing is the biggest hurdle to make a project work. Most programmers will only test 'good' cases - the errors will fall out by themselves. I have seen several projects that looked good until it went into production, and then found major errors in code because exceptions were not thoroughly tested. One of the techniques we used to use (and I think is part of the Use-Case methodology) is to never test your own code - work with a 'code buddy' - you test his/her code and they test yours.
In my experience, probably about 95% of project delays would have been eliminated by good structured coding and unit testing. In general, 1 hr of unit testing, saves 10 hrs of delay. Of course, I'm looking at things in retrospect on several levels: coder, system archetect, programming manager and project manager.
The BIGGEST problem I've encountered have been MY managers who equated testing time with wasted money - the 'it compiled - it works' syndrome. Long term, my strategies worked and ended up being more cost-effective - which is why I'm retired already, and my managers are still working.
Wanna talk about testing stragegies? Drop me a line.
Frank
|