and catch the ball better than the other guys.
Frank: That's not always a real popular thing for people to hear, but it's those kind of basic infrastructure things that are sort of really the most important when you get to software development.
Carol: And do you think that… I know that we're taught the technical skills, we're taught the programming, we're taught how to code, we're taught how to do creative hardware design, creative ………….. Do you think it's an issue of trying to teach technical people, people skills? Do you think that's part of the issue? Teaching them communications skills, or that they're lacking in that?
Frank: Well, clearly, interpersonal communications, people skills, are very very important to this. But it's more than just that, Carol. It's also the fact that we try to instill in people, and this is not strictly just in university, this is once they get into the work environment as well, there is an attitude that quite often evidences itself that, "I'm a skilled artisan, I'm a very highly creative person, no one else could possibly write code the way I write code."
Frank: "And therefore, I can't possibly follow any disciplined rules. That's going to take away all my creativity, it's going to sap my real strength, which is coming up with creative solutions and doing things my own way."
Frank: Which is really unfortunate, because the whole idea of having disciplined processes isn't about sapping people's creativity. In fact, this is the standard argument about rigor versus flexibility that's been going on as long as I've been in this business. The real value of a disciplined process isn't that it takes your creativity away, it's that it focuses your creativity on the area where it really should be applied, which is "How can I best solve this business problem for my client?" Not on "How am I going to choose to write a requirements spec this time?" or "Am I going to write a requirements spec?" or "How do I have to have my project plan documented?" or "What kind of team meetings are we going to have?" Or things like that. Those are things that really aren't relevant to how are we going to solve that business problem for the customer.
Carol: Right. And that's an interesting perspective, that creativity, which oftentimes traditionally in engineering has been kind of stifled. I think that computer scientists traditionally rarely focus on some of that, and we've got much more creativity that's nurtured. So it's a very interesting whole world of software.
And welcome back. I'm Carol Dekkers of Quality Plus Technologies, and we're talking about software process improvement - how we build software, how we end up with software that isn't great quality. And anybody who's tried to link two pieces of software together, anybody who's used software, knows that the fatal abend errors that come up and say "what do you want to do?" I was in Japan last week at the world congress on software quality, and one of the presenters was talking about some of the initiatives going on in Europe, where he said some of our cars actually have a lot of software in them. And software quality's becoming a big issue when you've got 80% of your car functions being managed and controlled by software. And he said wouldn't it be something, and he showed a joke slide, if the braking system came up with a "What do you want me to do? The brakes are failing? Reboot. Abend. Ignore." And