
Dear Client, Here’s Why That Change Took So Long - jetheredge
https://www.simplethread.com/dear-client-heres-why-that-change-took-so-long/
======
commandlinefan
What gets me is that software has been a mainstay of modern business for _at
least_ 30 years. And this whole time, every single professional software
developer has been telling every single non-software developer the exact same
thing, over and over: this takes longer to do than you think. If, say, 80% of
developers were knocking things out, problem free, in an hour or two and the
other 20% were hanging back like a 50’s union boss saying, “yeah, that’s going
to be an all-day job easy”, then maybe I could understand why they STILL think
we’re lying. Even if 20% of the devs could get things done in the time they
seem to think it takes and the other 80% were hemming and hawing I could still
understand this perspective. But that’s not the ratio. 0% of devs can reliably
complete tasks in the time that MBA’s seem to think it should take and 100% of
devs take longer than they “wish” it would take and THEY STILL AREN’T PAYING
ATTENTION.

~~~
noego
On the flip side, I've seen far too many teams move at the speed of molasses,
for reasons unrelated to the intrinsic complexity of the problem. Bureaucracy,
analysis paralysis, no automated testing, accidental complexity, tech debt,
poor retention of experienced developers, poor compensation resulting in sub-
par hires, insufficient training and mentoring for new hires etc etc. I
wouldn't be so quick to assume that every single development team is operating
at their most ideal.

~~~
irq11
I’m dealing with this right now. A team that is downright arrogant about
reducing their well-padded schedule, taking _months_ to do a job that should
take weeks, at most. Getting them to do _anything_ is like pulling teeth, and
accompanied with lots of arrogant lectures about how hard it is to estimate,
how you can’t rush quality, and so on.

It’s mostly bullshit. This team has historical reasons for their bloated
schedules, but at root, they’ve simply been coddled, and never forced to
justify their behavior.

I’ve been on both sides of the table now. Developers like to gripe and moan
about “unrealistic” schedules, but without aggressive pushback from
management, a huge number of programmers will simply never ship.

~~~
throwaway55554
Sounds like a hiring problem. Start hiring some new devs and keep them
separate so as to not contaminate them. As they come up to speed, let one of
the other devs go. Wash, rinse and repeat.

Note: I'm a dev and I can tell you I very much dislike working with prima
donnas.

~~~
megablast
Oh yes, keep them separate from the people who know the application, how it
works, what it integrated with, all the codes, all the issues. Brilliant!

~~~
throwaway55554
Right!?

------
jmilloy
The idea is sound, but this letter is truly surprising to me. Instead of a
succinct summary of what goes into the change, we get a long-winded narrative
that reads to me as full of excuses. I think a more useful email would be a
breakdown of the time actually spent, and a proposal for improvement,
something closer to this (obviously sent after the feature has been deployed,
and obviously including additional items for documentation, code review,
whatever else takes time in your development process):

    
    
      Summary
       - 0.5 hours investigation and planning
       - 0.5 hours feature development
       - 4.5 hours manually testing
       - 0.5 hours deployment
       
      Proposal
       - 8 additional hours now adding automated testing
    

Obviously, depending on your client, they may prefer a more verbose format or
need some more explanation, but probably 3-6 sentences at most.

~~~
jshowa3
Do you think a housing contractor is "making excuses" when they apply the
rationale requesting to take down a wall in the house by saying: 1) we need to
investigate the condition 2) check if its load bearing 3) check if it runs
electrical or plumbing 4) check if it is to code

No, they're telling you the rationale of what goes into making a change. I
agree that this isn't something you should send to clients. But, even sending
a summary to someone who invokes this question will ask the same thing for any
item you summarize. The next question will be, "Why does it take 4.5 hours to
manually test?"

So, explaining the rationale, at least once, will help the customer understand
the process and could contest specific elements rather than trying to hide it
in vagueness.

~~~
jmilloy
Really, I don't think that the developer is "making excuses" here. Which makes
it all the more unfortunate that the letter as written _sounds_ like excuses.

