3

I work in a software company where we have many projects for different clients.

We are facing the problem that some of the software is built on an old framework (Rails 3.2). Now, the customer has paid for making some new features to the project. The question arrises on upgrading the framework (at least to Rails 4.2, last version is 5), or just work with the software the customer has paid for. Our options (how I see it) are:

  • Try to convince the customer to paid for a framework update. It's pretty hard since they won't see any change, but it's easier to maintain. If the customer doesn't want to pay, this means to work with the old framework.
  • Update the framework and count it as a mandatory fee for "touching" the project.

This is important not only for this project, but a guideline for future projects. Should we allow to have outdated projects? This is quite annoying for developers. On the other hand, update the framework can be pricy as well.

Improve this question

3 Answers 3

Reset to default
2

I am making an assumption here, that your client owns the software you have built for them. If that is the case, you don't get to make the decisions about what work should be done in the software, they do. Deciding to make platform changes to suit your developers and your organisation and then expecting them to pick up the bill for that is plain wrong.

Change to the underlying software platform, to keep it in line with best practise, currently supported software etc. etc. should be covered in a support and maintenance agreement with the client. This will usually take the form that they agree to pay a fixed annual support fee and you agree to keep their software working and current.

Improve this answer
2
  • I disagree w.r.t. the client deciding what technical steps have to be performed to be able to deliver a new release. Not only that, but many clients wouldn't know what you're talking about. They hire you to get a job done, and the job is to provide software support for their processes. That said, large upgrades can sometimes dwarf costs of feature implementation so there might have to be a discussion, but if they refuse upgrading, then you have to decide if you want to work with an e.g. 10 year old, deprecated technology for just a bit more money to be able to get it out the door or pull out.
    – Tomislav Nakic-Alfirevic
    Sep 6, 2016 at 13:34
  • 2
    No-one said anything about the client defining or understanding steps to achieve a technical upgrade. You have put up a straw man argument. The client gets to make the decision on whether their software is upgraded or not, end of story. Whether they then accept a quote or estimate is neither here nor there, nor is it relevant whether the supplier chooses to continue to support deprecated software or not. That comes later. The point is whether the supplier may unilaterally decide to make changes and then stick the client with the bill. That is wrong.
    – Marv Mills
    Sep 7, 2016 at 16:45
1

The Client is coming to you to solve a problem, and if you have already committed to the work then it is disingenuous for you to want them to update their framework just to make your developers' lives easier, especially if there will be no value added to them, and just an extra expense - I'd tell you guys to pound sand.

The only way it would even be okay to approach the Client would be if the updated Framework added a great bit of functionality, had future uses, and you commit to an upkeep period that is cost-effective to them, and letting them know that you can probably complete other small projects faster may convince them to go ahead with the upgrade.

To avoid that problem in the future, add a maintenance period into your contracts - that for a set amount of time after Production, the client agrees to pay a flat rate and agrees to having upgrades done as they become available, as well as regular support, then everybody wins. You have to forward think these things - software is capricious, and languages are always updating.

Improve this answer
1

I've been in similar situations. My experience has been that when you talk about it, customers usually have at least an intuitive understanding of the issue, but will look for any way to avoid the announced cost. They have been working with you for years, have gotten accustomed to a certain rhythm of deliveries, have a feel for how much something costs and now you drop this bomb saying "we'll need 10x more money which will give you no new features and quite likely introduce regressions": they don't want anything to do with it, right? At the same time, things are blowing up in your face as fewer and fewer people in the larger community are able to help you troubleshoot obscure issues, documentation is hard to find and you basically break deadline after deadline, bleeding money all of the way.

From where I stand, there are a few options. You can try to argue that this kind of work doesn't happen often, but cannot be avoided and makes future work more efficient/cheap/productive. If these are key customers, you can offer a discount for the work or even subsidize it in order to protect your employees' sanity and prevent an oncoming exodus of developers fed up with having to use technologies today's graduates haven't even heard of.

If that fails, there are really two things you can try and do. One is to plod on on the current platform and charge significantly more as a kind of compensation for the added risk, frustration and ever more frequent technical issues no one on-line knows anything about any more.

Finally, if all of the above fails, you're basically stuck in a project you can't get a profit on, so you can only offer to hand it over to a vendor of their choice for future work, but will have nothing more to do with it.

Improve this answer
1
  • 1
    An alternative approach is to understand in advance that this can happen and build your agreements with the client to offer a future maintenance service to keep their system running, taking into account platform upgrades and enhancements. If they decline to enter such an agreement they then cannot complain when the service begins to falter, however if they accept you have a professional approach to ongoing maintenance and an agreed budget for doing the work. In my experience this is how professional software organisations deal with this issue.
    – Marv Mills
    Sep 7, 2016 at 20:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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