High Level Logic: Rethinking Software Reuse in the 21st Century

I could not agree with you more! There is a place for business experts and engineers to perform unit testing of components, but that should not be the extent of testing. A well-trained, knowledgeable software testing staff is absolutely critical.

When I manage a development project, I establish an initial team consisting of members from management, development, QA, Support, Documentation, Training, and Production Operations (Data Center) who see the project through from beginning to end. They attend all development meetings, discussions, code reviews, etc. Likewise they attend meetings specific to the other areas of the development lifecycle such as all phases of testing and documentation.

It is imperative, IMHO, that people outside the development team understand the process that takes place to develop a particular software project. They are therefore able to explain to others in their respective departments why we made one decision over another, which business requirements were included or dropped and why, which features are critical or optional. It provides the documentaton staff with key insight into the project, which I find allows them to document particular components or aspects of the project as we are in development to prevent a mad rush at the end of the cycle. And to your point of not compressing the software testing phases, having QA involved in the project meetings allows us to begin testing earlier in the lifecycle and often times to test some components while others are still being developed, which is beneficial because defects found early in development can be prevented in other components still being developed.

As a side note on software testing, I require systems-level testers (e.g. white-box testing) on my teams in addition to application-level testers (e.g. black-box testers.) And like you, I think automated tools have a specific purpose, but they are not the only solution and are not a good fit in some areas of testing. That’s not to say I’m not a proponent of automation because I absolutely am.

Including a representative from key areas of the development lifecycle is critical to meeting hard timelines and provides a better informed team all the way around. Sometimes the discussion is over a few of their heads or seemingly irrelevant to their job function, but I have never encountered a team, once the software is released and in production, who did not think being included from beginning to end was beneficial. I’ve had data center operators come back months later to tell me that the knowledge they gained in the project meetings helped them understand and meet customer requirements more effectively.

Yes, and as I thought about my next response, I wanted to say what I've neglected to say so far. I recognize that the airline industry has an excellent record and there are fantastic processes in place to correct problems that are discovered. IN a robot ethics interview I even suggested that one day there should be such processes for robots. One of the easiest scenarios to imagine (well - given the movie I, Robot and others - lots of robot scenarios are easy to imagine - but pin to the real world of today) - there is already pressure to allow autonomous vehicles loose on the roads - with some models already capable of some autonomous functions (like parking) right off the lot. What if one goes astray and runs through a crowd? You'd want a rapid response team collecting the pieces and asap determining the risk that it could happen again - certainly learn what went wrong and fix it.

We all learn from hindsight (it's the fool who doesn't). On the meta-level, we can look at the wind shear example and think what might be done in the future - not to wag a finger at the excellent job that's been done in that industry - but in the spirit of it's never unfashionable to improve.

Learning software at the R&D end could today, write improved algorithms that would deal with wind shear problems. And while we're at it - it's still quite dangerous to land in some circumstances, with rules for such things as max. safe shear (and that only covers when you know it's there). So, it's just no so that there's no more room for improvement, just on that one factor.

If I could add to what BuckeyeTexan said: that sets up the possibility of much more effective and efficient processes. I used to feel sorry for Q&A people sometimes - when they’d get thrown a large complex system all and once and were told to start testing. HEY! You’re holding up delivery! It was the same attitude that the engineers had faced, but much later in the process when managers had already spent a lot of money and were already under pressure from customers to deliver.

Like BuckeyeTexan said, the agile approach gets everyone involved from the start, in their respective roles and allows taking it a bit at a time. While doing that, you don’t need to rely entirely on generalists who feel uncomfortable about taking on certain tasks - especially under pressure to complete them. You can have various specialists forming a nice balanced production line of sorts. And the best thing about it - it goes on and on. I don’t mean that it delays project indefinitely. I mean that people can get expert in their specialty work, get in tune to working with everyone else in their group - and even continue the same way on more than one project - acting more as a continuous production entity than an ad hoc group with too few resources and time.

Agile is a great idea, but is very difficult to adapt strong QA processes to. I don't think the methodology is flawed, but in my experience too many paces use agile as an excuse to release anything on time. Often the stories change at the lat minute, scope can be way off for the time-frames due to the change, and testing strategies need to change on the fly.

The other issues I have with Agile is that I do work mostly on large complex system, other groups may be running waterfall, and others XP, they all change delivery schedules on the fly and it is very difficult to pull it all together for a clean delivery. That's why I often have to be the project manager as well as the QA manager, most teams do not like to watch the other’s ball, and the PMO’s tend to vastly underestimate the complexity of the project as a whole.

Yep, ok -— I was wondering if I’d erred in that way. I getchya. On the other hand, engineering is creative work and you can’t force or totally control the creative process. The “trick” I think mostly, when it comes to engineers, is to be clear about what you want them to do. I’ve said sometimes that you have to be careful what you tell an engineer you want - there’s a risk he might deliver it.

As for a sense that engineers aren’t supporting the overall process sufficiently - I harken back to my experiences in the ancient simple sequential project form. By the time software is delivered to test, engineers are either laid off (if they were hired for the project) or reassigned. Testers could complain about the lack of documentation and knowledge transfer, and involvement in their QA processes, but the engineers weren’t around to hear it.

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.

Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.