> The next question will be, "Why does it take 4.5 hours to manually test?"

I'm not sure it will. In my experience, clients are usually surprised about
how long something takes not because they think specific tasks are taking too
long, but because they aren't really aware of what the tasks are nor of their
tradeoffs.

"You're right, it took longer than expected. I chose to spent some time
setting up automated tests. That took extra time now, but will save much more
time later."

------
thaumaturgy
No client would ever read this, and much of the language in it wouldn't make
sense to the kind of client that most needs the explanation.

You're better off avoiding getting to this point in the first place. Maintain
a good relationship with cooperative clients and they won't (usually)
complain, because they value your work. You should fire uncooperative clients
and let them be someone else's headache, when possible.

Adding a little more detail to line items in invoices helps a lot too. "Fix
bug report #493" should usually be, "Investigate report of incorrect discount
calculation (#493), modify 1 file, review code, deploy to test, test for
regressions (all tests passed), deploy to production."

It seems dumb and repetitive to us, but one of those descriptions looks like 4
hours' work to the person approving the invoice, and the other doesn't.

------
unreal37
I worked in software development within companies for 20+ years. The "why does
it take so long" conversation has come up a lot.

So on one hand, I see the argument. Simply opening unknown code, and making a
change no matter how small, is a risky game. You need to research the impacts,
test, and walk slowly through a deployment you haven'y done in ages. I totally
get that.

But I also see the other side. Why DOES it take 8 hours to do a simple one-
line code change? That's ridiculous. Somehow, we've developed these fragile
systems. We've trapped ourselves in processes that add 7 hours to any change
we make, no matter how small.

The status quo does not need to remain. It should be easier to make small
changes. It should be cheaper to respond to simple requests. The client is
actually right to question us when they just want an email to appear a day
earlier and it costs them $1500.

~~~
rafiki6
I'm not sure what companies you've worked with, but the answers to your
questions are very easy and come with experience. There's a universe of
testable things. You'll never have 100% coverage (this is a software
development law). Even if you were to do everything right, and build
incredible automated deployment and testing systems, at best you'll end up
reducing but never entirely eliminating fragility. To even get to that level
of perfection would require a tremendous amount of overhead and time that most
enterprises don't want to invest in the systems they build.

It's akin to trying to constantly remodel/add additions to a building. You may
decide that you want new floors, but when you tear up the carpet you realize
there's tons of water damage that was being covered.

------
raiflip
It seems like most of the comments here either didn't read or missed the point
of the article. Yes, this is a simple change. Yes, pushing a fix out in a day
is actually pretty fast. But the author using a simple example to illustrate a
point. Better than taking a complex example that takes 5 paragraphs to
explain. Moreover you can easily extrapolate all the parameters in the article
for complex examples.

The primary point of the article is that there are very common inefficiencies
in our industry that, if we tackled responsibly, would greatly reduce the turn
around time of producing changes to the code base.

The point I took away the most from is how much having a single point of
change for a single concept and periodically cleaning the code base to keep it
this way can dramatically increase productivity.

~~~
ghostly_s
I read the whole thing, and if the author was trying to use this as a simple
example to illustrator a more general point, they did not communicate that
effectively.

~~~
barking
I agree, I thought it both overly long-winded and unclear. If I were the guy
he was addressing I'd suspect he was flannelling me.

~~~
munk-a
There were a bunch of corollary questions about user scenarios that came up
when I was trying to read it. I think it was a poor way to write it out - go
through an actual real world issue, touch on the problems you foresaw and
those you missed and the costs all of those totaled to, it's far more
interesting.

------
droithomme
When the customer demands a written explanation of exactly why a small change
took 4 hours, an engineer has to investigate that completely and write up an
analysis in language and sufficient detail for the customer to understand. The
given letter would take me a couple hours to revise and get the wording just
right and diplomatic. Since the customer is challenging the billing and there
is the subtext of fraud, the letter needs to be approved by management and
reviewed by legal. The engineer and others are also taken off other tasks to
work on this letter project. Providing a legally sound and technically
accurate letter of this nature likely costs around $1000 to provide, plus lost
opportunity cost.

