8

My client and I agreed on an architectural design for an android application, which included the MySQL database. The application has been released, and has grossed a good number of users and data. The client is suddenly asking me to modify the back-end and use Firebase instead of MySQL because he talked to someone from Google who suggested Firebase would be better.

The client has a notion that integrating Firebase is a very simple task. How can I make the client understand that completely changing the back-end is not a minor enhancement or bug fix, and that this will take some time to implement and incur an extra cost? I'd like to politely explain these facts as there is a string chance of me securing another project from them which I am particularly interested in doing. Please offer your suggestions.

  • 11
    Send him a quote with step by step changes that need to be made. Include expected time on each step and the cost of it. Preface it that due to those changes needing to be made it can't be considered a bug fix as functionality is working correctly. – Snowlockk Jun 14 '17 at 9:01
  • 1
    I'd rather not spend my time making a detailed quote for a project which may not happen. – Philip Kendall Jun 14 '17 at 9:43
  • 4
    The solution here couldn't be simpler, just state "That would involve completely redoing the project from the ground up". Couldn't be simpler to explain. And yes, don't do custom backends anymore :) Just use ably, firebase, pubnub or whatever – Fattie Jun 14 '17 at 10:55
  • 1
    I think the main issue here would be "why is somebody that doesn't have a clue about it request a big change like that ?". If this guy is a business guy, you're probably in the best position to make technical choices, and I would be assuming you did the best ones you could. If this guy is an IT guy, it shouldn't be that complicated to make him understand... In any cases, using analogies might help : "it's not like painting a wall a different color, it's like re-wiring all your electric installation built-in in the walls" or something like that. – Laurent S. Jun 14 '17 at 10:55
  • 1
    Note that you could say, the title here is essentially wrong. When you dump having a backend, and move to a BAAS, so as to avoid having a backend, that is incredibly different from "backend changes". "backend changes" are (merely!) something like totally changing the DB, hosting, middleware of the like. you're not "changing" your backend, you're completely eliminating the idea of having a backend, and going with a BAAS/PAAS/SAAS ("whatever") instead of having a backend! – Fattie Jun 14 '17 at 14:06
19

Just tell them the facts.

Hi.

Unfortunately, using Firebase isn't a simple change to the project and would involve a significant amount of rework of the architecture. As a very rough estimate, I think it would take about <some number> of weeks of effort. Shall we have a call to discuss further?

I suspect the answer here would then be "OK, don't worry about it then" but you never know.

  • 2
    The only thing I would add is a caveat, like: "At this point I am not conviced the change would add any significant benefit over the existing solution". – Fredrik Jun 14 '17 at 10:42
  • 2
    @Fattie The OP could also try using an analogy like that. "Currently, our system is a Porche. You're asking me to transform it into a Ferrari. This is going to be more than a simple oil change - we're effectively rebuilding the whole machine from the wheels up." – Steve-O Jun 14 '17 at 13:45
  • @Fattie - if changing your storage engine (even from mysql to nosql) is a "complete redo", then you haven't designed separation of concerns into your software very well. – HorusKol Jun 15 '17 at 1:24
  • @Fredrik, No, I disagree. Do not add "At this point, I am not convinced the change would add any significant benefit over the existing solution". You do not want to get sucked up into a debate. Quote your price. Let the client decide whether that price is worth it or not. He will most likely say "no". If he says "yes", then ask him what perceived benefits he thinks are worth that much, but I really doubt that he'll say "yes". – Stephan Branczyk Jun 15 '17 at 6:57
3

By their nature the back-end elements of systems are essentially invisible to customers/end-users and as such they often have difficulty comprehending the amount of complexity and work that goes into them. It's not their fault, and it's up to devs like you and me to help them bridge that gap and put it in to terms that they can relate to. Metaphors are good for this, especially if you can use them to show the differences between a "bug fix" type change and a more significant change such as the one they are talking about. The exact one to use depends on the person you are talking to but likening it to things like changing a tyre (bug fix) vs a full engine change (changing to firebase) on a car , or replacing a window (bug fix) vs structural work on a buildings foundations (firebase) is the kind of thing that I'm talking about. This coupled with a reasonably detailed estimate/breakdown of the work involved should give you the best chance of them understanding

