Dear Client, Here’s Why That Change Took So Long • Hacker News Board

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

#141

Post by SketchySeaBeast » Tue, May 07, 2019, 6:42 PM UTC

titanomachy wrote: post #12

SketchySeaBeast wrote: post #4

Earlier quoted context omitted.

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.

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 thei…

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.

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

#142

Post by hinkley » Tue, May 07, 2019, 6:43 PM UTC

throwaway55554 wrote: post #53

bfdm wrote: post #15

Earlier 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…

> 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. For these devs the Definition of Done is handing it to QA to debug. They do not include all the QA tickets their rush job creates as part of their DoD, and neither does their bad manager. Therefore, it does, in fact, look like they're way more productive than the res…

I've worked with devs who were so self unaware that they thought they spent less than 10% of their time fixing bugs in their code.

In the end they were right. Because they refused to own their own bugs, everyone else was cleaning up after them.

The real problem was when they started using this bullshit ratio to inform their opinions on development processes, pushing back on attempts to mature our process and tools.

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

#143

Post by bobblywobbles » Tue, May 07, 2019, 6:44 PM UTC

jmilloy wrote: post #45

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 fo…

I disagree with you. I don't think the article is "full of excuses." The details are essential to help non-developers understand why things take longer than expected, giving them a list of hours is not helping them anymore understand what goes on.

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

#144

Post by bobblywobbles » Tue, May 07, 2019, 6:45 PM UTC

unreal37 wrote: post #110

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 tak…

Our needs are complex, and constantly changing. If our needs weren't complex, it would be easier to make a change.

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

#145

Post by [deleted] » Tue, May 07, 2019, 6:46 PM UTC

gilbetron wrote: post #125

commandlinefan wrote: post #10

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…

Three months ago I found myself in yet another discussion with a PM about time estimation. I gave him an analogy I use for non-developers, where you try to estimate how long it will take to pack a kitchen into boxes for moving, the catch, I said, is that there's a significant chance each time you open one of the cupboards or drawers there might be a whole other kitchen or even house behind it. He responded with, "wel…

[deleted]

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

#146

Post by collyw » Tue, May 07, 2019, 6:47 PM UTC

_bxg1 wrote: post #33

commandlinefan wrote: post #10

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…

It's a failure of education. This is one reason why everyone should have a basic understanding of code: not so they can all become programmers, but so they can get a mental handle on these systems and the people who do program them. It's the auto-mechanic problem; if you don't understand the thing yourself, you have no way to know whether or not you're being taken advantage of. So you tend to just split the differenc…

My worst managers have been ex-programers who got promoted to management (too) early.

One always seem to think solutions were quick and easy, but that's because he never got to the stage where he could write reliable maintainable code. We were constantly fighting fires and he seemed to think that was normal.

I am not convinced that giving people enough knowledge to be dangerous is a good thing.

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

#147

Post by rafiki6 » Tue, May 07, 2019, 6:47 PM UTC

unreal37 wrote: post #110

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 tak…

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.

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

#148

Post by sambe » Tue, May 07, 2019, 6:48 PM UTC

commandlinefan wrote: post #10

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…

In my experience, well in excess of 20% of devs would make such claims and/or behave like this if given free rein, perhaps even a majority. This is especially true if you take "dev" to mean "anyone who commits code". The exact percentage will of course depend on the nature of the organisation and the incentives set by it.

I will give you that eventually they will take a bunch of time on something and have to explain furtively "it's more complicated than you think" but they may not even realise at that point why it's getting harder.

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

#149

Post by deanalevitt » Tue, May 07, 2019, 6:49 PM UTC

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.

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

#150

Post by donarb » Tue, May 07, 2019, 6:50 PM UTC

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.