~~~
zoomablemind
Exactly! When requests like this start popping in, it signals some ongoing
distrust or latent disagreement between devs and the client.

If I were that client, a response of that kind would rather infuriate me as
mudding the "clear" picture I see.

I believe, in this case, there's a bigger issue to address - the issue of
trust and responsibilities. If client's expectations about how things should
be done overpower his understanding of what the devs do, then
projects/contract assessments probably missed the target audience. To realign
such expectations the team needs more than just a bark back email.

------
toddsiegel
I do not think that is a good email for discussing a single, small feature. No
client is going to want to read it. It's too long and detailed (1855 words!)
and will probably only _increase_ their frustration.

It is a good idea to discuss with stakeholders, at a high level, why things
_seem_ to take long, but I find that works best as a conversation. No one
wants a tome like this in their inbox.

~~~
Loughla
To speak popular manager jargon.

There are some 2D conversations that are necessary. Dates, times, places. That
sort of thing.

This is solidly 3D communication. It needs to absolutely be face to face.
Otherwise the receiving person on that e-mail will (a) not read it, and (b)
take it as a passive aggressive way to get out of work.

Oh, and (c) look at the length and complete unnecessary detail of that email
that should be a meeting as another reason to accuse you of wasting time.

------
ghostly_s
I'm not a dev, but this feels like arguing with a strawman. There are really
customers who complain that a change to their codebase took _a single day_ to
implement? I would be utterly thrilled if I could get a vendor to turn around
anything that quickly

~~~
Raphmedia
I've worked in a web agency that billed by the hour.

Clients would ask for justification on why something would take 5h of support
instead of 2.5h because the previous similar request was done in half the time
during the development of the app.

What they don't understand[1] is that if they ask for an _urgent_ fix after
deployment, they're going to pay for a developer that had free time this very
moment to pull and install the project. That dev then need to read and
understand the codebase, make the fix, test it, make a pull request, ask for
someone else's billable time to approve the pull requests, merge any
conflicts, schedule a release, push the release, test again and document the
new feature. And that's if the request is in fact as simple as it look like.

Often, requests look very similar but are very different to each other. "Why
does it takes 3 hours to add a button on the sidebar while it takes 1 hour to
do it in the content of the FAQ page?" Well, one is done by the content team
and require no code or release. The other needs to be done in the code. Etc.

[1] They are told in very simple words that this is how it works.

~~~
adrianmsmith
> Often, requests look very similar but are very different to each other. "Why
> does it takes 3 hours to add a button on the sidebar while it takes 1 hour
> to do it in the content of the FAQ page?"

There is a good XKCD on this topic:
[https://xkcd.com/1425/](https://xkcd.com/1425/)

------
munk-a
This simple change and the recommended fix has another issue that this post
missed or dismissed as a non-issue. What if the deadline is pushed back after
the email reminder is sent? Do some users rely entirely on the email reminders
and might they need a followup email saying "Just kidding, actually you've got
more time" \- assuming you resolve that question, when the due date comes up
again should you send another email? What should happen (with these daily
emails) if a task is pushed back an hour without pushing it out of the 24 hr
bound? What should happen if it does push it out of the 24 hr bound but just
by a little bit? Should we encode some sort of grace period of ignoring the
change? If a due date is scheduled and due to go out immediately should we
allow a grace period for canceling it?

The technical questions behind why a change takes a long time are legion, but
so are the UX changes that all need to be accounted for. In software there is
no intelligent actor that can solve edge cases you missed when they come up,
instead you're building a system that will handle all of those cases (maybe by
occasionally crashing, granted) so user stories need to be vetted and
resolved.

~~~
aeorgnoieang
The post covered that, tho not the specific details you mention.

