Obscure software engineering terms

Question

Hi,

I hear a lot of terms which aren't well known amongst programmers (or perhaps the ones I work with at work aren't very good apart from a few), such as "technical debt" (which I studied and even see first hand at work).

What other obscure/not well known terms are there? This is especially useful to know as interviewers sometimes mention complex terms and if I don't know what they mean, it can screw up the interview as it is in progress.

Thanks

Answer 1

A lot of people haven't heard bus number before, which I find immensely useful. Once someone has it explained to them, I've noticed they really get a kick out of it and see the utility of such a concept immediately.

For those of you on SO who haven't heard it before, the bus number of a project or undertaking is the minimum number of people who, if they were to be hit by a bus, would cause the project to fail or place it in jeopardy of failure. Whenever a person holds too much institutional or technical knowledge on a project, the bus number becomes 1, meaning that if this person is unavailable, the project is likely to fail. (You might say such a person is an information silo, which is another useful term.)

Your goal is to have the bus number be close to the size of the entire team (that is, a good chunk of the team has to be out of commission before there's a serious risk of failure).

Note that a low bus number isn't bad, per se. It may be that you have team members with incredibly specialized knowledge that would take too long to transfer to someone else. But it's a warning sign that you have a risk which will be difficult to mitigate: you can't merely hire someone else to replace the person, nor can you ask that person to educate other team members without sacrificing at least some of their effectiveness and temporarily slowing progress.

Answer 2

I think you should do two things:

1. If you encounter jargon in an interview, stop and ask the interviewer to explain what they mean. This gives the interviewer a much better impression that you're honest and interested in learning than trying to stumble through the interview.
2. Start a technical jargon file. When you encounter things like "technical debt" at work, on blogs or whatever, add it to your jargon file. Google it and get a sense of its meaning.

When you're done with step two, post an answer here :)

Answer 3

The only other term I know which makes a financial analogy like "technical debt", is "software taxes": work that needs doing, but brings no immediate benefit, such as internationalization (or i18n).

There are probably thousands of obscure specialized terms, by language (hygienic macros?), application domain (rapid time?), business domain (any number of TLAs), company culture (microsoftese), or historical heritage.

In interviews, it's much better to admit that you do not know what a specialized term means than to give an inexact answer about something you do not really know about.

Interview questions are usually a way for the interviewer to get a feel of your personality, the answers you give are not really essential.