Is it project fraud or saving the client?

Why do we even ask this question?<p>How do we feel when people figure they know better than us and makes decisions on our behalf? Hopefully we don't experience this to often after we grow up (except by our governments ; ) and we shouldn't do it to anyone else.<p>And: What if the developer WAS mistaken? The client was smarter than he thought, just didn't tell the dev about future plans because of business secrets? If the developer makes decisions behind the customers back I'd also be fair for him to be prepared to pay the customer if it turns out that Rails was in fact needed (3.rd party integration etc.)

I would say its fraud. It completely ignores what the client is asking for. Although unlikely in this example there may be other reasons they pick that technology that you're not aware of.<p>If I hire a contractor for to put in lead pipes and I get copper pipes that's fraud. Lead is bad and its my job to help them, but if they insist I can either do the job or leave. For all I know maybe they need lead cause they are a lab and the lead does something for them.

It's your responsibility to clear technological changes with the client, or at least mention them. If the client never states a preference, use your own judgment.<p>The biggest fix is to have good communication--clients should be willing to explain <i>why</i> they want a particular framework ("I can find Rails devs more easily than x"), and providers must explain <i>why</i> they want to go against stated preferences ("This is a really, really dumb API endpoint. Sinatra is the simplest way of getting there from here.").<p>If people won't be open, well, that's when bad things happen.

A client hired you to specifically write an app in Ruby on Rails, and you decided to use something different?<p>I hope he is prepared for: 1) the possibility that the client will refuse to pay; or 2) sue him later, if he finds Sinatra cost more to maintain than RoR or finds he has to have it redeveloped because he really did need RoR.<p>Why even risk it? Why do you even care what language it is THAT much? It's not your project.

I don't think it's 'fraud', but it's definitely unethical and I wouldn't be surprised if there was some kind of legal action that could be taken. If I ask for a gluten free meal, and I don't get a gluten free meal, and that makes me ill, then the person who sold me that meal shouldn't be allowed to just say 'What's the problem? Gluten free meals aren't as nice.'.

One of the considerations when choosing a framework is how difficult it is to implement in the first place, but another consideration is how widely adopted it is. It's a lot harder to find someone who can maintain Sinatra code than someone who can maintain Rails code.

Well in this instance it looks like he lied to his client.<p>But as a broader point, how much information should you be giving your clients about technical decisions?<p>I mean, RoR is rails is omakase so there's a bunch of stuff you could change around to make it quite a different framework. Like switching the template library or ORM around. This might make it difficult if they had a second developer in mind to pick up the project in the future if they are not familiar with these.<p>I've had situations in the past where I've developed software with PHP5 and taken advantage of the features and then had clients who got annoyed when they tried to migrate to a cheaper web host who only supported PHP4 and not PDO etc.

It's fraud. No if, ands or buts.<p>The client hired you to do X then you should do X. You can suggest to do Y and if the client clears it then you do Y, but only if the client tells you to do Y. If I was the client I would be furious. If the client or I want to shoot ourselves in the foot by building the project on framework A or language B then it is our right to do that.<p>One thing that separates a good programmer from a great programmer is to recommend technologies and explain why, but no matter what you build what your told to. A great programmer will warn me and explain why, but if that programmer is told to do it anyways then they damn well better do it as they were told.

On Android, this site does make you want to scream at your screen.

Like anything like this, the answer is: what did the contract say? If the developer delivered what was laid out in the contract, it's not fraud. If the client really need RoR for some reason unknown to the developer, it should have been specified in the contract.<p>Now, it still isn't a good idea to substitute frameworks, but without it being contractually agreed upon, it would be hard to argue fraud.

So when the client hires a full time developer who understands Ruby on Rails but doesn't understand Sinatra, then what happens?