Am I nuts or is this charge for app support absurd?
December 22, 2017 12:46 PM Subscribe
8 hours and counting of code "re-familiarization" with nothing to show for it.
I’m the business owner/analyst for a webapp/db used by my workgroup. It’s hosted and supported by an internal service; within the same large institution, but a different division, so organizationally distant. I get along fine with the programmer who’s supported the app the past 2+ years. He is, however, at least the third one assigned to it since its creation about 10 years ago, so its’ not his code.
I put in a request recently to change the content of a couple of dropdown menus. After some brief clarification on the spec and a couple of weeks, we got an invoice for 8+ hours of work, though the menus themselves hadn’t changed. When I asked, he said he still needed more time to “re-familiarize” himself with the code, so I fully expect there’s more invoices to come. This is looking like thousands of $$ for what I’d categorize as an administrative change.
I’ve been in and around IT and software development for many years. I get that the code isn’t his and it’s probably a mess under the hood. But this is absurd! A request like this can’t turn into a blank check.
Have any of you had a similar experience? Stories and advice appreciated. Thanks and hope your holidays are safe and happy!
I’m the business owner/analyst for a webapp/db used by my workgroup. It’s hosted and supported by an internal service; within the same large institution, but a different division, so organizationally distant. I get along fine with the programmer who’s supported the app the past 2+ years. He is, however, at least the third one assigned to it since its creation about 10 years ago, so its’ not his code.
I put in a request recently to change the content of a couple of dropdown menus. After some brief clarification on the spec and a couple of weeks, we got an invoice for 8+ hours of work, though the menus themselves hadn’t changed. When I asked, he said he still needed more time to “re-familiarize” himself with the code, so I fully expect there’s more invoices to come. This is looking like thousands of $$ for what I’d categorize as an administrative change.
I’ve been in and around IT and software development for many years. I get that the code isn’t his and it’s probably a mess under the hood. But this is absurd! A request like this can’t turn into a blank check.
Have any of you had a similar experience? Stories and advice appreciated. Thanks and hope your holidays are safe and happy!
Is there an estimate built into the process?
posted by chesty_a_arthur at 12:59 PM on December 22, 2017 [1 favorite]
posted by chesty_a_arthur at 12:59 PM on December 22, 2017 [1 favorite]
I have not worked in a setting where I bill for my hours, so I don't know what the standard practices are there. But as far as actual work time, eight hours to re-familiarize myself with a codebase I haven't spent much time in (especially if it's ten years old!) seems normal to me if any substantive work is involved. I'm not sure what "change the content of a couple of dropdown menus" means, but if you're adding new menu items (which presumably need some kind of functionality behind them) or changing the behavior of existing menu items, I don't think this amount of time is unreasonable.
The usual way to avoid the "blank check" problem is to get an estimate so that you can do a cost/benefit analysis before prioritizing the work. If you can't get an estimate (or don't trust it), you can time-box the change.
posted by enn at 12:59 PM on December 22, 2017 [11 favorites]
The usual way to avoid the "blank check" problem is to get an estimate so that you can do a cost/benefit analysis before prioritizing the work. If you can't get an estimate (or don't trust it), you can time-box the change.
posted by enn at 12:59 PM on December 22, 2017 [11 favorites]
The cost isn't about the change. It's paying someone to know how to find out what to change. There's a joke that I'm butchering about a developer who charges $5010 a client to change a single line of code. The client is outraged. The programmer replies that the cost is $5000 to know what line to change, and $10 to make the change.
Not only does the programmer need to figure out what they need to change to meet the request, they need to test their change, make sure it doesn't add any additional bugs, re-build and deploy the app, etc etc.
Obviously there could be some shenanigans, but if this guy is the only one who can do the work, you're at his mercy. If you can get it cheaper, by all means try. But as a senior webdev with over 15 years experience and who manages ~10 devs, I don't think this is completely out of the ballpark at all. One day to look at the code is nothing if it's even remotely complicated. I wouIdn't even blink if one on my devs gave me this estimate for an unfamiliar area of the code base. I have my own projects that I wrote several years ago and it would take me more than a day to get back up to speed to solve what might seem like trivial issues to non-dev types.
Also - only 3 devs in 10 years?!!? That's an amazingly low turnover rate. And any 10 year old code is most likely going to be an amazing mess of horribleness.
posted by cgg at 1:12 PM on December 22, 2017 [8 favorites]
Not only does the programmer need to figure out what they need to change to meet the request, they need to test their change, make sure it doesn't add any additional bugs, re-build and deploy the app, etc etc.
Obviously there could be some shenanigans, but if this guy is the only one who can do the work, you're at his mercy. If you can get it cheaper, by all means try. But as a senior webdev with over 15 years experience and who manages ~10 devs, I don't think this is completely out of the ballpark at all. One day to look at the code is nothing if it's even remotely complicated. I wouIdn't even blink if one on my devs gave me this estimate for an unfamiliar area of the code base. I have my own projects that I wrote several years ago and it would take me more than a day to get back up to speed to solve what might seem like trivial issues to non-dev types.
Also - only 3 devs in 10 years?!!? That's an amazingly low turnover rate. And any 10 year old code is most likely going to be an amazing mess of horribleness.
posted by cgg at 1:12 PM on December 22, 2017 [8 favorites]
Response by poster: Obligatory Dilberts always appreciated.
chesty_a_arthur: No estimate in the current process. That's going to be part of my response, though, thanks.
enn: I totally get the difficulty of legacy code. But this has been in his portfolio for over 2 years, and there have been other support requests. Some were small (like I thought this was) and resolved reasonably quickly. Others were larger and sucked up all the $$ for updating underlying components and didn't actually get to the requested changes. So, admittedly, there's some frustrating history behind all this.
This may just all be another reminder of the eternal truth of Hofstadter's Law.
posted by sapere aude at 1:23 PM on December 22, 2017 [1 favorite]
chesty_a_arthur: No estimate in the current process. That's going to be part of my response, though, thanks.
enn: I totally get the difficulty of legacy code. But this has been in his portfolio for over 2 years, and there have been other support requests. Some were small (like I thought this was) and resolved reasonably quickly. Others were larger and sucked up all the $$ for updating underlying components and didn't actually get to the requested changes. So, admittedly, there's some frustrating history behind all this.
This may just all be another reminder of the eternal truth of Hofstadter's Law.
posted by sapere aude at 1:23 PM on December 22, 2017 [1 favorite]
Best answer: This happens to me, or has the potential to happen to me, all the time (as the person asked to make "a quick change"). The way to keep this from happening is to agree on an initial boundary of time. "If this is going to take more than 45 minutes let me know before going any further" or similar. Or state the request and ask for an estimate and scope before you approve the work - they may come back and say they need an hour of discovery time, or four hours, or whatever, but at least it gets discussed before the work begins.
posted by Lyn Never at 2:19 PM on December 22, 2017 [2 favorites]
posted by Lyn Never at 2:19 PM on December 22, 2017 [2 favorites]
How organizationally distant? At this point I'd give him another hour to work on it, then escalate to his manager, or have your manager do that. I was the BA for an internal team and my manager would get Very Stern Complaints if we didn't deliver in a reasonable time period. There was the implied threat of escalating further, which worked 99% of the time if the delay was within our control.
posted by AFABulous at 2:38 PM on December 22, 2017
posted by AFABulous at 2:38 PM on December 22, 2017
It depends on so many things because web apps have become increasingly complicated and obscure. For example, if the initial menu was set up via a plugin, addon or other prepackaged solution, it’s possible there are some limitations to it that means your changes now need to be custom, and the developer needs to figure out how it’s working and if it’s worth modifying what’s there, finding something new, or starting over.
As an example, I remember a meeting at an old job where the vp was frustrated that we needed a backend developer’s help to make every other line of a table an alternate color. Because it was something that just was not supported in raw html/css at the time. But his only frame of reference was excel and word. It doesn’t surprise me at all to hear a “simple” change is requiring a lot of additional work, including investigating it.
posted by [insert clever name here] at 2:47 PM on December 22, 2017 [1 favorite]
As an example, I remember a meeting at an old job where the vp was frustrated that we needed a backend developer’s help to make every other line of a table an alternate color. Because it was something that just was not supported in raw html/css at the time. But his only frame of reference was excel and word. It doesn’t surprise me at all to hear a “simple” change is requiring a lot of additional work, including investigating it.
posted by [insert clever name here] at 2:47 PM on December 22, 2017 [1 favorite]
Could this be a product of the how the organisation records time spent? I've worked in large companies which generally expected you to bill your time to a project. If projects are thin on the ground right now, the programmer might be billing a lot of time to you because you're the only external thing available to bill to right now.
Saying that, software is a can of worms within which small changes can escalate very quickly. I've spent countless days (and weeks!) working on things which on the face of it seemed like quick changes.
posted by leo_r at 3:28 PM on December 22, 2017 [1 favorite]
Saying that, software is a can of worms within which small changes can escalate very quickly. I've spent countless days (and weeks!) working on things which on the face of it seemed like quick changes.
posted by leo_r at 3:28 PM on December 22, 2017 [1 favorite]
Sometimes that's a good sign. Person A spends a fair amount of time understanding what exists already, comes up with an efficient plan of attack, executes quickly, tests, fixes minor issues, delivers. Person B jumps right in doing the "obvious", runs into unexpected problems, starts over, blunders through, tests, spends a long time fixing trickier bugs, eventually delivers (but leaves it more of a mess than it was before). I'll take A.
On the other hand, Person C is a perfectionist and can't stop themselves from "optimizing" and "refactoring". Person D just does the thing I asked for, even if it's a quick and dirty hack. That's sometimes a tougher choice. Sometimes D necessarily means B.
Person E just wants to pad billable hours. Do not want.
Like others have said, the key is communication and estimating. Which person do you want? Does the developer understand which person they're supposed to be?
posted by ctmf at 4:55 PM on December 22, 2017 [1 favorite]
On the other hand, Person C is a perfectionist and can't stop themselves from "optimizing" and "refactoring". Person D just does the thing I asked for, even if it's a quick and dirty hack. That's sometimes a tougher choice. Sometimes D necessarily means B.
Person E just wants to pad billable hours. Do not want.
Like others have said, the key is communication and estimating. Which person do you want? Does the developer understand which person they're supposed to be?
posted by ctmf at 4:55 PM on December 22, 2017 [1 favorite]
I usually charge a 4-6 week discovery period for legacy code so that future estimates are accurate. A day reading a 10 year old code base is not unexpected.
The problem I think is communication. There was likely a weird issue with the menu. In any case most developers I know under bill, but I’ve learned to always produce something for this very issue.
Usually it is a a risk assessment or GAP analysis so non technical stakeholders can see I spend my time doing something. I would not consider this necessarily malicious that he spent a day figuring out a weird issue.
There are programmers as mentioned above who want to make the code their own rather then fixing the problem.
posted by geoff. at 10:52 PM on December 22, 2017
The problem I think is communication. There was likely a weird issue with the menu. In any case most developers I know under bill, but I’ve learned to always produce something for this very issue.
Usually it is a a risk assessment or GAP analysis so non technical stakeholders can see I spend my time doing something. I would not consider this necessarily malicious that he spent a day figuring out a weird issue.
There are programmers as mentioned above who want to make the code their own rather then fixing the problem.
posted by geoff. at 10:52 PM on December 22, 2017
Best answer: pm: how long is this gonna take?
me: i'll let you know in 40 hours.
also...so much code is written to the lowest possible measure of success - feature correctness.
extensibility
tested (unit, integration, ui)
testable
maintainable (written w effective loose coupling approaches)
robust (resilient to unanticipated exceptions)
feature-correct
secure (designed and tested to meet law, policy, regulation, and jesus-don't-do-that-are-you-new)
i would say you have the most common architectural pattern: big ball of mud.
further, i would guess that your org is in the 'pay later' section of 'pay now, or pay later, but you will pay'.
annnnd...it's likely that the high cost of a feature change is in trying to head off unanticipated side effects. this is because the system has non-existent, low-coverage, or ineffective unit tests. good unit tests are hard to write; code needs a small interface, small responsibility, and a testable structure that doesn't cross object, function, or tier boundaries (depending on your design).
so...welcome to 'pay later'. pretty crap, huh?
posted by j_curiouser at 6:54 AM on December 23, 2017 [1 favorite]
me: i'll let you know in 40 hours.
also...so much code is written to the lowest possible measure of success - feature correctness.
extensibility
tested (unit, integration, ui)
testable
maintainable (written w effective loose coupling approaches)
robust (resilient to unanticipated exceptions)
feature-correct
secure (designed and tested to meet law, policy, regulation, and jesus-don't-do-that-are-you-new)
i would say you have the most common architectural pattern: big ball of mud.
further, i would guess that your org is in the 'pay later' section of 'pay now, or pay later, but you will pay'.
annnnd...it's likely that the high cost of a feature change is in trying to head off unanticipated side effects. this is because the system has non-existent, low-coverage, or ineffective unit tests. good unit tests are hard to write; code needs a small interface, small responsibility, and a testable structure that doesn't cross object, function, or tier boundaries (depending on your design).
so...welcome to 'pay later'. pretty crap, huh?
posted by j_curiouser at 6:54 AM on December 23, 2017 [1 favorite]
Best answer: My current job title is Programmer Analyst. I've been various flavors of web developer previously.
If it were me and it was taking that long, I would communicate with the client, letting them know why it's taking so long and how much longer I estimate it might take. After 8+ hours with no visible change, for a request that the vast majority of people would perceive as simple, a generic "have to familiarize myself with the code" no longer seems acceptable.
In what way did you want the menu items changed, just out of curiosity?
posted by nirblegee at 3:48 PM on December 23, 2017
If it were me and it was taking that long, I would communicate with the client, letting them know why it's taking so long and how much longer I estimate it might take. After 8+ hours with no visible change, for a request that the vast majority of people would perceive as simple, a generic "have to familiarize myself with the code" no longer seems acceptable.
In what way did you want the menu items changed, just out of curiosity?
posted by nirblegee at 3:48 PM on December 23, 2017
Response by poster: Thanks for all the great feedback. There's some history I glossed over with the hosting agency, which probably fed my frustration more than the bare facts I laid out above justified. They aren't so distant we can't escalate if needed, so that's an option. I agree that a better process would include better communication early on that the request is looking like a deeper can of worms than expected, and get the OK for x more hours, like what happens with good car mechanics.
The actual request involved a page where filling out fields and dropdowns allowed you to populate a pdf form. The two dropdown menus had dept codes and titles that are obsolete, so I provided new lists as well as a 2nd option of available tables that are updated regularly and could be used with a boolean to mark whether to show on the menus. Another coder with some familiarity with the app estimated 2-3 hours, but he may not know the true horrors under the hood and how hard it is to not mess up old records with obsolete values. Anyway, thanks to everyone for talking me off the ledge. I do think this app is too far underwater with technical debt to renovate, but we need to limp along a little longer with it. Now I just hope I can talk my boss off the ledge as well...
posted by sapere aude at 8:07 PM on December 23, 2017
The actual request involved a page where filling out fields and dropdowns allowed you to populate a pdf form. The two dropdown menus had dept codes and titles that are obsolete, so I provided new lists as well as a 2nd option of available tables that are updated regularly and could be used with a boolean to mark whether to show on the menus. Another coder with some familiarity with the app estimated 2-3 hours, but he may not know the true horrors under the hood and how hard it is to not mess up old records with obsolete values. Anyway, thanks to everyone for talking me off the ledge. I do think this app is too far underwater with technical debt to renovate, but we need to limp along a little longer with it. Now I just hope I can talk my boss off the ledge as well...
posted by sapere aude at 8:07 PM on December 23, 2017
estimate reality check: no single small change comes in at < 4 hours.
and, really, since you don't have unit tests...imagine the investment to have a human physically regression test every application feature after a small mod. yowza.
posted by j_curiouser at 10:04 PM on December 23, 2017
and, really, since you don't have unit tests...imagine the investment to have a human physically regression test every application feature after a small mod. yowza.
posted by j_curiouser at 10:04 PM on December 23, 2017
This thread is closed to new comments.
My point, you seem to be at this developer's mercy. They're the one assigned by management to do the work. You, nor anyone at your disposal, are willing or able to do the work. That's sorta where I see it.
posted by humboldt32 at 12:56 PM on December 22, 2017 [3 favorites]