Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

simplethread.com

Post reply on HN
Print view View original

101–110 of 285 posts

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

#101

Post by novaleaf »

noego wrote: post #40
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…

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

my own anicdata: Integrate a default proxy into our existing "choose proxy" workflow takes about 2 weeks, and I'm currently on my 3rd month of those 2 weeks :)

Reasons for the delay:

1) Proxy is a stand-alone application. Needs it's own deployment and build configuration 2) Main app was running on Node 6.x. High time to upgrade to 10.x as 6.x LTS is running out. 3) Upgrade to 10.x breaks some modules we depend on (Google Cloud datastore) and that module has been deprecated in Node 8.x+.. time to refactor that.... 4) Main app is in a mono-repo with backend systems still running node 6.x Don't want to spend the time upgrading everything to node 10, so need to split Main app into it's own repo, decoupling from existing mono-repo codebase 5) Since we are upgrading main app to Node 10, Best to remove dependencies on old definitely-typed typescript typings (upgrade to npm @types definitions). And as such refactor to use latest version of all modules.... 6) Security: New Default Proxy should only allow the Main app. code a solution for this using Keypairs.... 7) Docs, sample code for users, announcement mail.

thankfully i'm currently on step 7. Usually I expect to be off on my estimates by a factor of 4x. This is excessive :)

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

#102

Post by avgDev »

bluGill wrote: post #92
avgDev wrote: post #86

Earlier quoted context omitted.

This is impossible in my case, the source code is outdated. We do not have the source code of the project, which we run in production. The dev lost it. I have tried working with the source code but it has many bugs and it appears to be two years out of date. This leaves us with an application only in its current state with no way of making any changes. I may be able to extract pieces of information, reuse some stored…

At least you have something. You need to tell your boss that all features in the last 2 years need to be rewritten from scratch, with no lessons learned to speed up the effort, but that is still faster than starting over (particularly if the boss can say some things didn't turn out useful).

Would you take this approach even if the framework is outdated? Part of rewrite is to switch to a newer framework and make general improvements in maintainability, reliability and speed.

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

#103

Post by blhack »

commandlinefan wrote: post #100
blhack wrote: post #73

Earlier quoted context omitted.

>software has been a mainstay of modern business for _at least_ 30 years. No it hasn't. I've worked many jobs where software is still an afterthought. There might be a few software packages that the business licenses for use, but they are far, far, far from every having any software developers on their staff.

Well, what I mean here is - you can’t do business without software (or rather, you can’t do business without computers). I suppose if you’re managing a convenience store in central Alabama you might, but otherwise, software IS the business.

My former company (valuation ~$100M) was not a software company. It was a services company, and most of the business could run off of paper.

We were not a convenience store in central Alabama.

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

#104

Post by unreal37 »

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…

Agreed. This post is one long excuse.

If I was the client and you sent me this blog post as an answer to "why is it taking too long?", I'd fire you.

Because you spent more time writing the post than it'd take to update the code.

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

#105

Post by SketchySeaBeast »

munk-a wrote: post #81
SketchySeaBeast wrote: post #23

Earlier quoted context omitted.

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.

Itemize the bill, break it down relentlessly into tiny components and show how long different facets tied to the feature build took, ideally pin some of the time on them if it's appropriate ("Remember when you guys were a bit wobbly on the background color, well we had quite a few meetings and dev was tied up while we were talking, it ended up taking us about three hours between those two hour meetings and then an ad…

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

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

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

#107

Post by maccard »

bfdm wrote: post #15
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…

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…

On the contrary, there are plenty of devs who won't take on any work until it's been designed, scoped, run through management, prioritised and scheduled, when the actual fix is a one line change that would have taken less effort than the meeting where it was prioritised.

There's a happy middle ground between the two, and assuming developers who will deliver quick fixes are all hacks who don't care is counterproductive.

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

#108

Post by megous »

gnulinux wrote: post #58
megous wrote: post #22

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…

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.

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.

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

#109

Post by bluGill »

avgDev wrote: post #102
bluGill wrote: post #92

Earlier quoted context omitted.

At least you have something. You need to tell your boss that all features in the last 2 years need to be rewritten from scratch, with no lessons learned to speed up the effort, but that is still faster than starting over (particularly if the boss can say some things didn't turn out useful).

Would you take this approach even if the framework is outdated? Part of rewrite is to switch to a newer framework and make general improvements in maintainability, reliability and speed.

Yes. A framework is a detail, the business logic shouldn't care. Even if the framework is tied in I'd keep using it while moving newer stuff to something else. I've been in big rewrites to change the framework and everything else, on hindsight I believe I could have done an in-place refactor of everything to the new framework and been working the whole time, at less cost.

That isn't hypothetical, in the above rewrite we took one part that was considered too essential to wait brought it in, wrapped it, and used the new framework. It was working much sooner than the other code. It still isn't completely re-written - but it doesn't need to be as the core business logic is known to work.

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

#110

Post by unreal37 »

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

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

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

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

Post reply on HN