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.
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):<p><pre><code> 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
</code></pre>
Obviously, depending on your client, they may prefer a more verbose format or need some more explanation, but probably 3-6 sentences at most.
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.<p>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.<p>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."<p>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.
I worked in software development within companies for 20+ years. The "why does it take so long" conversation has come up a lot.<p>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.<p>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.<p>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.
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.<p>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.<p>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.
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.
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.<p>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.
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 <i>a single day</i> to implement? I would be utterly thrilled if I could get a vendor to turn around anything that quickly
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?<p>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.
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.
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.<p>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:<p>"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?
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).<p>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.<p>The face-to-face has a much better shot at being helpful, but, of course, that depends a great deal on the client also.
"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"<p>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<p>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.<p>Yours,
humble developer.
To me the main concern is that this shouldn't even be a <i>code</i> change: this stuff should be a matter of configuration. In a well-written system the dev time for it should be zero.<p>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.
> Changing the tasks due email to be delivered a day earlier should be a one-line change. How could that take 4-8 hours?<p>This is what's in dispute? Something else in the relationship is wrong.
On the flip side, when a change <i>doesn't</i> 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.
Our internal model of the world is always simpler than the world itself (otherwise it wouldn't be a model).<p>This whole article is just saying "Dear client, here's why your model is insufficient".<p>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
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.<p>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.<p>It's totally irrational. If you were a plumber then there would be a physical manifestation of the work.<p>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.
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.<p>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.<p>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.<p>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:<p>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<p>semaphore APP [9:05 PM]
xxxx's build passed — d61157d Improve password recovery on fix-password-recovery<p>I never need to doubt xxxx when I can see the myriad small tasks, failed builds, the commits etc.
> 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<p>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!<p>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.<p>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.
> but it could provide a benefit that greatly reduces the effort to make a similar change in the future.<p>Even worse, if we <i>don't</i> invest that time, the effort to make a similar change in the future will keep <i>increasing</i>. We need to invest that time just to keep it from getting <i>worse</i>.
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.<p>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.<p>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.<p>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.
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.<p>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.<p>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?<p>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.
> I know that investments like this can be hard to make, precisely because there aren’t any new visible rewards<p>Taken individually yes, there's no new 'visible' reward.<p>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.<p>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.
That's an excellent set of explanations. One way to forestall most of them is the magic phrase "change order".<p>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.<p>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.
A good software system should be understandable and modified by junior developers.<p>That's why most of "advanced patterns" doesn't work in real world.<p>Simple, clean, boring code is what a productive programmers should follow.
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.
Nice. I also like this similar version from Microsoft:<p>How many Microsoft employees does it take to change a lightbulb?
<a href="https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-many-microsoft-employees-does-it-take-to-change-a-lightbulb/" rel="nofollow">https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-...</a>
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.
Well, despite all the protestations that the letter tries to surface, some of which are legitimate -- sometimes it really is:<p>"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."
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...
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.
> Actively clean a codebase<p>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.
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?"
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.<p>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.
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.<p>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?"<p>Some customers will be ok with that. And you'll bill for 30mins or whatever and everyone's happy.
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.<p>Brevity is a virtue.<p>"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."
> "In other words, spending 1/2 day to a full day (4-8hrs) on this task is roughly 2x-4x the effort..."<p>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.<p>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.
Dear developers and other readers (megous, jmilloy, thaumaturgy),<p>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.
How many Microsoft employees does it take to change a lightbulb?<p><a href="https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-many-microsoft-employees-does-it-take-to-change-a-lightbulb/" rel="nofollow">https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-...</a>