Hacker News Reader

Comment by run4yourlives | Hacker News Reader

I would love to know the specifics behind this post, because it seems so very, very, wrong.

One of the comments nails it best: unless you are breaking the laws of physics, you can make software do pretty much anything... the real question is whether that is a net benefit.

"They want to use our software or customize things in ways that are technically impossible"

What the hell does that even mean? Perhaps the reason the tech can't communicate to the non-techy is that he can't communicate, period. Does it mean they're using the software for something it wasn't intended to be used for? Are they looking for a feature that isn't coded? Are they looking for support for something you aren't interested in supporting?

Not much is 'technically impossible' when it comes to businesses and software these days. What there are in abundance however are a lot of misguided applications.

View on HN

    "They want to use our software or customize things in ways that are technically impossible"

Maybe there is an unspoken " for the price they are will to pay" component to that statement. I have told customers before that given time, money, and hardware I can do almost anything they want. The real question is are they willing to pay for that time, and hardware to do what they are asking.

There are countless examples of "technically impossible" requests on the daily wtf and clients from hell. A good example is when the client wants you (or your software) to do something that involves access to other companies' infrastructure or to every computer in the world. For example, "make our website the default homepage for everyone." or "remove our competitors' links on Google."

Your examples sound rather easy, relatively speaking, to accomplish technically, but are certainly legally dubious. In fact, it seems most things that are "technically impossible" come down to social issues and not technical issues at all.

Technically and legally / morally acceptable and simple. The financial cost however would be unimaginably spectacular. Simply buy your competitors and shut them down, and create a simple 1e8 price range deal with some well known browser devs to make your page the home page.

Lack of communications ability could be an issue. Oh you didn't REALLY mean everyone's computer in the world you just meant in this office. Oh you mean the top adwords link on google not search results. Well...

Customer: "When I call a customer back I want my blog to mark his comment 'handled' with the date and time."

Engineer: "What phone do you use to call him back on?"

Customer; "The one on my desk."

Customer has a desk phone attached to a Northern Telecom PBX switch that was installed by a VAR (now out of business) but is still maintained by the property owner using a Win95 based laptop.

Generally the phrase "technically impossible" relates to a situation where a customer is asking for a capability which, to implement, requires either that they change their process, or co-operation by a third party. Often times the 'third parties' here are old school, highly invested in walling off their garden types, like AT&T. Often, telling the customer they have to change their processes to achieve what they want is a 'non-starter.' It can be a very frustrating experience.

Old time telco guy here. That's not even technically challenging much less impossible. I can do that for $50K to $75K of hardware worst case. If the trunks are ISDN PRIs just sniff the D channel(s) using a protocol analyzer, all off the shelf stuff, and watch for certain numbers, either his desk DID or an outgoing call to a customer with a currently open blog. Somewhat more old school stuff E/M or groundstart might be cheaper than a ISDN protocol analyzer. Something that old is not using VOIP which is too bad as a sniffer would be pretty cheap for SIP.

Most old stuff like that had a CDR call detail record serial port intended to feed a line printer. The simplest way might be run a serial connection to the CDR.

It may very well come down to the simplest way to do it is install another phone on the guy's desk. Forward his old extension to his new phone and new phone line. If your PBX vendor isn't willing to discuss simply forwarding a number then you've got serious vendor issues... thats not asking for much...

Best response ever!

My pick is that the customer is a moderate sized radiology department using FileMaker as a RIS, and they have asked the engineer to make it talk to a PACS, booking system, distribution system, CT, MRI, PET, x-ray, US etc (all made by different manufacturers), and the engineer is at his wits end. Maybe I see things through work-tinted-glasses.

"I want you to a build a program to see if there are any bugs in the code I write."

We have those, they are called compilers.

"Bugs" are just differences between expected and actual behavior. There is no definitive "right" or "wrong". There is only a matter of correct interpretation.

What you are essentially asking for is for me to eliminate the need for not only your program, but the user using it. That's far from technically impossible; whole industries are built on that idea.

What exactly do you think a compiler is?

Perhaps "practically" impossible is closer to the mark.

There are plenty of things that are literally technically impossible, given the state of current artificial intelligence techniques.

Not much is 'technically impossible' when it comes to businesses and software these days.

Try doing IP multicast on the public Internet.

What, you can't, because the ISPs have disabled it?

Next time try not talking out of your ass.

Using IP multicast is a solution to a problem; and I'm pretty sure the parent comment meant that he could solve any problem given enough time, money, and resources.

It's not like you _have_ to use IP multicast to solve certain classes of broadcasting problems, it's just more helpful.

"It's not like you _have_ to use IP multicast to solve certain classes of broadcasting problems"

Then why did NATO get their own dedicated lines to multicast on? Why don't they run their 100,000 simultaneous user systems without multicast and save that expense?

But OK, we'll pretend you're right about that one. What if someone asks for a job shop scheduler for predictably giving optimal schedules for 300 machines interactively? NP completeness is no problem, right?

Or what if someone asks for an in software modulator for the entire radio spectrum? The non-existence of the necessary hardware is again no problem, right?

Or how about when users asks for just plain contradictory requirements huh? Never happened to you? Because these ones are not just physically impossible but also logically impossible.

The fact is that some things are constrained by engineering. It is also a fact that some non-technical types in positions of authority push back when told "no" because of technical constraints, and ask "Why not?". Attempting to give them a reason is a trap, because they are asking the question as an opening negotiating ploy.

Because these idiots in their ignorance think an engineering constraint is a negotiable item.

I feel very sorry for the engineer in the original post because it sounds like he's stuck in such a rut.

And it's simply infuriating to hear somebody respond to that plight with the nonsense that "in IT anything is possible".

"IP multicast" refers to an implementation detail, not to a product feature. Several other ways exist to implement similar functionality.

Reply on news.ycombinator.com