Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I was recently in a discussion about the absolute statement "It costs more in programming time to optimise software than it costs to throw hardware at a problem".

The general thought (of which I agree with) is that as an absolute statement this is wrong. There are too many variables to ever generalise in such a way.

What other statements do you hear about software/programming that simply do not work as an absolute and why?

share|improve this question

closed as not constructive by Mark Trapp, Walter Jan 7 '11 at 13:25

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

9  
Pretty much all absolute statements about programming are wrong, but I guess you're looking for specific examples? –  Jon Hopkins Dec 21 '10 at 13:49
9  
Actually almost all absolute statements pronounced by humans are wrong. Ignorance and arrogance are not limited to programming. –  user8685 Dec 21 '10 at 13:53
3  
To avoid confusion, maybe this post should be renamed "Mythical Absolutes in IT." –  Mark Freedman Dec 21 '10 at 14:08
9  
All absolute statements about absolute statements are wrong :-) –  Todd Williamson Dec 21 '10 at 14:56
1  
This question doesn't meet enough of the six guidelines for good subjective questions. –  user8 Jan 7 '11 at 7:38
show 3 more comments

24 Answers

up vote 50 down vote accepted

A bit about usability:

People will read our texts and documentation.

No, they won't. They'll click everything in circles slowly getting mad because it doesn't work.

share|improve this answer
1  
@Uwe Keim: He's a saint. You should promote him to a "saint developer". –  user8685 Dec 21 '10 at 20:37
8  
On the other hand, the less you have to read documentation to use a tool, the better designed the tool seems to be. –  Lars Wirzenius Dec 22 '10 at 8:45
show 2 more comments

It costs more in programming time to optimise software than it costs to throw hardware at a problem

Is adding an extra $1000 server for static content cheaper than 100 man hours to redesign an entire web app? Probably.

Is 50 man hours optimising a poor processing algorithm cheaper than replacing a half million dollar core server, including full regression testing, down time, etc? Certainly.

Without actually analysing the unique situation you are attempting to apply it to, there is no way of knowing.

  • How many man hours would it take to improve the software?
  • How well does the existing software scale with additional hardware?
  • What other costs are associated with new/additional hardware?
    • Downtime?
    • Additional energy costs? (Including additional cooling)
    • Additional software licenses (more servers/more cores)?
share|improve this answer
1  
It also depends on your target. If you're developing software that runs on a server, it might be worth it to just buy a bigger server. But if your software runs on the client, and you have a wide distribution, then it's not cheaper to ask all 100,000 of your users to upgrade their PC... –  Dean Harding Dec 21 '10 at 21:51
add comment

Free software is cheaper.

You save on licenses, yes. But you're not taking into account additional wage expenses on extra man-months to make things tick. At the end of the day the TCO may be way higher.

share|improve this answer
4  
It depends on your employees and the software you are using, it can go either way. I think, in fact, because most software is cheap in comparison to the time it takes to train people, whether software is free or commercial has little bearing on the TCO. –  dan_waterworth Dec 21 '10 at 14:22
4  
but at least you have a chance to fix things. –  user1249 Dec 21 '10 at 14:44
8  
To supply another frequently false absolute: Free software is useless. I think you'll find my false absolute much more common in business than yours, although yours is more common in programming communities. –  David Thornley Dec 21 '10 at 15:49
8  
I think you can generalize this to "The cost of software is primarily indicated by the purchase price". goes back to scheduling training for the enterprise-grade project management software being rolled out in a few days to replace the enterprise-grade project management software rolled out last year to replace the enterprise-grade project management software in use before that... –  Shog9 Dec 22 '10 at 4:04
show 2 more comments

"premature optimization is the root of all evil"

Although this one does work, it is often taken out of context (I could swear many people convenently ignore the 'premature' bit). Some people seem to read this as "any optimisation is the root of all evil"

I wish those people would read more of the text around that small quote:

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

Yet we should not pass up our opportunities in that critical 3 %. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail"

~ Donald Knuth

share|improve this answer
3  
There may be good habits to get into, also. In C++, ++i to increment a variable as a stand-alone expression will never be worse than i++, and sometimes may be a lot more efficient. –  David Thornley Dec 21 '10 at 15:51
2  
++ I'm an A1 pest on this subject. So much stupid stuff is said about it, and so very few people actually know what they're talking about. They say "measure measure". They say "get the right algorithm", all of which totally misses the point. The point is to actually do performance tuning and in the process learn what approaches to take, and what well-known and recommended practices to avoid. –  Mike Dunlavey Dec 21 '10 at 23:11
add comment

