Returning to the beginning …

I've had an interesting couple of days...  

I came across a book in my personal collection that's responsible for “starting it all” - my career in software engineering!

As I've been writing on this blog, I've found myself mentally referring to ideas I was sure originated from there.  And so I've decided it would be interesting 15 years on to return to the book, and compared “what I learned” from the book (ie pure theory) with “what I now know” (hard experience).

My education background is actually science/engineering/teaching – not “computers”, and it was during some PhD research I found myself more and more driven to use computers and write programs to analyse my data.

Originally I was using BASIC, but all the cool kids in the Department were using C++.  So I picked up a book by Michael J. Pont – Software Engineering with C++ and CASE Tools.  It's a mammoth book – 900 pages!

It's also kind of 3 books in one – it teaches you C++ language, it teaches you to use CASE Tools (not heard of them used since 2003) and then this thing called “software engineering”.  And it's the last area I've been revisiting.

For years this was the only book I'd read on testing, so opening it up, I was surprised to find no testing chapter.  In fact it covers testing in really only 4 pages.

That is – it only directly mentions testing in one spot – testing as a process.  However throughout as part of the discussion of software engineering there is a discussion about quality, about checking the quality of code at every level.  It's very similar to the Agile idea of “quality being baked in”, ie test early and ensure that any code meets at least basic functionality before passing it on.

I know as a developer I was very diligent about checking my code “worked” before passing it on.  I wouldn't do the obligatory developer “victory dance” until I was sure of this.

In recent years I'm somewhat alarmed on some projects how some development teams are in such a race to finish that this basic level of testing is just skipped.  It's almost going the way of “if it builds, it's good”.

Ironically in the “bad old days” test teams used to be made of developers with no coding to do.  Bad for testing, good for development.  As many developers would learn how their code would eventually be tested, and get their head around checks they needed to perform.

Maybe I need to start running a testing bootcamp with my developers.






[The book itself is probably a bit dated now - it's even got screenshots from Windows 3.1, C++ is now superceeded by C#, and CASE design tools replaced by Agile whiteboards.  It's still a very good book, Michael Pont having a superb writing style, and provides very detailed case studies to get your head around]