Is it project fraud or saving the client? | Hacker News Reader

Is it project fraud or saving the client?

screamingatmyscreen.com

Why do we even ask this question?

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.

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.

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.

Definitely fraud.

  Fraud consists of five elements:

  The making of a false statement;
  With knowledge that the statement is false or with reckless disregard as to whether or not the statement is false or true;
  With the intent that the listener rely on the statement;
  With the result that the listener relies on the statement;
  With the consequence that the listener is harmed.

He's just missing the last part: proving he was harmed. This might come later when he tries to hire someone to maintain the app; or when he finds he can't outsource the hosting of the app; or he can't integrate it with some other software he needs; or some other problem because the developer didn't use RoR.

http://contracts.uslegal.com/fraud/

Are you a lawyer? Do you know at all what is necessary to prove the black letter elements of fraud in the jurisdiction where the contract between the dev/client originated? Are you licensed to practice there?

No? Well then it seems by saying that it's definite fraud, you've made a false statement with reckless disregard as to whether or not it's true, with the intent that someone reading these comments would rely on your statement and form a conclusion which would negatively impact and defame the developer in question here.

Now of course what I'm suggesting is ridiculous, but no more than your completely unfounded statement that this situation is "definitely fraud." You don't know what you're talking about, your URL citation makes that inherently clear to anyone who does and it's just unnecessary to comment like this.

I did forget the obligatory IANAL. Good catch.

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.

The biggest fix is to have good communication--clients should be willing to explain why they want a particular framework ("I can find Rails devs more easily than x"), and providers must explain why 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.").

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?

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.

Why even risk it? Why do you even care what language it is THAT much? It's not your project.

I can understand why you would care about what language it is. But there's nothing wrong with charging more to work in a language you dislike; you just have to be upfront about that.

You care about the language SO MUCH that you would be willing to risk developing the app for free, or worse free + real damages + punitive damages (for fraud)?

There's no language that I love so much that I would risk a lawsuit over it.

I don't know, Lua is pretty nice.

Of course not. I totally agree that you need to have client approval over what you end up using. But my point is that if the client wants you to use a language that takes you longer, or that you are miserable to use, you can reflect that in your quote.

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.'.

Coding in Sinatra over Rails won't make you ill. What are the implications when the only apparent downside is that a non-technical person is getting the product in a different framework than he wanted?

I think that it's simply a matter of getting what you believe you paid for. The implication of an alternative choice may not be clear to the contractor, but it might be important to the non-technical person (even if they don't specifically know what the technology is).

Perhaps the non-technical person had a trusted friend who is a Ruby on Rails expert -- and this person was not available at the time of initial development, but available later to maintain the app?

he might hire someone to maintain it based on their rails experience, for example.

Follow on development, and available talent pool.

You wrote a super fast OLTP system in forth? Great! You're a god, but no one can support it or extend it to meet future needs.

Perhaps Bob had reasonable expectations that he'd be able to organically grow this app over time. Not being technical he chose a platform which seemed to have a pool of talent available to him.

In the small, this was a trivial technical decision. In the large, business picture, that decision might have major negative effects. Bob should have been consulted, and had the decisions explained to him.

On the other hand, Bob could have explained his longer term intent to his subordinate and allowed her to make a reasonable decision as long as the tradeoffs were communicated back to him.

As somebody else has mentioned - if the customer wants to modify the application later on after the initial contract has ended, and looks for somebody experienced in what they believe they had initially been sold, then that is a costly process, both in terms of time and money.

We don't work in a bubble - our decisions have impacts long after we've ended our own contract with clients. Clients should be given exactly what they're expecting. If you think the client should go a different route, then you should explain that to the client, and document exactly what the final product will be.

Even if the difference doesn't make you 'ill', it is simply unethical to sell somebody something they're not expecting - whether you believe it's better or not.

Legal actions would only be possible if a spoken wish, which is not part of the written contract, can be used as a basis for a lawsuit in Germany. I know that it was "only spoken", but I do not know the legal possibilities we have here.

Most oral contracts can be enforced in most countries, including Germany. It might be hard to establish that it was part of the contract. For example, if you spend a lot of time negotiating a contract, and both parties put a bunch of stuff into the text during the negotiation, then it might appear that anything discussed orally but not written down is not part of the contract.

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.

In general I think you're right, but in this case, most Rails devs can probably maintain a Sinatra codebase.

Do you believe someone able to maintain Rails code in a sufficient way would have trouble maintaining Sinatra code after reading the documentation? IMHO this is the strong point of Sinatra. You do not have much magic going on. Reading the docs and looking at the code should be everything you need to understand what is going on.

(In this case the code is well documented and from a technical point of view below CRUD.)

Well in this instance it looks like he lied to his client.

But as a broader point, how much information should you be giving your clients about technical decisions?

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.

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.

> But as a broader point, how much information should you be giving your clients about technical decisions?

I explicitly list the technologies I use for a project. Let's say a webapp: Django (Python 2.7), HTML5, CSS3 (SaSS), JavaScript (jQuery) together with two short sentences explaining that the (to the time of development) current versions of the libraries will be used.

From this point there are two possibilities: The client has objections or doesn't care. If there are objections it is likely from someone who will maintain the code. If he doesn't care I wasted 4 lines.

I once had a client which was convinced by his nephew (he recently started studying CS, so he obviously knew what he was talking about) that I did everything wrong using Django, I should have used Node.js. Even a discussion if I would have to rewrite everything in node emerged.

I prefer to explain to my client what I will use and put it in the contract. Those 4 lines saved me a lot of trouble.

This seems like a sensible approach, I will be more thorough in future. I assume you also inform the client if you change your mind about a minor library?

I only had to change libraries because the client changed the specs of a project. In this case he receives an updated list. (We once were asked to integrate something which required us to add some JS libraries for faster development)

Minor version updates are communicated with the sysops if they exist. If we host the project there is no extra information.

+ 1 , i explicitly list ALL THE STACK i'm going to use and make the clients sign the list.

It's fraud. No if, ands or buts.

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.

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.

> If I was the client I would be furious.

What if everything has turned out great for the client and he loves the result? Is it fraud if you "harm" someone, but they don't care?

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

Could you please send me a screenshot and the device you are using so I can take a look at the problem? Email is timo@obviousDomain thanks :)

When the browser window is relatively narrow, the scrollbars only scroll the text area, not the humongous left-hand pane with nothing of interest except your "about me".

Verified on Firefox, Chrome, and Opera.

Currently I expect a browser window to be at least 950px width on the desktop. I only change to designs for lower resolutions on mobile devices.

I am not entirely sure how common it is, but it should be a small fix and won't hurt to support smaller resolutions on the desktop as well. Thanks for the feedback.

Zoom is also disabled, makes it hard to read on mobile.

The problem I see, after receiving a screenshot from a Nexus 7, is that the responsive breakpoints seem to be ignored on some devices.

On mobile devices there shouldn't be a fixed sidebar. The content should use the whole screen with ~45 characters / line.

https://dl.dropbox.com/u/388004/sams%20mobile.png

I just sent you two Android screenshots. The first is how I saw your site when I wrote the post here - the part you can't see on the screenshot is that the black square covers the content regardless of how you scroll that content.

I had a surprise when I powered the phone back up (having left your site in the browser when it powered down). The second screenshot shows what happened after that power-up. I'll assume that when it re-rendered, it used a different media type ... or that you somehow caught it after the fact? I guess I'm also assuming this is how the mobile site is supposed to look (scrolled all the way to the top).

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.

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?

Reply on news.ycombinator.com