As a slight side note it sounds like you aren't convinced that the change offers any real value (or at least not enough to justify the work involved), if so I'd say it's worth explaining the pros/cons of the change, say that you are happy to do the work if they want but that you aren't sure it will give them value for money.

  • I'd liken it to changing the material used to construct a bridge, compared to fixing a pothole found on the bridge. – schizoid04 Jun 14 '17 at 22:40
  • I think he should just point to a free course on Udacity on "Firebase essentials for Android" made by Google. If that course doesn't get across the complexity of the task, I'm not sure what will. classroom.udacity.com/courses/ud009 – Stephan Branczyk Jun 15 '17 at 7:37
3

I'd say that ultimately, helping your client understand the complete technical scope of the desired change is not your problem. This actually sounds more like you haven't instituted a very good change-control process in your past interactions with the client, i.e:

  • You're on a fixed price contract
  • You've allowed the scope of the project to creep repeatedly in the past
  • It's unlikely that you've been paid in "milestones", preferring maybe a deposit in the beginning and a big lump of money in the end.

If you've "trained" your client to believe that scope creep is a freebie, you shouldn't be surprised one bit at this stage. I've seen lots of situations where the client holds the final payment as a hostage over large last-minute changes, and it's not fair to the developer at all but many developers tolerate such behavior out of (innocent) ignorance.

Don't worry about project #2, because honestly you can go over to the 'Computer Gigs' section on Craigslist in any major city and see how many parties are trying -- daily -- to get work done for free with promises of additional work later. It's a very common hustle.

Be more concerned about this client not trying to get over on you for project #1. Set your price, and stick to it. I recommend you charge hourly, because beside your code changes, the client is also going to expect you to migrate the existing data to Firebase. Develop a written scope-of-work document, and have your client sign to it before you start any work. This step cuts down on misunderstandings later.

1

I assume you have a contract with the client.

For this change to come through you need a new contract bnecause it's work not covered by the initial agreement.

So to communicate that this is not a trivial thing, make him an offer where you specify the hours needed and a price for your work.

That's the best way to communicate this.

1

I would put together a detailed Estimate including all the tasks that would need to be done and the hours to do them and the overall cost. Don't forget the cost of moving the existing data to the new data source. As a guess I would estimate this to be several thousand hours of work, but you need to be much more specific than that, show them what needs to be done and what each major task of this would take.

I also would include a risk analysis describing the risk of introducing new bugs, the lack of data integrity, the chance that some data would be lost in transferring to the new database, etc.

Once you present it, either they will pay you a large amount of money to make the change or you will never hear of it again.

1

There is a very simple rule - the customer is always right. As long as the customer pays.

The cost is: Migrating all your data from MySQL to Firebase (without losing anything). Updating the client software. Convince all the end users to update their applications - that's a tricky one, because end users hate that kind of thing and you will have losses.

Updating the client software is most non-trivial. You will move from a well-tested application to something that is again in an alpha state. You will be moving from a standard and tested environment to a proprietary solution. There is cost involved, Firebase is not free and depending on what you are doing, it might not be cheap. And from things I read here and there on the internet, Firebase is easy for simple things but can turn into a nightmare when you go over the limits. MySQL will be here five years, ten years, 20 years from now. No guarantee with Firebase. Firebase will change whenever Google feels like changing it.

Finally, what is his source for his information? He talked to someone from Google? Firebase is a Google product. Of course someone from Google will praise it to high heavens.

So you will make an estimate for this "simple" change. The estimate will be based on your estimates, not on the clients opinion. If he thinks your estimate is too high, you can offer him as an alternative to do this work, paid for every day of actual work. You are most certainly not going to do it based on his low estimate. Tell him that you are a professional software developer, and you know better than a Google salesman.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.