TDD is required and sufficient to produce a high quality product.

Both are... let's put it mildly, out of touch with the reality.

share|improve this answer
show 1 more comment

Programmers are interchangeable.

Only if you're using them as type monkeys, at 5-10% of their capacity. Then yes, they're replaceable.

share|improve this answer
1  
So I can't fire you? –  muntoo Jan 7 '11 at 7:09
show 2 more comments

We can reliably create a successful product by investing some money and throwing some workforce at it.

Not really, if by a mere chance. You need a vision and a genuine desire to make things somehow better and your future users happier. Without that, the outcome is random.

share|improve this answer
add comment

It's going to take 5 days to do that.

It never does.

share|improve this answer
3  
6 to 8 Weeks: meta.stackexchange.com/questions/19478/the-many-memes-of-meta/… –  user8685 Dec 21 '10 at 14:15
1  
@Thorbjørn - sometimes. –  Otávio Décio Dec 21 '10 at 14:48
4  
You mean "It's going to take ____ days to do that." Whatever your estimate is, it's too low. Also, it's too low because your scope is wrong. –  NickC Dec 21 '10 at 17:44
2  
There's actually a law for that. Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. –  Michiel Kalkman Dec 22 '10 at 1:15
show 2 more comments

It is true that one should be wary about absolutes but the statement that you quote is not a absolute statement per se but rather rule of thumb which is arguably true for many but not all cases (such as the example given by Dan). Truth be told I can't recall any objectionable statement which is considered as absolute by the programmers

share|improve this answer
add comment

Programmers are pure overhead against the company's bottom line.

Maybe this was true back when people could substitute a general ledger notebook for a database, but in this day and age, an efficient and competent programming staff can save a company great piles of money. Piles of money saved = piles of money earned.

share|improve this answer
add comment

The only difference between programming languages is syntax.

This statement refers, of course, to Turing-equivalence and is generally used to refer to a language with features lacking in the preferred language of the person making the statement. It would be more accurate to say that syntax is a difference that results in more differences when it comes to actual coding and maintenance.

share|improve this answer
show 2 more comments

Nobody over 25 can program effectively

It's probably based on the fact that teenagers are good at all-nighters, which seems to outsiders like an incredibily efficient way to program.

share|improve this answer
5  
Forget all-nighters. In my early 20s, I had nowhere near the number of distractions, obligations, conflicting priorities, etc. that now compete for my attention daily. Consequently, I was a hell of a lot more productive, even on the days when I only worked a few hours... –  Shog9 Dec 22 '10 at 4:06
1  
@Dean, I've heard it at least 0.5 times per year, since 1984, when I first started programming. –  Lars Wirzenius Dec 22 '10 at 8:43
show 2 more comments

Once you learn language [commonly C++], all other languages are trivial to learn

I have never met a university professor who didn't genuinely believe that this statement was true. I've argued it till I was blue in the face, but they have all been insistent that the language is a simple implementation detail, and are as such, interchangeable.

share|improve this answer
7  
Arn't languages trivial to learn? Are we talking about the language, or the ecosystem around the languages? –  Morten Dec 21 '10 at 18:59
3  
If you've got the concepts, the syntax is generally easy to learn. The tools and libraries might take longer, and of course new concepts can take years. –  David Thornley Dec 21 '10 at 22:49
4  
It's probably true in the case of C++ ; I've been learning it for 20 years, and I still find rules and exceptions and whatnot.When I finish learning it, I'll probably know all the other languages already. Hence, trivial to learn. –  egarcia Dec 21 '10 at 23:37
7  
I think the point is that once you have mastered one language you will have learned the skills necessary to master the next one. Honestly... your professors are exactly right. You go from not knowing the details to knowing which of the details you know not. –  instanceofTom Dec 22 '10 at 0:43
1  
To all commenters: try going from C++ to Haskell or Lisp. Heck, even Python or Ruby. And I'm not talking about libraries or syntax, but concepts, abstractions, workflows. –  Mauricio Scheffer Dec 23 '10 at 22:13
show 3 more comments

"You're not a real programmer: you're not constantly typing". At first, I hoped it was just a joke, but no, he was serious.

A short moment of unconfortable silence ensued before I proceeded to explain that thinking about the implications and weight which type of implementation to do before coding or even sketching diagrams to structure is also part of the process x_x

On the other hand, the colleague he was implicitely comparing me to is an obsessive typist: he's my best mate and a great guy, but he writes the first thing that springs in his mind and only thinks about it while he's typing, so he's hitting backspace more than half of the time: looks great to "look busy" when management comes around, but quite a pain to maintain the code or integrate with the rest of the application.

