Just send them a git diff ...
Dear Client, Here’s Why That Change Took So Long
61–70 of 285 posts
Re: Dear Client, Here’s Why That Change Took So Long
#62Earlier quoted context omitted.
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.
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.
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.
Re: Dear Client, Here’s Why That Change Took So Long
#63That'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.
Re: Dear Client, Here’s Why That Change Took So Long
#64What 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…
I've been developing for clients for 20+ years and 9 times out of 10 they do under estimate, but I think it has to do with lack of knowledge rather than anything malicious. I found myself doing it when I get quotes for home repair or construction. My mind immediately goes to "I don't think it should take that long" even though I have no idea how to estimate those types of projects. I wonder if it's because with somet…
Please don't excuse this, when management over promises and devs "under" deliver, then the axe never falls on management. The best work environments I've seen are where devs and management work together to supply estimates of a reasonable scale and where time is taken in project planning to chop up big goals into small tickets in a developer-meaningful manner.
Re: Dear Client, Here’s Why That Change Took So Long
#65Part 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.
Re: Dear Client, Here’s Why That Change Took So Long
#66To 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 eve…
[deleted]
Re: Dear Client, Here’s Why That Change Took So Long
#67The 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 fo…
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.
Re: Dear Client, Here’s Why That Change Took So Long
#68The 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 fo…
Pro-tip for anyone who needs to internally sell getting the automated testing in. Feel free to gently inflate the manual testing and deflate the automated testing numbers, and make it clear that the automated testing will reduce the cost of the next ticket.
Once a code base has decent test coverage the time it takes to add additional tests is pretty reasonable and most of that manual testing time goes away.
Re: Dear Client, Here’s Why That Change Took So Long
#69Dear 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.
Re: Dear Client, Here’s Why That Change Took So Long
#70Earlier quoted context omitted.
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 cl…
Spot on. I was 1st SE at the company I am at now. Previous applications were developed by outside contractors. I tried making some changes to that code base and found massive issues. Source code was older than the compiled application. Massive methods that were 1k+ lines long. Business rules all over the place in IF statements. Barely any documentation/comments. Only way forward is complete rewrite. I'm a relatively…
Even though the code you are interacting with appears awful, you may want to reconsider the rewrite strategy. This post may be helpful: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Consider rewriting only a handful of small parts that are causing problems critical to the success of the product, and making small improvements to the rest of it as needed over time.