|
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? |
|||||||||||||||||||||
|
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 specific 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, see the FAQ for guidance.
|
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. |
|||||||||||||
|
|
Programmers are interchangeable. Only if you're using them as type monkeys, at 5-10% of their capacity. Then yes, they're replaceable. |
|||||
|
|
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. |
|||||||||||||||||
|
|
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. |
|||||||||
|
|
It's going to take 5 days to do that. It never does. |
|||||||||||||||||
|
|
"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:
|
|||||||||
|
|
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. |
||||
|
|
|
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. |
|||||
|
|
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! |
||||
|
|
|
TDD is required and sufficient to produce a high quality product. Both are... let's put it mildly, out of touch with the reality. |
||||
|
|
|
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." |
||||
|
|
|
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. |
||||
|
|
|
"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. |
|||||||||
|
|
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.
|
|||||
|
|
Once you 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. |
|||||||||||||||||||||
|
|
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. |
||||
|
|
|
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. |
||||
|
|
|
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. |
|||||
|
|
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 ;) |
|||||||||
|
|
One of my favorites:
... |
||||
|
|
|
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. |
|||||
|
|
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. |
|||||
|
|
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 |
||||
|
|