share|improve this answer
2  
"He's my best mate and great guy" but an utter moron. I'd be worried that my thinking would be contaminated. –  Yar Dec 21 '10 at 22:59
1  
Those type of programmers excel at small projects but crack when given a large project. Imagine he was your boss... –  snmcdonald Dec 22 '10 at 0:14
show 1 more comment

Free software is useless

Often found in business circles, rarely among the programming community.

Often associated with the naive belief that commercial software vendors actually take responsibility for their products. If I had a nickel for every time I've heard "someone to sue", I'd get myself a much nicer home box and monitors.

Often also associated with the belief that nobody would do good work except for money.

share|improve this answer
6  
This one is so true. Last year I spoke with a client that didn't want to use Google maps on their corporate page because "Google free apps are for hippies". –  egarcia Dec 21 '10 at 23:39
show 2 more comments

Development time is proportional to the number of developers

This is a classic but it might be new to some programmers.

"Adding manpower to a late software project makes it later."

-The Mythical Man Month.

share|improve this answer
add comment

Learning a language means understanding its syntax, and is therefore trivial.

"Programming language" is not synonymous with "spoken/written language" in this way. Knowing the syntax of a programming language is equivalent to knowing the alphabet of a spoken/written language. Really learning a language involves much, much more than its syntax.

share|improve this answer
3  
This is true of spoken/written language as well. –  ebneter Dec 22 '10 at 1:16
add comment

As long as we document it, no one can claim it is a bug.

I've been on too many projects that excuse unexpected or stupid behavior as long as we write it down somewhere.

share|improve this answer
add comment

The users know what they want/need

Most of the time, they really don't. They may think they do, and some may even be in the neighborhood, but they really don't. The rare few who really do know what they want can't describe it well enough for you to get it right the first time.

In consulting, this is often called the "presenting problem"; in development, it's the 80/20 rule; in programming, it's the admonition to expect to throw away the first prototype.

Users don't really know that they want/need because they don't understand what is truly possible...and what isn't!

share|improve this answer
add comment

My software is perfectly secure.

share|improve this answer
add comment

One of my favorites:
* usually after application crashes for unknown reason

Nope, it's not cause of my code. Definitely.

...

share|improve this answer
show 1 more comment

Splitting and branching a product will make maintenance more efficient.

I've seen this one burn companies very badly several times in my career. It's very tempting to think that different things will break in the slightly different, specialised versions of products, so that teams working in their own specialized "bubbles" can efficiently maintain their own stuff. But more often than not, this just leads to a mess where the same things have to be fixed in every separate branch, and inter-team communication and integration becomes a nightmare.

Also: this development model often leads to the "Mythical Man Month" thing happening.

share|improve this answer
1  
It's more likely that inter-team communication was already poor, branching isn't a silver-bullet, but if it's done properly, it's extremely useful. Anything done badly is a problem, and branching requires a high level of group coordination/cohesion. –  Slomojo Dec 23 '10 at 23:11
add comment

There is no such thing as bug free code.

I'm sure this will seem controversial, but there are plenty of scripts and small projects out there that have 0 bugs. But of course, that won't be the code you're writing right now, or that project that's about to go live ;)

share|improve this answer
4  
+1. The version I tend to trot out is "there is no such thing as non-trivial bug free code.". :) –  Bobby Tables Dec 23 '10 at 23:12
1  
This makes me think of the stuff NASA produces - fastcompany.com/node/28121/print? –  Bjarke Freund-Hansen Jan 7 '11 at 9:20
show 1 more comment

If you are a Programmer you should inherently understand the business logic behind ALL your company's software.

Even though we are capable of writing software, it does not mean we will inherently understand the internal business logic of every piece of software our company owns or requires us to write.

In my experience customers assume we have a fundamental understanding of the business logic when proposing new software. Customers often become frustrated when you ask for further direction. I think there is an assumption that since tasks on the computer are "quick", then the time required to plan and write a piece of software should be proportional. Customers can become even more frustrated when you explain the dangers of the implementation they are asking for. Its like a one way street of knowledge, the programmer should fully and immediately understand the business logic, but customer will step back from understanding the mechanics of the software, expecting it to be done.

In another aspect, management will assume since you are a programmer you should inherently be able to use every piece of company software without training.

share|improve this answer
2  
just your companies? most non-tecnincal people seem to assume you know the intimate details of all software and hardware ever produced –  jk. Jan 7 '11 at 9:42
show 1 more comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.