~~~
munk-a
That's why I mentioned it, actually taking the time to see what a change can
effect itself takes time, and if changes are pushed through in an hour then no
one is stopping to think about what systems you might be breaking.

------
projektfu
Too much protest here. I feel you'd be eventually judged on those numbers as
well. Are you a time & materials shop? The fact is that you either start a
clock when you start working on something and stop it when it's done or you
have standard times that things should take (like an auto shop does.) If
you're working efficiently, you can tell your client that you work efficiently
and this is simply how long the change took. If you're procrastinating and
charging the client for the time, you should fix that.

~~~
stronglikedan
I don't think four hours is unreasonable for any type of shop (with 4-8 being
CYA estimating). One or more resources likely have to do most of the steps
below.

* Document the customer request

* Investigate the customer request

* Create and document the requirement

* Assign the task

* Switch current context

* Deploy a dev environment

* Make the change

* Submit the change to QC

* Test the change

* Deploy the change

* Clean up dev environment

* Document the change

* Bill the customer

Ideally, you would encourage the customer to bundle multiple requests, so that
most of the tasks could be shared among them. However, if they insist that
they need it now, then they need to pay accordingly.

This story seems like it could be solved with improved up-front communication.

~~~
projektfu
Totally agree it's a reasonable time. I think that it's a waste of time to
argue why it takes time to do your work. You'd only write that letter because
you feel bad about charging your client for your time.

A better letter if you wanted to write one would be about the benefits you
provide and the completeness of your work. I wouldn't even mention the time it
takes.

~~~
SketchySeaBeast
If you're charging T&M money, and the client comes back with "why does it cost
that much?", what would you suggest? Assuming burning the bridge isn't an
option.

~~~
munk-a
Itemize the bill, break it down relentlessly into tiny components and show how
long different facets tied to the feature build took, ideally pin some of the
time on them if it's appropriate ("Remember when you guys were a bit wobbly on
the background color, well we had quite a few meetings and dev was tied up
while we were talking, it ended up taking us about three hours between those
two hour meetings and then an additional thirty minutes to redo the change
three times - thankfully we held off on testing until we'd all gotten on the
same page.")

The more explanation you get out there the better, if you're honest (or a good
faker) people will be reassured by your explanations - but accept that not all
clients are profitable ventures, a customer who can't pay for the time it'll
take isn't one you should take on, just try and leave things in an amiable
state.

~~~
SketchySeaBeast
> Totally agree it's a reasonable time. I think that it's a waste of time to
> argue why it takes time to do your work. You'd only write that letter
> because you feel bad about charging your client for your time. > A better
> letter if you wanted to write one would be about the benefits you provide
> and the completeness of your work. I wouldn't even mention the time it
> takes.

I understand your response, but the (grand?) parent seems to be indicating you
don't do that, and just explain that you do good work.

------
Townley
My favorite idea here is how it's a developer's job to articulate the issues
with a client's code base to the clients themselves. Some clients just want
the problem to go away, but smart ones recognize the importance of a high-
level understanding of the state of their code base.

If you work for a cheapskate who's just nickel and diming about billable
hours, the "Why does this take so long" question is nothing more than the
rhetorical whining of a bad client. But in a healthy client-developer
relationship, the question is important. It's a less-articulated, unfamiliar
version of the following, which any good developer would find amiable:

"I, as someone invested in the success of my company, am seeking insight into
a part of that success that only you have. I trust that you're not playing
Minesweeper on our dime, and yet our current process isn't delivering the
returns we expect. As someone who knows better than I do, are my expectations
unreasonable and in need of adjustment, or are there investments that can be
made to get us there?

------
nocman
I believe I understand what the author of this post is trying to accomplish,
but for virtually every "client" I have ever worked for, their eyes would have
glazed over by the time they'd read 25% of this response (if they could even
get that far).

It is worth it to try to help your client understand why seemingly simple
changes take a long time to implement. I'd just be surprised if the written
response in this post would be of much help to most clients.

