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

181–190 of 285 posts

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

#181

Post by rdiddly »

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…

More likely those who were paying attention and learned the lesson were promoted, fired, or age-discriminated out of it.

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

#182

Post by hinkley »

novaleaf wrote: post #170
hinkley wrote: post #117

Earlier quoted context omitted.

You need to get an agreement with the team that you're going to amortize future upgrade treadmill activities across all work that is done. You can't mortgage future productivity to get short term gains when your project is supposed to run for 5, 10, or 20 years. You'll spend most of your time working slowly if you work that way.

yours and a lot of other comments seem to hint that this work may not be strictly required? I'm a bit surprised. At least in my case, as a public facing SaaS I don't think running Node 6.x past it's LTS window is a valid choice, so better to bite the bullet now. If I went about doing the minimum work, it just adds more code/complexity that needs to be refactored when upgrading Node.

No, it has to be done. But some people won't believe it until they've had a couple tough upgrades that show the cost of laxity.

On one project there were CERT advisories out, and we had deferred upgrades due to breaking changes in those upgrades. All of a sudden we had to deal with the upgrade and a security issue at the same time. It was ugly. After the second time, we started putting at least one upgrade story per month on the work queue. Sometimes we let the engineer pick what they wanted to upgrade (just upgrade something!). Other times we picked the engineer for the work that needed to be done.

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

#183

Post by Techonomicon »

novaleaf wrote: post #170
hinkley wrote: post #117

Earlier quoted context omitted.

You need to get an agreement with the team that you're going to amortize future upgrade treadmill activities across all work that is done. You can't mortgage future productivity to get short term gains when your project is supposed to run for 5, 10, or 20 years. You'll spend most of your time working slowly if you work that way.

yours and a lot of other comments seem to hint that this work may not be strictly required? I'm a bit surprised. At least in my case, as a public facing SaaS I don't think running Node 6.x past it's LTS window is a valid choice, so better to bite the bullet now. If I went about doing the minimum work, it just adds more code/complexity that needs to be refactored when upgrading Node.

People are hinting that it is not strictly required to get what was initially desired done.

And that seems 100% true.

You do not have to do everything at one time. You can easily to one thing, and then right after that, literally right after, do another.

You could have gotten the proxy up and going, and then upgraded node.

It's not about "doing the minimum work" it's about understanding the problem space, what can be split up, and how to attack the surface area efficiently.

You're also introducing other problems that can occur by doing multiple things at the same time.

Generally speaking I advocate my developers to be really good at separating problem spaces and attacking accordingly. It's really hard to take on multiple issues at one time and actually have high confidence in not breaking many systems along the way.

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

#184

Post by makecheck »

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…

Software prices have not done anything to help with this.

Entire operating systems are “free”. Software that takes tons of effort may be $.99 on an app store. We have been programming non-programmers to undervalue everything for those same 30 years.

Probably, software packages should never have fallen below $100. The minimum price on any app store should probably have been $10. Then we might see a valued industry.

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

#185

Post by Qwertystop »

SkyBelow wrote: post #87
dsp1234 wrote: post #31

Earlier quoted context omitted.

This isn't all on the non-developers. I've walked into two rooms this week, which contained several senior developers, and when I asked them about non-functional requirements, they had to ask what they were, and why they were important. I've also seen teams where the Defintion of Done doesn't include any steps at all towards deployment. Done is when someone approves the pull request. Not surprisingly, it takes longer…

>when I asked them about non-functional requirements, they had to ask what they were, and why they were important. Based on my own experience with NFRs, these are perfectly reasonable questions.

I think this is a parse issue -- is this

> I asked them about [the non-functional requirements for this project] and they had to ask [please give me details on those requirements]

or is it

> I asked them about [non-functional requirements as a general concept] and they had to ask [what are these new things you speak of, I have never heard of such a thing]

?

The former is reasonable, the latter less so.

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

#186

Post by [deleted] »

novaleaf wrote: post #170
hinkley wrote: post #117

Earlier quoted context omitted.

You need to get an agreement with the team that you're going to amortize future upgrade treadmill activities across all work that is done. You can't mortgage future productivity to get short term gains when your project is supposed to run for 5, 10, or 20 years. You'll spend most of your time working slowly if you work that way.

yours and a lot of other comments seem to hint that this work may not be strictly required? I'm a bit surprised. At least in my case, as a public facing SaaS I don't think running Node 6.x past it's LTS window is a valid choice, so better to bite the bullet now. If I went about doing the minimum work, it just adds more code/complexity that needs to be refactored when upgrading Node.

[deleted]

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

#187

Post by Symbiote »

novaleaf wrote: post #170
hinkley wrote: post #117

Earlier quoted context omitted.

You need to get an agreement with the team that you're going to amortize future upgrade treadmill activities across all work that is done. You can't mortgage future productivity to get short term gains when your project is supposed to run for 5, 10, or 20 years. You'll spend most of your time working slowly if you work that way.

yours and a lot of other comments seem to hint that this work may not be strictly required? I'm a bit surprised. At least in my case, as a public facing SaaS I don't think running Node 6.x past it's LTS window is a valid choice, so better to bite the bullet now. If I went about doing the minimum work, it just adds more code/complexity that needs to be refactored when upgrading Node.

You either need to upgrade from Node 6 or you don't.

That's nothing to do with adding a new feature, and should be planned accordingly. It's unfortunately very common for developers to hide maintenance tasks in other work, but clearly not ideal.

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

#188

Post by Balgair »

zbigniewc wrote: post #134
Balgair wrote: post #116

Earlier quoted context omitted.

My own 'magnification' index is as such: Take whatever time I think it should take. Then double that number and go up one time unit. Exp: I think it should take me 3 hours this afternoon to do this -> 6 days. I think it should take me 2 days to to this -> 4 weeks. I think it should take me 1 week to do this -> 2 months. I think this should take us one month to accomplish -> 2 years.

Such approach assumes that literally all tasks are minefields full of unpredictability. But are they really? In my experience such reasoning and 'magnification' applies only to minority of cases, while most of the time you hopefully deal with well-enough understood domain and codebase to accurately estimate the effort based on the initial judgement.

For me, it's more of a guestimating rule. Sure, some tasks take less than I'd expect them too. Sure, some take a LOT longer than even my guesstimate. But this helps me 'plan for drought and pray for rain', so to speak.

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

#189

Post by james_in_the_uk »

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…

If you think software developers get this bad, try being another professional like marketing or legal.

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

#190

Post by noego »

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…

Many times, they are indeed MBA problems. VPs micromanaging instead of delegating, not investing enough money into hiring, retaining and developing their talent, etc.

Other times, it is a problem with the existing developers. Choosing not to learn/follow industry best practices. Creating an over-engineered solution instead of a simple one. Skimping on automated testing and spending more time on manual testing instead. Making their colleagues wait an inordinate amount of time for a simple question, code-review or approval. There are many things developers can do that would slow down their team's productivity.

I don't think tribal finger-pointing is very productive. It really does vary case-by-case.

Post reply on HN