Comment:     by Brian Lanham 1/26/2005 WOW! Great column! I have a client who is like this about 'iteration' or any derivative thereof. I am a "call a spade a spade, otherwise it's a shovel" guy too and I am glad to see you standing out in this area. Also, love your book!
	Comment:     by Joe Strazzere 3/1/2002 A consultant who proclaims "I don't play those games" when asked by a client to avoid particular terms? That's different! When a customer wants you to modify your methods a bit, you decide they need to be educated instead? Interesting! This may work for you, but in many situations people will be better served by learning to adapt, rather than declare that "my words are the correct words".
	Comment:     by Jim Hazen 3/1/2002 Yes, I have to agree with the intent of the article. Calling a "spade a spade" is the way to go. We always get caught up in using new terms for the same thing. I also agree with what was said about explaining and defining the term. A lot of the problem out there in the industry comes from lack of understanding, when both parties speak the same language and understand its meaning then communication is improved. It is the breaking of the "terminology ice" that needs to occur first in order for the communication flow to work. Implementing and monitoring are tough to do, but if everyone agrees to the terms and buy's into their use then the...Read On
	Comment:     by Yudhish Belankar 2/28/2002 A Wonderful Article. I believe everybody in the industry has experienced situations as it appears in the article however not all cases are similar. In a situation when people come from different software organizations, they tend to look at the terminologies in the way they were taught or had experienced in the previous organizations. For certain terminologies like "non-compliance" people take it up as a personal comment even after training and facilitation and when the same is referred as an "action item" it seems to be more comfortable!! Well a common understanding or interpreatation of terms could be helpful but it needs a lot of effort...Read On
	Comment:     by Rodger Drabick 2/27/2002 Karl, great article. You wrote 'We can start with the "IEEE Standard Glossary of Software Engineering Terminology" ', in your response to James Bach's comment. I agree; I'm a big fan of the IEEE Glossary. Also, as I'm currently working on a book about Testing Process, I created my own Glossary because the terms "Test Plan", "Test Case", and "Test Procedure" have so many different "interpretations" in our industry today. As you know, I get very upset when I see "ambiguous" requirements, so I have a big problem with ambiguous terminology in any location. Unfortunately, English is nasty that way. And we engineers probably don't do much to help.
	Comment:     by Tek Wallah 2/26/2002 Karl made a good point about watching our language. I worked at a shop where the concept of methodologies had been so abused that you immediately lost credibility if you used it. On the other hand, I believe that much of the negative reaction to software vocabulary is based on an objection to software engineering practices. Some of us don't call ourselves engineers, not just because it would be illegal in some countries, but also because we don't believe that engineering is a good paradign for modern software projects. The difficult part of leaving the analogy with bridge building behind is to not throw out useful procedures along...Read On
	Comment:     by Carol Dekkers 2/26/2002 Karl, Eloquently put! I believe you hit the nail on the head (so to speak) that communication is a critical factor to advancements in software engineering. When we do software measurement training (and particularly when that nasty "F" word -- "Function Points" is involved), I tell people that the measurement industry as a whole involves common IT terminology, but often their meanings are different -- in fact, we become "separated by a common language", much like we can be separated if we don't understand the differences between American and British English. IMHO (In My Humble Opinion), terminology and resistance barriers are convenient...Read On
	Comment:     by Kenneth Katz 2/26/2002 Unfortunately, the vast majority of contemporary software development is not an engineering process but "hack code now and fix it later". This will continue as long as enterprises tolerate poor quality software whereas they would never tolerate automobiles, airplanes, bridges, water/sewer systems or electrical power supply of comparable poor quality.
	Comment:     by Gábor Ponyi 2/26/2002 This issue definitely deserved an article and I absolutely agree with Karl in what he wrote. This is why I have to reflect on the reader comments about local vocabularies. Of coures there is a place and need for a local vocabulary but this should not be abused. Not calling the CMM -- one of the few well established and commonly understood terms in the SW profession -- CMM for whatever reason is wrong. The same goes for any published methods and processes. Using (enforcing) these terms will make communication easier both locally and globally. Locally: some of the audiance might be familiar with the terms. Globally: we, SW professionals...Read On
	Comment:     by Andrew Raybould 2/26/2002 I must admit that I cringe when I hear the word "process", even though I understand its importance. This is because there seem to be many people who believe that if we can just find the right process, and make it detailed enough, we can turn software development into painting-by-numbers and all will be well. This sort of thinking has been around for decades, and it is never successful because it ignores the importance of human skills in the reasoning about, and communication of, abstact ideas, which are the key prerequisites for successful development.
	Comment:     by Jon Anderson 2/26/2002 Karl -- You mentioned several causes for why people react to things the way they do: bad experiences, different backgrounds, different definitions for terms. There is another one that I have found -- partly because I have succumbed to this myself. When you are in the initial stages of being exposed to a new concept (in the "impressionable years" as you mentioned) you interact with others who have had more experience in that area. If you respect that person's opinion and expertise, and that person expresses a specific viewpoint on this new concept you are learning, that person's viewpoint can have a strong influence on how you think about...Read On Author's Response: 2/27/2002     Jon -- This is an important observation; thanks for sharing it. Our values, vocabularies, and priorities are certainly shaped by our teachers, be they classroom instructors or respected colleagues and mentors. As we learn more and gain personal experience, we sometimes find ourselves disagreeing with people whom we respect. I learned about this in graduate school (in chemistry, of all things). My first year, I could barely understand the literature I tried the read. My second year, I understood much of it. By my third year I was critiquing what others had written, and in my fourth year I began contributing to the literature myself. We need to pick our mentors carefully, I guess.
	Comment:     by karen gonzalez 2/26/2002 Good article. Frequently, in teams of software developers, testers, project managers and business analysts, terminology causes misunderstandings. I wish I had only known earlier in my career, because it would have probably helped, had I given qualifiers when using terms. I have my own understanding and experience with terms such as 'integration testing', but these terms certainly can mean different things to different team members. Not qualifying industry terms with an example or definition can lead to a total misunderstanding of the project's schedule. I was in a software testing class, where trained testers applied different meanings to...Read On Author's Response: 2/27/2002     Karen -- Thanks for your comments. Your experiences point to the confusion that can arise without a common vocabulary that is shared across both individuals and organizations. If team members differ in what they think, say, "integration testing" involves, important activities are likely to be overlooked and product quality can suffer. Shying away from terms like "defect," which are well established in the industry (if not always with a uniform definition) tends to criminalize the errors that people unavoidably make. Using euphemisms like "issue" doesn't really help us very much.
	Comment:     by Robert E. Lee 2/25/2002 Great article, Karl! It certainly suggests that it is worthwhile accumulating a personal glossary [and probably a similar glossary at varoius levels of organization]. Every time you detect a difference of interpretation on a significant software or business term, note it to help avoid later confusion. I think this works just as well in-house as for a consultant. It's also useful to note local usage that differs from IEEE etc., this can be displayed to consultants and new people before confusion needs to be debugged.
	Comment:     by Mary Steinborn 2/25/2002 Karl, I wholeheartedly agree with you and commend you for sticking to your guns about vocabulary. I also can't help shuddering to hear that there are organizations where the words "process", "requirements specification", and "methodology" are hot buttons. Yes, if someone else wants to use a different vocabulary that has words that are truly synonymous with yours, by all means use them. But if "process" is a hot button, the culture at that organization isn't simply objecting to the word, they are avoiding the idea of process. If "requirements specifications" is a hot button, you can bet that they believe they can accomplish quality...Read On
	Comment:     by Marshall Lee 2/25/2002 This article points out the pervasive problem in most companies that words are often used without clear definition. I took away two things from reading this article: (1) if you want to use a term, make sure you have a clear and convincing definition, (2) the author's approach to engineering. This article brushed closest to being an advertisement for the author then any other article I have read from this site so far. I know that most contributing authors to this site are also looking for work, but at least try to write articles that give more helpful information then a bio on your work practices. Author's Response: 2/25/2002     Marshall -- I'm sorry you read my article as being an advertisement. That certainly wasn't my intent. There's an old saying that "you write what you know". Like everyone else, I learn from my experiences and from my interactions with a variety of people in different situations. Many of those experiences have yielded powerful lessons and insights over the years. When I share those lessons, I illustrate them with examples of the seminal experiences. I'm sorry you interpreted this as an advertisement.
	Comment:     by James Bach 2/25/2002 Hi Karl, I don't understand what you mean by calling spades "spades". In Portuguese a spade is "pá" (according to AltaVista, anyway). In the software field, we don't have an agreed upon set of definitions. They vary from community to community. From your column, it sounds like you have a particular set of definitions that you'd like to impose on everyone else. That's like driving the process improvement truck with the parking brake on. I can smell those brakes burning from here. Emotional reactions can work for or against you in the realm of intellectual processes. I strongly recommend that you get them working for you, and drop that talk...Read On Author's Response: 2/25/2002     James -- "Calling a spade a spade" is a pretty common expression. Don't you think it would be helpful if we did have an agreed-upon set of software definitions? They certainly don't have to be my definitions, but we need to be able to communicate effectively and honestly. We can start with the "IEEE Standard Glossary of Software Engineering Terminology," unless you have a better suggestion for cutting the software Tower of Babel down to size. I once read a process document that was titled "Procedure and Policy" for something, and in the text it variously called itself a guideline, a process, and a standard. All it really was is a procedure, but if someone is dead-set against policies, the title alone would turn them off. I think we'll all be better served by educating ourselves, our colleagues, and our clients about what terms really mean so we're on the same wavelength.
	Comment:     by Andrew Wetmore 2/25/2002 I believe in speaking clearly, because in the end it reduces occasions for misunderstanding. But what is suggested in this column needs to be adapted to the local culture and vocabulary, and has to take into account that the "let's use my definition" approach only works if the speaker has sufficient standing to be allowed to get to his second sentence. At my firm, some very peculiar names have been assigned to various stages of the test process, mainly because some pretty high-status folks wanted to use them. So we use them. There are other issues I would rather bleed to death over than nomenclature. Author's Response: 2/25/2002     Andrew -- You're right, we need to adapt to local vocabulary and culture, but we shouldn't avoid overloaded and misunderstood terms or use definitions that conflict with established terms. In the case I cited about using my definition for a specification, the senior manager involved wasn't a software person. When I told him what I thought a software requirements spec was, he found that an acceptable definition, but the term "specification" got him on edge until he heard that definition. At one of my clients, the CEO had heard bad advice from a seminar instructor about how dangerous prototypes were so he was leery of them when I recommended them. I could have made up some other word to trick him into accepting prototypes, but he still would have had the wrong impression of "prototypes". So instead, I tried to educate him about the risks and benefits of prototyping, and he gained a better appreciation.

Back to Top