[andybak]

Tricky one. I've just had to sell my clients on an update from Django < 1.8 as that fell out of it's support period.

"Hey folks. I've got to do lots of work that will result in no new visible functionality and I'd like to be paid for it"

I did consider slipping a Python 3 upgrade in there at the same time but there are limits to my powers of persuasion.

So - Python 3 will have to wait.

[jsmeaton]

I don't do this kind of work (agency) but I find it strange that ongoing maintenance isn't discussed and priced into the statement of work right from the beginning.

Something like 2 days maintenance every 9 months to stay current, or 4 days every 2-3 years to go from LTS to LTS. If a customer doesn't understand why they need to be paying maintenance every x months or years, isn't that your fault for not making that clear in the beginning? Sorry if it seems like I'm picking on you, but I've seen this kind of comment quite a lot, and I've never asked the question before.

[andybak]

I actually agree and I should factor that in more.

However for many reasons it's often tricky:

1. This is something you have to address in the initial stages of a client relationship and with price-sensitive clients unused to software development if you're not careful it can sound like you're just rent-seeking.

2. 'Big but infrequent' changes are difficult to cost. Django LTS upgrades are every 5 years. Breaking changes like Python 2 to 3 are even rarer. What figure would I have proposed during the sales process that would have correctly covered me for these? I'm almost certain I would have significantly underestimated.

3. It's not always clear if you're entering into a long-term relationship with the client. They might expect the website to be completely replaced in a year or so, they might be intending to bring development in-house or various other things that make 'saving for a rainy day' a tricky proposition.

[cowsandmilk]

> 3. It's not always clear if you're entering into a long-term relationship with the client.

I've also found that clients will often be acquired, go through management changes, etc that make having these things built in become unstable. One of my clients was acquired by Merck, then Merck sent a letter saying they were terminating all contracts. 18 months later, I get a frantic e-mail from some low-level people asking why I was no longer updating things for them.

The median life of many companies makes building in release->release upgrade support difficult in practice.

[collinmanderson]

I personally charge my clients with a flat monthly maintenance fee which includes upgrades, but also minor bug fixes. In some ways it's a guarantee that the website will keep running, though without an actual SLA. It means I don't need to spend time selling the client on the upgrade.

1. Yes. I always put the on-going fee in the initial project estimate, so there's no surprises.

2. Yes, it requires some guess-work. I've also found that it saves time to take one feature migration (like removing django's url patterns() function) and making that change to all projects at the same time (rather than making all the upgrades to one project at once). I also have found it helpful to reduce the number of 3rd party dependencies. (Fewer things to upgrade, and fewer things that may potentially stop getting supported.)

(Also "Django LTS upgrades are every 5 years" - I was going to correct that to 2 years, but I suppose you can completely skip an LTS line if you time it just right (like, jump from 1.8 directly to 2.0). But you still need to upgrade every _4_ years. Right?)

3. Yes, it's something to figure out initially.

[jsmeaton]

Thanks for the response. I forget sometimes that not all customers are reasonable.

[MyNameIsFred]

I'm coming from the Java world, but as a consultant for enterprise customers, I'll say that they only understand two kinds of ongoing maintenance: 1. Dollars over time (e.g. licenses) 2. Purpose-specific hire (i.e. hire a guy to do nothing but support this new thing between now and forever)

In other words, they understand continuous maintenance, but not continual maintenance. Anything else is either too awkward to write on a budget. If you suggest that it needs periodic review, they'll think you just need to "do it right the first time, so this isn't an issue going forward", whether or not that makes any sense.

[cuu508]

How about car oil changes for an analogy? You could probably drive for several oil change periods without apparent issues, until eventually there would be big issues. Django upgrades are similar, not "that" difficult, and it's a good idea not to fall too far back in versions, running into more and more incompatibilities. Py 2 -> 3 is a bigger one, so maybe like a timing belt change? ;-)