20 ms·

Dear Client, Here’s Why That Change Took So Long

464 points by jetheredge 7y ago

revskill 7y ago
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.
bshimmin 7y ago
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 7y ago
  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 7y ago
    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.
    - sound1 7y ago
      Great comment!
    - SketchySeaBeast 7y ago
      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.
projektfu 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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.
jvagner 7y ago
> 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.
ghostly_s 7y ago
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
- HEHENE 7y ago
  A day would be incredible. We have a show stopping issue with a vendor's software. Several reports we have to run daily takes 6-12 minutes to run, when it should take seconds at most. I've been communicating with their lead reports developer. The fix is done, tests are written, QA has given it the rubber stamp, but he's simply not allowed to push it to our instance until their next code release on the 22nd. It makes no sense, and it's certainly not how I run our side of things. In the meantime, my users will lose 6-12 hours of productivity this month (15 days, 4 reports, 6-12 minutes each.)
- jrockway 7y ago
  I am guessing they want to pay $50 for 10 minutes of work instead of $2400 for 8 hours of work.
  - paganel 7y ago
    You’re most likely correct and it’s a thing that has bugged me on and off ever since I started realizing that some of us, programmers, are not very well suited to linear working (for a lack of better word) like for examples accountants or lawyers. Sometimes you spend an entire day on trying to fix an issue/bug with no luck, until the following day when all of a sudden a brilliant idea comes to you and you solve everything in 15 minutes. Also, should we bill our clients for the time we spend in the shower? Because for me that’s when most of the “eureka!” moments happen (that and when washing dishes by hand). I don’t know of any solution for this issue, just wanted to point out that this perspective tends to be often ignored when discussing about how to pay for programming work. Also, programming is hard, not so much the languages or the frameworks themselves, but the human relations that any software program ultimately ends up resembling.
commandlinefan 7y ago
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.
- bfdm 7y ago
  There is a small subset of devs that will rush and get the work "done" in the underallocated time. The catch is in, of course, the Definition of Done. This is why we spend time aligning teams on exactly this. Sure I can fire off that one line change and tell you it's done. But, does it work? Is it right? Do you care? Typically this sub-par work is done by inexpensive outsourced development shops being managed by a client rep without the capacity to see through the lies until the project goes sideways in the future. The developers who rushed the work are paid and out of the picture and never have to fix the problem or touch that code again, so they don't care.
  - plausibilities 7y ago
    Handyman Contractor mentality vs Civil Engineer mentality in a nutshell Unfortunately not everyone cares about resilience and certain performance thresholds when it comes to construction, especially when budgets become involved. Some customers will are happy to cheap out for a hack-job remodel in the hopes that they can flip their home and run off before the bagholder realizes they got a lemon.
    - Waterluvian 7y ago
toddsiegel 7y ago
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 7y ago
  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.
- heartbreak 7y ago
  I really doubt this is an actual email sent to a client. Obviously it’s too long.
steve76 7y ago
People in charge complain about the lack of wage inflation. Yet they end people's careers and throw people in prison. People with nothing, trying to make the world better and get through the day. Maybe stop saying how great you are while you burn through other people's lives like firewood with eyes, and start making their failures your failures.
thaumaturgy 7y ago
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.
megous 7y ago
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.
- chris11 7y ago
  > Some customers will be ok with that. I'm not sure I would fully trust that. The client probably won't be happy if bugs from poorly tested code keep coming up. And it sounds like the client might question the dev teams work, if they are currently questioning the team's estimates.
  - megous 7y ago
    They have to be ok with that before the fact. You just have to make sure they understand what it means.
- gnulinux 7y ago
  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 7y ago
    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.
raiflip 7y ago
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 7y ago
  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.
  - raiflip 7y ago
    I thought the following line: "Below we have a letter that we have written variations of numerous times over the years. " made it clear that the letter is not real, and is therefore a semi-fictional example.
  - barking 7y ago
    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 7y ago
      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 7y ago
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 7y ago
  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.
Udik 7y ago
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.
- deleted 7y ago
  [deleted]
- aeorgnoieang 7y ago
  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).
jmilloy 7y ago
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 7y ago
  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 7y ago
    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."
te_platt 7y ago
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.
bobm_kite9 7y ago
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 7y ago
  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 7y ago
    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".
