You can't do that
jacquesmattheij.com
jacquesmattheij.com
Though far from the level of difficulty presented by jacquesm, the same thing happened to me with an end-of-term project a few years back.
We had to make a small piece of software in Java. Most of my mates were going for boring stuff, such as sudoku solvers or small neural networks to play the likes of Connect four.
I wanted to make a Gameboy emulator.
"You can't do this", said my professor. "At least not in two weeks' time."
Well I don't remember much besides coding during those two weeks, but guess what - after 14 days, my program could boot Tetris. No sound, granted, but it was playable.
My professor was quite the sore loser though - he considered the program incomplete since it only booted a few roms, didn't have sound and could crash randomly. I ended up turning in a gameboy rom dissassembler instead, complete with GUI and breakpoints setting.
Still, never believe that "you can't do that".
It didn't even count towards course credit, but by the time I submitted I'd built everything, with an in-game level editor and reflective surfaces (all software-rendered). It was way beyond what I had ever achieved, and completing that project totally changed my view of what was possible.
Make sure that story comes through on your resume.
My friends called it "Ray" and would leave funny drawings on my desk depicting them partying while I played with Ray. Or if I had been partying with them, they'd all groan when we arrived home and I set to work. But it was definitely worth it.
There may be one important lesson in that experience, though (not that I believe the prof was trying to teach it): complete, rock-solid software with few features beats glitzy, bug-filled software with many features. Users will never know what they are missing.
Professor told me to do self-localization of soccer robots based on greyscale images and assigned me to a PhD student.
PhD student said "This can't be done, at least not in real-time" and was angry about his professor because he now had to look after me somehow. Of course, he didn't.
Six months later, my program could self-localize a soccer robot based on greyscale images, in real-time. On large fields and with varying light sources, which the previous, color-based algorithm couldn't.
Unfortunately, PhD student was a sore looser and still gave me a bad grade. Professor didn't help.
For my final thesis in college my professor made me change my mind. My initial project idea was a music instrument, a polyphonic digital synthesizer (TTL-only, no processors). I had a single wavetable "voice" implemented in silicon already, as a proof of concept.
Instead, he convinced me to make a boring sawtooth variable current generator for his lasers. :( Grrr, I wish I didn't listen to him.
Great thought.
Most of my most memorable successes were when others said that something couldn't be done. First you think, "Why not?" Then you think, "What would it take?" Then you figure that you'll never find out for sure unless you try. The reward is compounded by the initial skeptism.
Just a few silly examples (any of these sound familiar?):
Manager: Shop Floor Control is impossible.
Me: Why?
Manager: Because the base data is so inaccurate.
Me: So?
Manager: It would take years to fix all the data.
Me: What if we turned in on anyway?
Manager: The output would be worthless.
Me: Wouldn't it show where the base data was inaccurate?
Manager: Yes.
Me: Then you could fix the biggest culprits?
Manager: I suppose.
Me: So turning it on would expedite data fixing?
Manager: Yes.
Me: So it's not really impossible?
Manager: Well...
Manager: Bug free software is impossible.
Me: What would it take to make is possible?
Manager: Nothing. Can't be done.
Me: What if we added systems testing to unit testing?
Me: And then built rigorous test plans covering almost everything?
Me: And then enforced User Acceptance Testing?
Me: And allowed nothing into production without passing?
Me: Would it be better?
Manager: Yes, but we can't afford to do all of that.
Me: So, bug-free software isn't impossible, just expensive?
Manager: No, it's impossible. Get back to work.
Me: Sigh.
Manager: A web app is impossible.
Me: Why?
Manager: Because it depends upon data entered by regular people.
Me: So?
Manager: People are idiots. They enter wrong data all the time.
Me: What if we trained them?
Manager: Impossible. They don't work for us.
Me: What if we made the software smarter?
Manager: What do you mean?
Me: Data validation.
Me: Data reasonableness based upon rules or history.
Me: Crowdsourcing data validation.
Manager: The data would still be bad.
Me: What would it take to make the data good?
Manager: Nothing. Impossible.
Me: Sigh.I'd say, "Impossible != Unlikely"
based on your skill set, you're likely to fail
It's probably safe to say that almost everyone who ever achieved anything great was also "likely to fail". It comes with the territory.
it can also lead to spectacular failure
Spectacular failure is to great achievement what striking out is to hitting a home run.
...and that a more rational approach is to say, "The value of a possible success" is high enough that it's worth the expenditure of energy to bet the "losing" side of a p = .01 (or whatever)".
[of course it's going to depend on who is expending the energy - and who get what portions of the possible success benefits]
Manager: A web app is impossible.
You: Yeah, I agree that it would be really hard to build,
but it would give us great advantages.
Manager: Maybe, but we can't trust data entered by regular people.
You: Yes, this is a pain to deal with. Fortunately, from
my past experience, I learned good ways to cope with that.
At the end, everyone agreed that it was well worth the
trouble. Anyway, I don't want to annoy you more with that,
I know you are really busy. Let me find the project I
worked on and let's talk about it later on.
Manager: "I'm the manager and I know what to do"
You: "Fuck you, I'm the coder and I know WAY MORE THAN
YOU"
Manager: (Don't like being contradicted by an employee..
even less being told fuck you): "I am right, here's why"
You: "Fuck you, I'm the coder and I know WAY MORE THAN
YOU"
Manager: (Don't like being contradicted by an employee..
even less being told fuck you): "I am right, here's why"
[..]
You: "Fuck you, I'm the coder and I know WAY MORE THAN YOU"
Manager: "No, you fuck you. I'm the manager and you won't
win"
Manager: "I'm the manager and I know what to do"
Me: I know you are the manager and you choose what to do,
but as a programmer (and from my experience), I could help
you take the best decision.
Manager: But I'm still the manager and I WILL CHOOSE WHAT
TO DO, not you.
Me: Yes, totally. I'll get some facts about xyz and get
back to you, so you can choose the best thing for the team.And ultimately, isn't this irrelevant? They are just a few general, entertaining anecdotes. I hope you don't take Dilbert or The Office seriously as well.
The manager comeback to that is:
Manager: Fine, but let's put the fact-finding on the back burner as it's not a high priority right now.So correspondingly in my experience, only poor quality and insecure managers would get the same impression as you. High quality managers would value the feedback and expertise from their technical folk, and never take direct comments, questions, or contradictory points as insubordination.
It's the first lesson I learned in management anyway. You hire people who are smarter than you, and you correspondingly depend on them for the questions you hired them to answer. Direct to-the-point conversations aren't conflictive, they're productive.
I can't tell you how many times, I've told people, "OK, just tell me the point." Likewise, I can't tell you how many times people have told me, "OK, just tell me the point." People don't like wasting time with unnecessary chit chat when they can get things done, and if there's professionalism and respect in the group, there's no chance such a direct contradictory statement could ever be perceived as an FU.
Manager: I pay you to know about this stuff. Also, it's
impossible.
You: No it isn't
Manager: (Likes wasting his money paying people then not
listening to them): I am right.
You: No you aren't.
Manager: (More interested in asserting schoolyard social
dominance than running a business) I'm not
listening la la la
You: *sigh* But....
Manager: I'm the manager and you wont win.
You: When we as a company do the impossible, we all
win. We can do it.
Manager: I don't care. I'd rather we all lose than you
win.
You: *sigh*The main problem about unit testing is that you only can demonstrate that the software pass all your unit tests not that the software is bug free.
Also, your software usually run on top of other layers that you need to trust like the operating systems, VM, BIOS, hardware failures...
1. Can the proposed idea be implemented as stated?
2. Does the proposed idea degrade gracefully, i.e., will an imperfectly achieved solution provide significant benefit?
The answer to #1 is almost always "No" because the simplest way to state an idea, the normal way to refer to an idea in conversation, implies that it will work perfectly in all cases. For instance, "bug free software" is impossible in practice, but if you achieve nearly bug free software, you'll have much less buggy software than your competitors.
You can't talk sensibly about any idea without explicitly moving on to question #2 and talking about costs versus benefits. Will one bad data point in the Shop Control Application cause an accident that costs ten times as much as the efficiency gained? Will the value of "bug free software" be negated by a single bug in a release? If your boss is still talking in absolute terms about question #1, then you need to move him to question #2 by explicitly talking about what the benefits of an imperfect solution are. In your mind, it may be obviously implicit in your proposal that there will be cracks in the system, but you can't blame your boss for taking your proposal for "bug free software" literally unless you explicitly address how an imperfect solution will be useful.
To the contrary, with adequate rigor it can be done. Naysayer complaints of "that takes too long" forget that there is no subsequent time spent fixing bugs because there aren't any.
Prime example is the seL4 operating system:
http://tech.slashdot.org/story/09/08/13/0827231/Worlds-First... http://ertos.nicta.com.au/research/sel4/
To the point of the article, there is a crucial difference between "impossible" (be it mathematical or physical) vs. "too hard for me to bother".
Oh, right, Google did it.
Your reasoning is exactly what the article criticizes: the notion of "that's impossible, don't bother" vs. "so what, let's do it anyway".
Our ability to handle complexity scales exponentially over time, and we're on a fast-rising part of the curve now; even if something is "impossible in practice" now, get started on the problem and predict at what point the industry _will_ have the technology to handle that level of complexity.
Hard != impossible. Hard now != hard in the relevant future.
Hurray for the patent system supporting innovation.
This guy just was too late, someone else beat him to it.
For some meanings if "unrelated field", using the same idea is not infringement but a new invention. It's called "novel application" or somesuch.
Check with a competent patent attorney.
When you think about the huge number of patents the big companies sit on, it's pretty much Russian roulette to try and to something new. At good chance to shoot yourself in the foot and waste a couple of years even if the idea works.
It's actually sad that the author seemingly did "the impossible" technically only to be stopped by some paperwork in the end.
Awesome takeaway! Without people taking that attitude, we probably would still be living in caves.
I accidentally established myself as a capable and competent worker at my job and have unfortunately given management the confidence that I can do anything. I'm using a negative context here because I've lost the ability to say no to them. I suppose since my job as a programmer is to give them what they want I should never want to say no, but I'm a sucker for elegance and I really try to avoid solutions that are overly complex and convoluted. Unfortunately, there are occasions in which a feature requirement requires such a solution. Or rather, not the actual feature requirement, just one of the "tweaks" they like to nitpick on to make it perfect. I.e "This is great, but you know what would make it perfect?" syndrome. Usually, I'm fine with these but when the tweak requires a complete overhaul or reimplementation--potentially days worth of coding to implement I'll try to dissuade them from it. Inevitably, if it's something they are really stubborn on when I say "well, I can't really do that--the system doesn't support event callbacks which is what would be required to implement...." I'll get back "It's impossible?".
And thats it, cat's got my tongue. I want to say yes. So bad. But I know the answer is no. I know they are confident in my ability, so they think they know the answer is no. But, seriously I'm gonna have to write a third party application in a different language and write a service protocol to communicate between the main ERP suite and the third party app to accomplish this and it's just so they can get an extra description feedback to an auto-complete feature. I know there are more important, more critical, more exciting issues that I could and I think I should work on. Whats worse, is that if I were a little less proficient, if I knew one less programming language it would impossible for me. Then again, it still wouldn't because I know I could just learn that one language and it would be possible. Arrrggghh there's no way out of this question.
"Well, no it's not impossible. I can probably do it. But it's going to take an extra couple of days.."
"Okay, let me know when its done."
[grit teeth].
Of course it usually takes me more than a couple days to do the impossible, but maybe you're faster than I am. ;)
Seriously, though, if there is a trade-off in feature value, the "agile" approach would be to point that out, and let them know what features they might be losing by having you work on one with only a lesser value.
Or in the words of a good friend of mine, if they're asking you to do it anyway, you're not charging enough for it. :)
The main drawback to the solution you describe is not the "two days to develop", but doubling or tripling the complexity of that part of the application. It will be a pain to support and enhance in the future.
Manager: "Is it possible?" You: "Yes it can be done, but you're basically making this application twice a complicated for this one feature. This makes deployment and support more complex, and if anything ever goes wrong, it will take a lot longer to even find the problem. If we ever want to upgrade the underlying software, this could break."
I've worked at few places that have done the real analysis to know the answer to that, but very few even consider it.
It takes a bit of persistence and convincing the other party to engage in what they consider a flight of mental fancy, but once you get over the "impossible" part and start figuring out how to solve the rest of the problem, I find that a solution that avoids the initially-impossible part tends to present itself. That, or you'll figure out why what you thought was impossible isn't. The beauty of this is that it works equally well when you're trying to convince someone else of something you know to be right and when you're trying to figure out a solution yourself.
The other easy strategy I use all the time (and this is more for concrete problems, as opposed to intellectual/theoretical ones) is start by deciding if the problem is one that can easily be solved by throwing money at it. If it can be, then it's a much easier question - you just have to determine if the problem is worth the money it would cost to fix it, which is simpler. If the problem can't be solved with money, then you know where to start to find a solution (enumerating all the non-monetary resources you have and seeing what might work).
Edit.: In these extreme cases it may even do good to discourage people to deal with these demonically hard problems. If you are addicted to thinking these problems are dangerous. Such hard problems ruined mathematicians life. You can become addicted to solve the problem, but you cannot solve it so you try harder. There is no sign of success, so you try even harder... When I was thinking about P vs. NP for 1 month I could not sleep well and could not concentrate on my job well. It was terrible. After the dark period it was so good to think about business, software development again where there are problems (or at least subproblems) which you can actually solve or partly solve.
From the other end, in my experiences, hearing "you can't do that" in a corporate setting has often (not always) meant that the manager/company didn't feel it worth the risk to the company. The manager won't be around 2 years from now when your project is completed, so he would rather you work on things with immediate impact so it benefits his review. Because of this big companies often get very risk averse, focusing on big, cash-cow projects and consequently slow their innovation.
Contrast that to startups where you've got a bit more freedom, I'd think you're less likely to hear it (if so, it might mean more of "we don't have the resources/money"). I think it's often less of the person being an ass, and more about what they're incentivized to promote.
- Paul Buchheit
I was recently working in a company where the task tracking system wasn't linked in any way to source control. I thought linking the two would be a great gain: being able to see the modified files from the task management system, and resolving the task directly in the commit message would allow managers and developers to easily increase productivity, if only by a little bit.
I had to have 3 different meetings with the sysadmin to get him to do that, each one escalating further up in the company hierarchy. Eventually, we had to tell him exactly how to do it, and my boss said it had to be done. The main reason the sysadmin said he did not want to do it was that he felt there would be no gain.
I learned a lot about office politics then...
If there is a proven theorem that something is impossible, either the theorem is wrong or it's impossible.
> the halting problem is solved routinely by people in software engineering research groups
I'm not sure how I'm meant to read this.
If it is that people do the solving of the halting problem (that is, people read the source of the program and say "this will halt" or "this will not halt"), then they have not solved the halting problem: the halting problem states there is no way to do this by algorithm.
If it is that people write software which solves the halting problem, then you are wrong, and you explain to yourself why you are wrong. They are solving a different problem, namely, whether some very small class of computable functions halts.
Your two sentences "the halting problem is solved routinely" (assuming you mean the latter case, as above) and "this does not invalidate the Halting Theorem" do not logically work.
It can get a lot more subtle than that. I do not want to elaborate, but there are classes of problems for which we can only guarantee SOME hard problems (or undecidable ones) but MOST of which are easy. There are other classes of problems where MOST problems are hard.
> Your two sentences "the halting problem is solved routinely" (assuming you mean the latter case, as above) and "this does not invalidate the Halting Theorem" do not logically work.
I agree it sounds illogical, but my phrasing was poor. I meant, if problem instances that arise in real life are easy to solve, yet there is a theorem that states that NOT ALL problems are easy, these two are not mutually exclusive. I agree "routinely solving the halting problem" is an exaggeration on my part.
The algorithm to answer if a program running on a deterministic finite-memory machine is trivial: Run until it either halts or repeats a state. Halting means it halts (duh); repeating a state means it doesn't halt. This algorithm is, of course, not implementable.
Some other people, the born dreamers who are overly motivated and naive by default need experience, need to fail a lot to learn that some things are harder than it seems. (I am more in this category.)
But in reality there is a market for the belief of whether 'they can do that': (angel) investing. If someone bets that people's capabilities are undervalued she should buy into the market (invest in early stage enterpreneurs). If someone bets that people's capabilities are overvalued she should sell (not invest).
Saying 'you can do that' is cheap. If you really trust he/she can do that you invest. I think the market is balanced in Silicon Valley (some say overvalued) and undervalued in some countires where there is virtually no angel investing in technology startups at all. (Like where I live in Eastern Europe.)
Its a big demotivator if you feel like you are being dismissed out of hand. So if you're managing a team or have folks coming to you with new ideas, 'you can't do that' is probably the worst thing you can say to them.
Many years ago, for a course project, she proposed software that would allow you to tag songs and get information about it. Perfect for identifying that obscure song at a bar. The professor told her, flat out, it was impossible. He explained his reasoning and then suggested she work on another project.
All of this came to light when I showed her Shazam. Her first words were "I KNEW IT WAS POSSIBLE!"
The original post is pretty unspecific. Did the professor claim that creating a general system with a large database is impossible? That it's impossible as a term project? That creating a proof of concept system with 3 GB of music from your personal collection is impossible? That simply identifying a song given a part of it and the source file is impossible?
At my first job my whole team had to enter details on a shared spreadsheet. I suggested we set up data-validation or drop down menus for input, someone straight off said 'can't be done - someone tried it last year, didn't work.' then took me like two weeks of campaigning just to overcome this initial knock back. What a waste of time.
Translation: we gave it to an intern and he couldn't do it in a week.
Good, where's my flying car?
Subverting the dedication part using a highly reliable software solution is acceptable (self navigating carplanes).
Once you've got that down you've solved 90% of the flying car problem. IMHO of course.
EDIT: Of course - the real "end run" around the problem would be to answer the question "why do you want a flying car?" and address THAT instead of building a flying car. Would someone want a flying car if teleportation was available? I'm guessing "no".
More in a social context than a technical one, it usually implies "This is my excuse for not doing it"
So I agree! Keep your confidence if you think you've got an idea that may work, especially when there's a bunch of people who have a vested interest in your device not succeeding, telling you that it won't work.
Everytime I think about starting a company or investing in tech, stuff like thinks makes me reconsider.
1) Have problem 2) Find related discussion forum 3) Post problem, state or imply it's probably impossible. 4) Get much more interest and better answers than a plain question would have.
1. I don't want you to do that because of x,y,z.
2. I saw some other people try that, and they failed.
3. Someone else doesn't want you to do that.
4. I tried it, and I failed at it and my ego is tiny.
5. Rule or Law X states you shouldn't do that.
Can't is such an abused word, better to not use it at all to make yourself clear.
When you understand the laws of physics, anything is possible.
Those people just inherited preconceptions from their environment (co-workers, bosses, common knowledge...). Their brain never even tried to wonder if a new approach was possible.
I think this article describes the situation well. At first I was annoyed with them, but then I came to realize that the reason they were saying this was because they didn't understand what I was getting into, and from their perspective it really was impossible.
I have come to appreciate that they are not out to rain on my parade for the sake of being mean, but because they actually do care about me. I suppose that as with all criticism, discernment is needed.