The face-to-face has a much better shot at being helpful, but, of course, that
depends a great deal on the client also.

------
bshimmin
Part 4: learn to bill by the day and never again have to worry about
justifying how long a simple-sounding code change took to make.

~~~
SketchySeaBeast
So would you bundle up a series of these into a day? Or just assume the client
is cool with this taking a day?

I believe you're also assuming you're servicing a client whose got a lot of
budget to blow on a lot of small changes.

~~~
titanomachy
Servicing a client with a very tight budget is a colossal pain. It might be
inevitable early in your career but try to get past it as soon as you can. If
your client has more time than money they will waste a lot of your time
quibbling over price.

The best clients have more money than time and will pay you well to make their
problems disappear. They pay you to think about the software for them, so they
can spend their valuable time thinking about the business instead.

~~~
SketchySeaBeast
Yeah, I need to develop comfort enough to become a contractor - at the moment
as an employee it means you go wherever they tell you.

------
ozim
"Of course, you can’t just deploy a change to production without, at least,
running it locally or on a test server to make sure the code executes
correctly"

Dear client of course we can, just prepare for commits in history: "That
simple fix" 6h ago "Fix the fix" 3h ago "Really fix" 1,5h ago "Really really
fix the fix" 10min ago

If all goes well enough, we won't have to craft "Customer data fix" SQL query
commit the next day, just because someone forgot about that totally hidden
stored procedure that was not included in the "Really fix". Which takes
another 6 hours to prepare on next business day and invoice instead of being
3-4h of proper fix for "one liner" turns into bill for 12 hours and 2 days of
lost production time.

Yours, humble developer.

------
Udik
To me the main concern is that this shouldn't even be a _code_ change: this
stuff should be a matter of configuration. In a well-written system the dev
time for it should be zero.

But in general, the whole letter feels wrong: either the complications of such
a trivial change depend entirely on legacy code that isn't responsibility of
the current maintainer, and therefore the client knows well how hard and
expensive even simple changes are (and this should have been made clear when
the project started); or the maintainer is asking the client to pay for
developments (refactorings, tests, or a different, more general implementation
of the feature) that weren't agreed beforehand.