rusanu 7y ago
How many Microsoft employees does it take to change a lightbulb? https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-many-microsoft-employees-does-it-take-to-change-a-lightbulb/ https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-...
jshowa3 7y ago
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?"
munk-a 7y ago
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 7y ago
  The post covered that, tho not the specific details you mention.
  - munk-a 7y ago
    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.
jrochkind1 7y ago
> 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.
amelius 7y ago
Just send them a git diff ...
tomcam 7y ago
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.
jorblumesea 7y ago
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.
- deleted 7y ago
  [deleted]
ashelmire 7y ago
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.
unseenbastiat 7y ago
Buy cheap Viagra Cialis erectile dysfunction pills online: http://goatse.info/ http://goatse.info/
nocman 7y ago
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.
jermaustin1 7y ago
> 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.
lowercased 7y ago
> 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.
ww520 7y ago
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.
unreal37 7y ago
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.
- bobblywobbles 7y ago
  Our needs are complex, and constantly changing. If our needs weren't complex, it would be easier to make a change.
- rafiki6 7y ago
  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.
- notatoad 7y ago
  >But I also see the other side. Why DOES it take 8 hours to do a simple one-line code change? That's ridiculous. you might be right, but if you're not in a position to help make it take less time, that's not a helpful discussion to have. the reality is that it takes that long, and complaining doesn't make it faster. The procedures that take time exist for a reason, and i'm sure in every organization there are opportunities to make the process faster. But when somebody who wants a change says "why does it take that long", they aren't looking for helpful ways to improve the process, they're looking for an exception to the process be made so their specific change gets out faster.
Townley 7y ago
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?
yebyen 7y ago
> 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.
zghst 7y ago
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...
deanalevitt 7y ago
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 7y ago
  > 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.
donarb 7y ago
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.
breatheoften 7y ago
It takes at least 2-3 hours just to write that letter to the client ...
supernova87a 7y ago
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."
brlewis 7y ago
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.
ozim 7y ago
"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.
neves 7y ago
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-many-microsoft-employees-does-it-take-to-change-a-lightbulb/ https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-...
cromulent 7y ago
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.
jldugger 7y ago
Quick survey for folks: How long does it take to push a spelling fix out to customers?
crikli 7y ago
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 7y ago
> "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.
utopcell 7y ago
Chances are, it would had taken me 4 hours to compile that response alone.
WheelsAtLarge 7y ago
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 7y ago
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.

464 points by jetheredge 7y ago

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.

bshimmin 7y ago

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 7y ago
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 7y ago
  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.
  - sound1 7y ago
    Great comment!
  - SketchySeaBeast 7y ago
    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.

projektfu 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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.

jvagner 7y ago

> 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.

ghostly_s 7y ago

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

HEHENE 7y ago
A day would be incredible. We have a show stopping issue with a vendor's software. Several reports we have to run daily takes 6-12 minutes to run, when it should take seconds at most. I've been communicating with their lead reports developer. The fix is done, tests are written, QA has given it the rubber stamp, but he's simply not allowed to push it to our instance until their next code release on the 22nd. It makes no sense, and it's certainly not how I run our side of things. In the meantime, my users will lose 6-12 hours of productivity this month (15 days, 4 reports, 6-12 minutes each.)
jrockway 7y ago
I am guessing they want to pay $50 for 10 minutes of work instead of $2400 for 8 hours of work.
- paganel 7y ago
  You’re most likely correct and it’s a thing that has bugged me on and off ever since I started realizing that some of us, programmers, are not very well suited to linear working (for a lack of better word) like for examples accountants or lawyers. Sometimes you spend an entire day on trying to fix an issue/bug with no luck, until the following day when all of a sudden a brilliant idea comes to you and you solve everything in 15 minutes. Also, should we bill our clients for the time we spend in the shower? Because for me that’s when most of the “eureka!” moments happen (that and when washing dishes by hand). I don’t know of any solution for this issue, just wanted to point out that this perspective tends to be often ignored when discussing about how to pay for programming work. Also, programming is hard, not so much the languages or the frameworks themselves, but the human relations that any software program ultimately ends up resembling.

commandlinefan 7y ago

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.

