When your problems are important, but the fixes perhaps not so much.
This is a common question.
Not the file-size-display issue, but rather the more general question: “Why didn’t Microsoft fix this?” where “this” is a person’s pet peeve or a system bug.
Asking “Why?” is in most cases an exercise in frustration; rarely will you get a clear answer. But I can theorize many legitimate reasons for not addressing something like this.
Become a Patron of Ask Leo! and go ad-free!
Almost all modern software is unimaginably complex. Each and every fix has to be weighed against the risk of breaking something else, as well as the cost of fixing it in comparison to its relative importance. In addition, what you consider a bug might be an intentional feature. It’s also not uncommon for the “bug” to have already been fixed in some other way that you’ve not explored. Finally, it just might not be considered important enough, or important at all.
Most folks fail to understand how incredibly complex an operating system like Windows has become.
Windows must work:
- On a staggeringly large number of different computers, over which Microsoft has only limited control
- With a staggeringly large number of different peripherals, over which Microsoft has almost no control
- With an even more staggering number and arbitrary mix of those computers and peripherals
- In several different editions (Home, Pro, Enterprise, and others)
- In many different languages
- Running a plethora of different applications from an innumerable number of vendors
- Performing an incredible number of tasks and solve an unimaginable number of problems, none of which can be predicted.
Some days it’s amazing it works at all. (And yes, this is where the anti-Windows crowd screams in unison, “It doesn’t!”).
Making any change to it, no matter how trivial, can have dramatic repercussions.
Using the original complaint as an example, let me theorize why the file-size display hasn’t been changed. (Important: I’m using this only as an example. These same reasons probably apply to any random feature/bug you think should have been fixed or changed but hasn’t been.)
It would break something
This has long been Microsoft’s Achilles heel. It’s something the company has dealt with constantly since its earliest days.1 Even though it seems each release breaks something, they spend a tremendous amount of energy trying to avoid that.
“Breaking things” may not mean the things you and I as users see. Perhaps it breaks a testing tool or some form of automation. Perhaps the fix would break something you and I would never care about — something internal to Microsoft or something important to corporate users, for instance.
It’s not a bug, it’s a feature
This classic line actually has more relevance than you might think.
While to you it might seem “obvious” that a 10-gigabyte file might be better represented as “10GB” than “10,000,000KB”, that may in fact not be the case. There may be legitimate reasons for the feature to stay exactly the way it is that we don’t have the knowledge to appreciate.
It might be too costly to change
“How hard can it be?” is a phrase that software engineers hear all the time.
The short answer is, “It can be really, really hard.”
Consider something as simple as the display of a number. It’s not just about changing the math and choosing the right suffix (KB, MB, GB, TB, etc.). It’s also about things like localization: some countries use commas while others use decimal points to separate number groups, and then there’s the whole reading left-to-right or right-to-left display issue. A small change can become incredibly expensive to implement.
And every change must be tested in all those configurations.
It might already be there
Sometimes people complain about “missing” features that are just a click away, already existing in another location or technique.
For instance, if you hover the mouse over a file in Windows File Explorer (unless you’re in the “Details” view), the tooltip displays the size of the file expressed in just the notation you’re asking for. The fact that this information is available in one place lowers the priority of it being “fixed” in another.
It might not be important enough
Which would you rather have Microsoft do: make Windows more stable and secure, or fix the display of file sizes? “Both” is not an option since resources are limited. (And, no, you can’t just add more people to a software project. There’s a very accurate adage about that: “Adding more people to a late project makes it later.”)
I choose security every time. Compared to the larger issues we want Microsoft to address, and that Microsoft may also prioritize, fixing your pet peeve often just doesn’t make it in.
It might not be considered important at all
It’s clear the person asking the question feels very strongly about this particular issue. But, to be totally honest, I’ve never even noticed it before. My gut reaction was, “OK, that’d be cool, but is it really that important?” It feels more like a minor annoyance.
I don’t mean to minimize issues you feel passionate about, but it’s frequently the case that in the grand scheme of things, these issues are low in priority simply because no one else noticed. It’s just not considered a big deal — or even a small deal.
Remember, I’m just guessing here, but for this specific feature, the fact the functionality is actually available in the tooltip makes me believe there’s probably a compatibility issue preventing it from being implemented in the size column. Much of the implementation work and testing matrix may well have been addressed by the tooltip.
That is all total guesswork on my part, based on being a software engineer who worked there for many years. I could be totally wrong.
Changes and breaks
The next logical question to ask is, “OK, if they didn’t fix my issue, why did they fix, change, and break all the things they did? Surely that was more work and broke more things than my little issue would have?”
And that is a very valid question.
Unfortunately, the answer is as vague and speculative as the reasons for not fixing or implementing something.
A lot of research and effort goes into deciding what features “make the cut” when a new version of Windows is released. And arguing — there’s lots of arguing, as well.
Most of the “big” new features and changes are part of a larger theme. Windows 10’s UI revamp is a good example. Microsoft spends a lot of time and effort designing and evaluating UI changes to make sure they work for people. You might feel that they fail in that regard, or you might simply not agree, but that’s generally what’s happening: a few major themes are selected, and hundreds, if not thousands, of changes result.
Smaller items are likely more haphazard. Product support representatives, designers, test engineers2 and software engineers all have a say in what goes in, and they all have differing opinions — just as you and I do — about what is and is not important to the next version.
As deadlines loom and the product needs to ship, some of those previously agreed-on features and fixes get tossed anyway. Often cuts are made, saying, “We’ll get to it next version,” but the pragmatic reality is, when the next version comes around, they may say, “If it’s wasn’t important enough for the last version, maybe we don’t need to address it at all.”
There’s no great answer
I’m sure people who are passionate about one feature or another, or folks who are anti-Windows and anti-Microsoft, will consider this a totally insufficient answer.
I don’t think there is a clear, complete, or sufficient answer. It depends on the issue, the timing, and on so many things out of anyone’s control and out of the public eye.
With each release, update, and patch, Microsoft makes a combination of technical, user, and business-related decisions. How those all combine into specific features and product changes is much like making sausage: you probably don’t really want to know.
One thing I can assure you of: “lazy” has nothing to do with it.
Subscribe to Confident Computing! Less frustration and more confidence, solutions, answers, and tips in your inbox every week.
I'll see you there!
Footnotes & References
1: I started in 1983, and even then we were deeply concerned about “backwards compatibility” — meaning we did not want to break software that previously worked — to the point that we would “un-fix” bugs because important applications relied on the buggy behavior.
2: Those that are left, anyway. That’s a peeve for another day.