Re:Software Engineering principles to make teams better
by bobthepanda on Wednesday June 30, 2021 @04:00PM
(#27692819)
Meaningful improvement is in the eye of the beholder. There's the old tale of how Google found out 500ms in latency was a 1% drop in traffic. http://glinden.blogspot.com/2006/11/marissa-mayer-at-web-20....
20 to 17 minutes is a 15% time savings still.
Re:Software Engineering principles to make teams better
by lowercased on Wednesday June 30, 2021 @08:42PM
(#27695173)
25 hours to 20 minutes is insane. The process ran daily and only needed to run daily. 20->17 was unnecessary and a waste of time.
Re:Software Engineering principles to make teams better
by lowercased on Thursday July 01, 2021 @08:29AM
(#27698432)
Can't edit my post - posted too soon. 20 min -> 17 min was unnecessary for the client, but... 2 other people got to 'share' in the credit, because 'the team' got this down from 25 hours to 17 minutes. They got to learn something, after telling me it was 'impossible', but... that wasn't enough. They needed to put their fingerprints on it, then got to take credit for something. And took it they did. Annoying as hell, 15+ years later.
Somewhat relatedly, I've refactored processes down from 25 hours to 20 minutes. It got to 20 minutes, and other people started nitpicking that it could 'be faster' (the same people who'd let it get to 25 hours, then threw up their hands and said "it can't be fixed"). They spent loads of time getting it from 20 minutes down to... 17-18 minutes (spending 2+ weeks in the process). I'd indicated "there's really no more 'there' there - this is about as fast as it's going to get, without faster hardware". They had to find out for themselves there wasn't much more juice left in the tank.
Maybe it's not related, but I felt like sharing it anyway... :)