bfdm 7y ago
There is a small subset of devs that will rush and get the work "done" in the underallocated time. The catch is in, of course, the Definition of Done. This is why we spend time aligning teams on exactly this. Sure I can fire off that one line change and tell you it's done. But, does it work? Is it right? Do you care? Typically this sub-par work is done by inexpensive outsourced development shops being managed by a client rep without the capacity to see through the lies until the project goes sideways in the future. The developers who rushed the work are paid and out of the picture and never have to fix the problem or touch that code again, so they don't care.
- plausibilities 7y ago
  Handyman Contractor mentality vs Civil Engineer mentality in a nutshell Unfortunately not everyone cares about resilience and certain performance thresholds when it comes to construction, especially when budgets become involved. Some customers will are happy to cheap out for a hack-job remodel in the hopes that they can flip their home and run off before the bagholder realizes they got a lemon.
  - Waterluvian 7y ago

toddsiegel 7y ago

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 7y ago
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.
heartbreak 7y ago
I really doubt this is an actual email sent to a client. Obviously it’s too long.

steve76 7y ago

People in charge complain about the lack of wage inflation. Yet they end people's careers and throw people in prison. People with nothing, trying to make the world better and get through the day. Maybe stop saying how great you are while you burn through other people's lives like firewood with eyes, and start making their failures your failures.

thaumaturgy 7y ago

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.

megous 7y ago

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.

chris11 7y ago
> Some customers will be ok with that. I'm not sure I would fully trust that. The client probably won't be happy if bugs from poorly tested code keep coming up. And it sounds like the client might question the dev teams work, if they are currently questioning the team's estimates.
- megous 7y ago
  They have to be ok with that before the fact. You just have to make sure they understand what it means.
gnulinux 7y ago
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 7y ago
  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.

raiflip 7y ago

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 7y ago
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.
- raiflip 7y ago
  I thought the following line: "Below we have a letter that we have written variations of numerous times over the years. " made it clear that the letter is not real, and is therefore a semi-fictional example.
- barking 7y ago
  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 7y ago
    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 7y ago

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 7y ago
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.

Udik 7y ago

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.

deleted 7y ago
[deleted]
aeorgnoieang 7y ago
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).

jmilloy 7y ago

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 7y ago
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 7y ago
  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."

te_platt 7y ago

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.

bobm_kite9 7y ago

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 7y ago
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 7y ago
  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".

rusanu 7y ago

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

jshowa3 7y ago

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?"

munk-a 7y ago

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 7y ago
The post covered that, tho not the specific details you mention.
- munk-a 7y ago
  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.

jrochkind1 7y ago

> 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.

amelius 7y ago

Just send them a git diff ...

tomcam 7y ago

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.

jorblumesea 7y ago

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.

deleted 7y ago
[deleted]

ashelmire 7y ago

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.

unseenbastiat 7y ago

Buy cheap Viagra Cialis erectile dysfunction pills online: http://goatse.info/ http://goatse.info/

nocman 7y ago

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.

jermaustin1 7y ago

> 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.

lowercased 7y ago

> 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.

ww520 7y ago

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.

unreal37 7y ago

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.

bobblywobbles 7y ago
Our needs are complex, and constantly changing. If our needs weren't complex, it would be easier to make a change.
rafiki6 7y ago
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.
notatoad 7y ago
>But I also see the other side. Why DOES it take 8 hours to do a simple one-line code change? That's ridiculous. you might be right, but if you're not in a position to help make it take less time, that's not a helpful discussion to have. the reality is that it takes that long, and complaining doesn't make it faster. The procedures that take time exist for a reason, and i'm sure in every organization there are opportunities to make the process faster. But when somebody who wants a change says "why does it take that long", they aren't looking for helpful ways to improve the process, they're looking for an exception to the process be made so their specific change gets out faster.

Townley 7y ago

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?

yebyen 7y ago

> 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.

zghst 7y ago

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...

deanalevitt 7y ago

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 7y ago
> 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.

donarb 7y ago

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.

breatheoften 7y ago

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

supernova87a 7y ago

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."

brlewis 7y ago

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.

ozim 7y ago

"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.

neves 7y ago

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-many-microsoft-employees-does-it-take-to-change-a-lightbulb/ https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-...

cromulent 7y ago

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.

jldugger 7y ago

Quick survey for folks: How long does it take to push a spelling fix out to customers?

crikli 7y ago

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 7y ago

> "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.

utopcell 7y ago

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

WheelsAtLarge 7y ago

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 7y ago

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.