This could also be called "verbal communication in the small".
There are some words that are misused quite frequently; their misuse can cause misunderstanding which can lead to unhappiness. When I hear these words misused, I have to sit down and have a cup of tea.
Here are some examples in the context of project planning:
Question: what's the population of UK? A precise answer is 57,675,328. A more accurate answer is 60,000,000. Capiche?
Ever had building work done? A quote is what you will (or at least should) pay (fixed price). An estimate is a guide to how much you'll pay - it might be more, might be less (time and materials). Developers will give you an estimate for the cost of some piece of work. If you want a quote, you need to explain what that means, otherwise you'll get an estimate no matter what you ask for. A quote will always be larger than an estimate if the person giving the quote knows what the difference is (or if you ask for a best case/worst case pair of estimates it will be something like the worst case estimate.) With builders (and outsourcers), the quote will also depend on how much they want the work and what they think rivals will bid. Software developers working on an internal system generally aren't concerned with such things.
The value of some piece of work is, roughly speaking, how much money it will save or how much revenue it will generate (minus how much it cost to produce). An estimate from developers of how much a piece of work will cost is just the cost - not the value. The value might be high and the estimate for the cost low, or vice-versa. Cost and value aren't necessarily related - use the right term or people will be confused.
Following on from the previous article in the series, another "programming in the small" style thing that I often see, even by people who understand non-interacting fermions, are conditionals that are more complicated than they need to be.
Consider the following (Java) code:
public boolean isWhatever() {
if(someCondition() == true){
return true;
}else{
return false;
}
}
Must control fist of death.
someCondition() == true can be replaced by someCondition(), which is easier to read.
There's something about the existence of the "true" which I think sends my brain (and I guess others) thinking about programming rather than the meaning of the code.
For the opposite value of the condition, some people do someCondition() == false rather than !someCondition() which I have heard justified on the basis that ! is easy to miss - which is a reasonable point but again I find obscures the meaning (if you read the code rather than interpret it as a program). It's not: "if the water to make my tea is boiling hot is false then throw a hissy fit" - no - it's "if the water to make my tea is not boiling hot then throw a hissy fit".
In python the equivalent of ! is not, which I think is much more preferable - but unfortunately my programming in the small articles don't result in changes to languages quite yet. I think ! is typical of the wrong-headed "C" based nonsense that also includes each case of a switch statement needing a break - but maybe that should be another article.
Anyway, back to the plot. This leaves you with:
public boolean isWhatever() {
if(someCondition()){
return true;
}else{
return false;
}
}
Must still control fist of death.
This can be replaced by:
public boolean isWhatever() {
return someCondition();
}
less is most definitely more. I've also seen someCondition() ? true : false, which is also pointless.
David Peterson suggested another category of over complicated conditional (thanks David) - where the conditional is negatively named, for example:
if (!isTeaNotHot() && isCupNotEmpty()) {
bewareOfSpillage();
}
is much easier to read with positively named methods:
if (isTeaHot() && !isCupEmpty()) {
bewareOfSpillage();
}
Other conditional related stuff that annoys me (but less obviously - I probably won't spill my tea when faced with such code) is where there are more if statements than necessary, that could be replaced by judicious use of &&, || and ==.
Consider the following code:
public boolean isWhatever() {
if (someCondition()) {
if (someOtherCondition()) {
return true;
} else if (yetAnotherCondition()) {
return true;
}
}
return false;
}
this can be replaced by:
public boolean isWhatever() {
return someCondition() && (someOtherCondition() || yetAnotherCondition());
}
which is so much easier to understand (given someCondition(), someOtherCondition() and yetAnotherCondition() mean something). In general, I think fewer if statements lead to a more easily understood meaning.
Something based on my current reality:
public boolean successfullJobInterview(boolean candidateIsSuitable, boolean candidateIsOfferedJob) {
if (!candidateIsSuitable && candidateIsOfferedJob) {
return false;
}
if (candidateIsSuitable && !candidateIsOfferedJob) {
return false;
}
return true;
}
it looks reasonably logical and simple - how could this be improved?
public boolean successfullJobInterview(boolean candidateIsSuitable, boolean candidateIsOfferedJob) {
return candidateIsSuitable == candidateIsOfferedJob;
}
which is simpler if you think about it.