~~~
aeorgnoieang
I've actually come around to the opposite conclusion over the course of my
career: everything should be hard-coded by default (tho using a well-named
variable/constant/identifier). Making data-driven (e.g. configuration data
driven) code is always more work and, unless you have strong evidence
otherwise, [You Aren't Gonna Need
It]([https://martinfowler.com/bliki/Yagni.html](https://martinfowler.com/bliki/Yagni.html)).

------
jvagner
> Changing the tasks due email to be delivered a day earlier should be a one-
> line change. How could that take 4-8 hours?

This is what's in dispute? Something else in the relationship is wrong.

------
brlewis
On the flip side, when a change _doesn 't_ take long to implement because of a
successful campaign waged against technical debt, it's important to
communicate that to the stakeholder too, even though they won't ask. I
implemented such a change on Friday afternoon and made sure to talk about why
it went well at sprint review and at sprint retro.

------
bobm_kite9
Our internal model of the world is always simpler than the world itself
(otherwise it wouldn't be a model).

This whole article is just saying "Dear client, here's why your model is
insufficient".

Which is a much nicer email to write than "Dear client, here's why my model
was insufficient". Which is what happens when the estimates go south

~~~
jmilloy
I'd almost argue that, in the example, the clients model wasn't insufficient.
If you want to include "implement automated testing" in a small feature
request without telling your clien, then your client is probably right to be
surprised!

~~~
Qwertystop
Perhaps I misread it, but I think the only testing being included was for the
specific change. The bit at the end was "if we had the time to do a lot of
general refactoring and testing not tied to the particular feature being done
right now it would save time in the future".

------
cromulent
Software development is magic to most people. You have the same laptop as
them, and somehow you make stuff that works and makes them money by flexing
your fingers.

They don't know how to internalize that - they are dealing with a magician
that turns dirt into gold and gets paid by the hour.

It's totally irrational. If you were a plumber then there would be a physical
manifestation of the work.

Software managers who have never written code are also often suspect, in my
opinion. They can be professionals of magic management without understanding,
liking, or even appreciating their field.

------
deanalevitt
I'm a non-technical founder who generally doesn't bug my team about why a
change took so long but that's because they communicate with me.

Thing is, working with a developer as a non-technical team member can be a
frustrating, opaque experience. Communicating progress is eye-opening for non-
technical colleagues but when a programmer does not communicate, then
obviously the non-technical members have no idea what's going on.

Developers can forget too, that the one small change might be holding up
marketing, sales and customer support, all of whom themselves are getting
flack from above about why X customer is still angry, or why the press release
isn't being sent out yet etc. "Waiting on a dev" isn't an answer that reflects
well on anyone.

The "Dear Client" letter wouldn't be necessary if there was more
communication. It can even be automated. Here's what I see in a Slack channel
with my colleagues:

github APP [8:52 PM] New branch "fix-password-recovery" was pushed by xxxx
[yyyyyy] Pull request submitted by xxxx #466 Improve password recovery • Fix
styling • Ensure the visitor is signed out of all sessions • Redirect to sign
in instead of 404 when an old recovery link is visited

semaphore APP [9:05 PM] xxxx's build passed — d61157d Improve password
recovery on fix-password-recovery

I never need to doubt xxxx when I can see the myriad small tasks, failed
builds, the commits etc.

~~~
megablast
> Thing is, working with a developer as a non-technical team member can be a
> frustrating, opaque experience.

And vice-versa. Imagine knowing something very well, something quite
complicated. Then not only knowing how to fix that issue, but explain it to a
child. Now, constantly having to handhold that child over every step, even
when they don't even need to know, and it is slowing you down having to do
that. And maybe not even knowing the solution, but trying different things,
and having to explain each to that child.

What you have setup sounds awful. Learn the technical side, or let them get on
with the job. The updates you need should be at a daily standup.

> then obviously the non-technical members have no idea what's going on.

You still don't know what is going on, you just pretend you do.

> Developers can forget too, that the one small change might be holding up
> marketing, sales and customer support

Then make this clear during standup.

------
yebyen
> we always include time for writing automated tests in our estimates. It can
> slow down initial development, but it greatly improves the efficiency of
> operating and maintaining a software system. It isn’t until a system grows
> that you truly start to feel the pain of not having tests, and by that point
> it can be a monumental task to work tests back into the system

Not only this, but also: I've recently come to understand the idea that
allocating enough time for writing unit tests and integration tests, tends to
uncover design issues. If a test is taking longer to write than it seems like
it should, or if a particular method or bit of functionality seems harder to
test than it was to write, that is a signal that you may have a design issue!

Writing the automated tests will help you find out when you have written some
code that stinks, if you know what to look for and have the time to step back
and think about it. It's called "Red/Green/Refactor" for a reason, it's not
"Red/Green/Red/Green/Red/Green" – if your estimates only allocate enough time
to write the feature and nominally prove that it works, you're missing a
critical part of the TDD pattern and you're not getting nearly as much long-
term value out of your tests as you could.

If you don't write automated tests at all, it's even worse, because those
design issues will only show themselves when it's time to make a change, and
your bad design is now standing in the way, preventing you from iterating
quickly when you really need it.

------
jrochkind1
> but it could provide a benefit that greatly reduces the effort to make a
> similar change in the future.

Even worse, if we _don 't_ invest that time, the effort to make a similar
change in the future will keep _increasing_. We need to invest that time just
to keep it from getting _worse_.

------
WheelsAtLarge
Software programming and maintenance is mainly a mind game. The change
requestor won't see you taking out a bunch of tools to get ready and they
won't see you make the changes. It's hard for them to see why changes take the
time they take. Also the time it takes to modify code is relative to the
codebase, your understanding of it and the changes needed. I've had
situation's when I've made changes in minutes but other changes have taken
days. There's no way to standardize code change. Other professions can set a
time on changes because there's been plenty of past data that can be
referenced.

So given this, it is reasonable for requestors to feel like a change should be
immediate because it seems simple relative to the way they themselves make
changes when they need to. They are trying to use their past experience to
come up with the time it should take to make a small change. So many things
seem easy when you don't have the right experience.

The only way to counter this is to define very specifically why it will take a
day vs whatever time they think it should take to make the changes. Even then
it's a hard sell since the requestor will feel that a lot of what you are
doing is a waste of time which in their mind equals a waste of money since
time is money in business. This is how things have been, are, and will be.

I think part of a programmers training should include how to deal with
customers since we all have had to deal with this situation and will continue
to do so. It's part of being a programmer for hire.

------
namelosw
I work on a project consists of tens of devs that continuously delivered
applications for almost a decade, and I joined this team 3 yrs ago. At some
peaks, there were almost a hundred people. We still continuously deliver new
features to the project every day.

We bill by hours as a lot of people suggest in this thread. Which works pretty
well. We also have flexible iteration plans, the clients can prioritize any
feature that is important to them. If a feature does not worth it, it will
likely stay in backlog forever.

Most things are really smooth IMO, though explaining why technical stuff is
costly/mandatory is really hard to deal with. Because both of us want the
project to be an ever-green project, we need technical advancement,
architectural extensibilities. It's so hard to even convince myself if I
considered myself a non-technical person. Why do you need to split into
services? Why things are not immediately synchronized after the splitting? Why
do you need a job here, and what's a job exactly?

At the end of the day, it seems when you are convincing people about things
they've no idea, you really need to be trusted -- just like you kind of trust
doctor, and being suspicious about witch doctors. To achieve this, it seems
better first to be business-focused and solving problems to build trust and
reputation, as some kind of credits.

------
lowercased
> I know that investments like this can be hard to make, precisely because
> there aren’t any new visible rewards

Taken individually yes, there's no new 'visible' reward.

Looking at the larger picture, say, 3 months from now, changes that used to
take 3 days now take 3 hours, and there are fewer outages, reduced downtime,
higher uptime, and fewer (or no) hair-on-fire-we-lost-customers issues any
longer.

Establishing both short term metrics (request turnaround time) and long term
metrics (uptime, data loss, security breaches, customer satisfaction, team
satisfaction, employee retention, etc) will help understand justification of
effort.

------
tomcam
That's an excellent set of explanations. One way to forestall most of them is
the magic phrase "change order".

Anytime you get into a conversation where the customers starts off with "Can't
you just..." then it's your responsibility to let them know a change order
needs to be filed so you can estimate the new impacts it will have, including
cost.

Some of the excellent techniques in OP's article will be employed, but "change
order" terminology and workflow minimize these requirements after you've
stepped them through the change order workflow once or twice.

------
revskill
A good software system should be understandable and modified by junior
developers.

That's why most of "advanced patterns" doesn't work in real world.

Simple, clean, boring code is what a productive programmers should follow.

------
ww520
Even with 6 to 8 hours for the change, it's far too short. This is not a code
change. This is a business process change. The ramafication is far greater
than one line change.

------
neves
Nice. I also like this similar version from Microsoft:

How many Microsoft employees does it take to change a lightbulb?
[https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-...](https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-
many-microsoft-employees-does-it-take-to-change-a-lightbulb/)

------
te_platt
My last two projects have been for the military and a medical device. The
example here seems so wonderfully simple (even as an example of how much has
to happen on a simple change). Add in all the process/design/QA/validation
documents that need to be created -> passed off -> executed -> recorded and
you are at much longer than a day.

------
supernova87a
Well, despite all the protestations that the letter tries to surface, some of
which are legitimate -- sometimes it really is:

"We did not design our system to make simple changes simple, and are now
paying the price for it in the gap of we can deliver versus what our customers
intuitively believe and should expect as response time for simple changes."

------
zghst
Mostly during my career, giving the technical explanation to the PM, they are
appropriately able to pushback and get the client calm and reasonable, only
when the one thing that took long that's now taking longer, that's when it
gets tedious...

------
donarb
I call the the “one little button syndrome”, where a client thinks that just
adding one little button to a web page should take a few minutes. They don’t
realize that that one little button may require a whole bunch of code to
support on the backend.

------
jermaustin1
> Actively clean a codebase

I've worked for a lot of customers as a developer, I can count on 0 hands the
number of times "actively cleaning the code base" would have approved by a
stakeholder, especially if there is a budget assigned to the project.

------
jshowa3
This post is amazing. I try to explain this all the time. Reminds me of a
previous post on HN where people were defending bosses condescending questions
of "why does X take so long?"

------
jorblumesea
Part of the issue is just the siloed nature of many businesses. The business
team has no idea what engineers actually do. Marketing just thinks it's like
editing a complex word document. The clients you're working with have never
interacted deeply with their own internal dev team. Their interface is always
a customer facing position.

Getting engineering to understand the business side and the business side to
understand how engineering works would go far in clearing up many
misconceptions and allowing things such as tech debt paydown, cleanups and
refactors, etc.

------
megous
While some of that may be true, it feels ridiculous/inappropriate as a
response. The customer doesn't want a disertation about programming/support
practices. The customer wants something made cheaper.

That can be satisfied to a large degree. You can just as well tell the
customer: "OK, I'll do the obvious chnage, if something else breaks, we'll fix
it later. It seems likely all will be fine. Ok?"

Some customers will be ok with that. And you'll bill for 30mins or whatever
and everyone's happy.

~~~
gnulinux
This doesn't make sense. If you're selling a product, the quality of your
product shouldn't be customized/determined by your customer. Your customer
should pay you to get the product with the described quality. If you never
test your code and do 4-8 our changes in 30mins, in a year your codebase will
be write-only mess.

~~~
megous
I'm not selling a product. I'm selling a service. And cost of that is
determined by the service level.

At the "I change it you test it" level, it can be pretty cheap and fast.

------
crikli
Good lord, tl,dr. And I'm a dev. Client sure as hell wouldn't read all that.
And I know this because at the start of my career I wrote those kind of long-
winded explanations before I realized that nobody was reading them.

Brevity is a virtue.

"Dear client, the change itself took very little time but making sure that
this change did not have unintended ripple effects took a lot more. We are
careful and deliberate when deploying changes to your production application
because in this mission critical application, downtime and errors are not
acceptable. If you'd like more detail I can provide it during our next
regularly scheduled catch-up."

------
chiefalchemist
> "In other words, spending 1/2 day to a full day (4-8hrs) on this task is
> roughly 2x-4x the effort..."

My personal rule of thumb is: It either takes 1 minute, 1 hour, 2 hours, 4
hours, or 8 hours. Or obviously longer, but for the back of the envelope type
of things these tiers work.

There's no 3 hours or 5 hours. Nothing ever take 3 or 5 hours. Perhaps
sometimes 6 but at that point - due to distractions and side fires - it's a
full day. Call it 8 and stop kidding yourself.

------
ashelmire
Dear developers and other readers (megous, jmilloy, thaumaturgy),

This is probably not a real email to a client or meant to sound like one. Stop
responding to it like that's what this is (and perhaps also, remember that
satire and social criticism exist). It IS meant to highlight one of the common
problems of software development for interested readers.

------
rusanu
How many Microsoft employees does it take to change a lightbulb?

[https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-...](https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-
many-microsoft-employees-does-it-take-to-change-a-lightbulb/)

------
amelius
Just send them a git diff ...

------
utopcell
Chances are, it would had taken me 4 hours to compile that response alone.

------
breatheoften
It takes at least 2-3 hours just to write that letter to the client ...

------
jldugger
Quick survey for folks:

How long does it take to push a spelling fix out to customers?

