21–30 of 62 posts
Just because a function is”seldom used” shouldn’t schedule it for execution. Users might seldom use something but really need it.
Just because a function is”seldom used” shouldn’t schedule it for execution. Users might seldom use something but really need it.
Earlier quoted context omitted.
If you could somehow track the frequency spectrum of usage, then you could mostly handle that problem. "Oh, the frequency spectrum strongly peaks at about once a week? I guess users regularly need to use this feature. Probably important somehow." vs "Huh, the frequency spectrum isn't strongly peaked anywhere, but is substantially lower at high frequencies. We can probably remove this."
Imagine a time keeping system where employees regularly enter their hours and schedule time off. But somewhere is a button or screen that gets used once a week called "run payroll". Aside from being periodic and not available to everyone, no metrics can capture how important it is. Never the less, my favorite thing to do with code is running over it with the delete key. Just be careful about what gets it ;-)
And this is why the users are the ultimate deciders - or at least should be - what features ought to be removed, rather than the developers.
Earlier quoted context omitted.
It’s not unusual to do it in C or C++, just because the dependency management story sucks so bad (there’s a lot more options than there used to be, but still no one defacto standard like pip or cargo).
There's this concept of a shared library, you should check it out.
https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
> A lot of software developers are seduced by the old “80/20” rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.
> Unfortunately, it’s never the same 20%. Everybody uses a different set of features. In the last 10 years I have probably heard of dozens of companies who, determined not to learn from each other, tried to release “lite” word processors that only implement 20% of the features. This story is as old as the PC. Most of the time, what happens is that they give their program to a journalist to review, and the journalist reviews it by writing their review using the new word processor, and then the journalist tries to find the “word count” feature which they need because most journalists have precise word count requirements, and it’s not there, because it’s in the “80% that nobody uses,” and the journalist ends up writing a story that attempts to claim simultaneously that lite programs are good, bloat is bad, and I can’t use this damn thing ’cause it won’t count my words. If I had a dollar for every time this has happened I would be very happy.
> modules that accounted for less than 0.1% of page visits. This meant I could remove them entirely without affecting 99.9% of users. No it doesn't, these are different metrics, same user that does those 99.9% visits could once in a blue moon want to visit a very important page, and be negatively affected. And this could (in theory) be the case for every single user The Word screenshot is another illustration of the…
Yeah, I'm thinking about the apps I use all the time and the features that I rarely use but would miss. Like reset password... or account cancellation ... stuff like that.
Their approach is quite reasonable as a starting point. Make non breaking product change and see what happens. You may be amazed what (doesn't) happen.
> While I knew that some pages were less frequently visited than others, I was surprised to see that there were modules that accounted for less than 0.1% of page visits. This meant I could remove them entirely without affecting 99.9% of users. I could delete entire directories containing dozens of files and thousands of lines of code. I don't know about the author's application, but a data driven approach is not goin…
If you could somehow track the frequency spectrum of usage, then you could mostly handle that problem. "Oh, the frequency spectrum strongly peaks at about once a week? I guess users regularly need to use this feature. Probably important somehow." vs "Huh, the frequency spectrum isn't strongly peaked anywhere, but is substantially lower at high frequencies. We can probably remove this."
> While I knew that some pages were less frequently visited than others, I was surprised to see that there were modules that accounted for less than 0.1% of page visits. This meant I could remove them entirely without affecting 99.9% of users. I could delete entire directories containing dozens of files and thousands of lines of code. I don't know about the author's application, but a data driven approach is not goin…
The 0.1% and 99.9% are not complements!
"Data driven" development is so much BS since so many devs don't care to think properly about sampling and statistics.