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

171–180 of 285 posts

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

#171

Post by megablast »

deanalevitt wrote: post #149

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

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

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

#172

Post by novaleaf »

stickfigure wrote: post #131
novaleaf wrote: post #101

Earlier quoted context omitted.

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 (Go…

While all platforms have some measure of this phenomenon, the update treadmill problem does seem to be especially acute in the javascript ecosystem. I update Java dependencies maybe once a year; it's usually painless and incompatibilities are highlighted by the type system. If you let your JS dependences get stale by a few months, you're looking at hours or days of work. And that doesn't count the massive shifts in b…

I've spent the last 5 years on Node, and honestly most modules are fine. The only ones I've had serious problems with are those created by Google. They keep taking huge complex dependencies on things like Grpc that break between Node versions, and keep churning their other library signatures (or deprecating entire modules).

Maybe in the last year they've settled down, maybe not. I learned my lesson and don't take dependencies on them anymore. Much easier.

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

#173

Post by avgDev »

megablast wrote: post #166
avgDev wrote: post #41

Earlier quoted context omitted.

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…

Sounds like you don't even have source control and a CI system.

You are correct.

We have implemented source control and CI is the next obvious step, but those things were not in place 10 years ago when the application was developed.

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

#174

Post by 4ntonius8lock »

thanatropism wrote: post #95
noego wrote: post #40

Earlier quoted context omitted.

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…

> . 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. Most of these look like MBA problems. That said, maybe more experienced coders should be doing MBAs (which isn't just about attending classes but about networking, acquiring a wide…

As someone who has spent time as a project and product manager, I will say a lot of it comes down to a point of view that 'tech will make it happen'.

Many times I've seen long time estimates for something, because C level was requesting "X feature". But when you sit down down with C level, and understand what they want to achieve with X feature, many times it is possible to sit down with tech and figure a way to get what was wanted without the feature, generally by adapting some other request or feature.

The problem is that most managers are looking to suck up to C level guys and 'deliver'. And many C level guys won't stand the insubordination of someone telling them 'maybe that thing you guys thought of isn't the best way to achieve what you want', no matter how much you work on the techniques from How to Win friends and influence people. Some guys are just dictators, and some are suck ups, and when the two meet, as they often do, it means tech will work 10x what is needed to get where the company needs to be, because the focus will be on what someone requested, not what we are looking to get at.

Also, many developers get stuck in the mindset of places like that, where they assume they have no voice and everything they say will be used against them. So you ask them as a manager how they would achieve X and they just say "tell me what you want in the spec sheet"... people get weirdly conditioned when in negative re-enforcement environments.

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

#176

Post by novaleaf »

hinkley wrote: post #120
elemeno wrote: post #115

Earlier quoted context omitted.

But in a case like yours if sounds like steps 2 through 5 aren't strictly relevant to the change you're making, so it's no wonder that your estimate is blown out the water. (Sorry if I'm wrong, you've obviously got more context on your own platform than I do!) It does make me wonder though if there is a trend of 'hiding' necessary maintenance work in larger tasks - if so that seems to me to be indicative of a larger…

Yes, there is. Probably the best four projects I worked on, there was collusion to spread out the cost of necessary maintenance across all work items. Because nobody will agree to doing maintenance stories (this is how Scrum hijacks developer ethics). Never ask permission to do something that must be done. Or to look at it another way, if no stories are maintenance stories, then all stories are maintenance stories.

I used to be all about jumping on the next fancy thing as soon as it was (pre)released. Having been burnt and learned my lesson, now I delay until it's blindingly obvious it needs to be done.

But yeah, if it needs t be done, do it.

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

#177

Post by throwaway55554 »

megablast wrote: post #162
throwaway55554 wrote: post #89

Earlier quoted context omitted.

Sounds like a hiring problem. Start hiring some new devs and keep them separate so as to not contaminate them. As they come up to speed, let one of the other devs go. Wash, rinse and repeat. Note: I'm a dev and I can tell you I very much dislike working with prima donnas.

Oh yes, keep them separate from the people who know the application, how it works, what it integrated with, all the codes, all the issues. Brilliant!

Right!?

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

#178

Post by mjevans »

williamdclt wrote: post #161
cutenewt wrote: post #153

Earlier quoted context omitted.

I've always wondered why we don't provide estimates with a low, median, high scenario. It'd create a lot less disappointment and more accuracy.

I don't think that people are good at that. I've been asked before to give a low and a high scenario, but all I can really do is to tell you how long I think it would take (I did a +/- 50% of the estimation, and explained what I did). Sometimes there's a specific uncertainty that changes radically the estimation. But remove this uncertainty and we're back at estimating and doing +/- 50%.

It's the unknown unknowns that really make estimates inaccurate. If someone were an expert in one exact thing and that's what they worked with day in and day out, then those unknowns would be small and the areas around them well defined.

It is relatively easy for someone to become a maintainer of one specific thing as long as that's the only thing they're doing for a long time.

Then you look at a software developer, sysadmin, anyone in the technical industries, and quite often it's not one specific thing, it's LOTS of specific things. Each with thousands, maybe millions, of human-hours in their development and the development of the things they depend upon. Every layer of hardware and software having it's own quirks and wrinkles.

It's like trying to be the god of a small solar-system of interacting planets each with plate tectonics and life-forms.

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

#179

Post by scarejunba »

avgDev wrote: post #86
drewolbrich wrote: post #70

Earlier quoted context omitted.

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.

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…

Slightly relatedly, we bundle our source code into our deployable artifact along with the revision. A bit silly and it increases the artifact size, but it's just another layer in the Docker image and so it's not that painful.

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

#180

Post by ozim »

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

Post reply on HN