Replies

Sounds like a good idea. I think many people are stuck between two worlds. It’s also a challenge for engineers since the process is partly experimental - to be realistic. I don’t know how many times I use the word “prototype” in the commentary I’ve written on HLL’s past so far ... and now it’s emerging as “real software.”

So, when software is written for reuse, it’s better to think of it going through stages. There is a prototyping - experimental - phase that often can’t be avoided. But at some point (easier for some things than others) it’s going to settle in to a component with a well-defined purpose, justifying investment in support of nice documentation and test procedures.

I’ve used the word “product” in the article w.r.t. components - intending to suggest a shift in what it takes to finish one; i.e. what it’s character is. Reuse justifies the effort.

FWIW I had an automated test suite that consisted of about 80,000 test cases. It was heavily dependent on reusable methods and small sections of specific code to tie it all together. Maintenance was a dream and it seldom took more than a couple of days to get the whole thing running again after major changes in the system. The company I worked for decided to throw the whole thing out so that they could move to a new tool without even doing an assessment.

The reason I think they did this was to reduce the amount of testing being done. We were over testing because no one wanted to throw out any tests once they were automated. As the automation manager, I would recommend that they prioritize the tests and we would run them by priority depending on the scope of the changes. None of the senior managers would agree to not running tests because they feared being blamed for any leakage. I could go on but I am sure you get the picture.