
File this rant under ‘Free Advice is not always Good Advice.” Over the weekend, Microsoft pushed out an update for Office 365 that included an update to OneDrive. Now, I
File this rant under ‘Free Advice is not always Good Advice.” Over the weekend, Microsoft pushed out an update for Office 365 that included an update to OneDrive. Now, I (and many other customers) have one of those icons on my taskbar that indicates an open window that says DesktopWindowXamlSource. I know that this is a bug. It indicates an open window for a program that doesn’t have one. OneDrive is only visible on the notification part of the taskbar since it mainly does it’s work in the background.
That’s an annoyance but not enough for a rant. These things happen when someone makes a small coding error or, more likely, forgets to disable a flag during a build. It should be noted that this only seems to happen when using virtual desktops so it may have gotten past QA test (though it shouldn’t have).
What I found unconscionable and, hence, rant worthy, were the solutions that Microsoft allowed to live on their own help forums at answers.microsoft.com. The first “solution” was to enable a setting that allows the desktop icons for open programs to reside only on the virtual desktop that the program is living in. So, basically change the UI and, very likely, how you work, to accommodate a bug. That’s not a real solution but at least it is a workaround, silly as it may be. Change how you work to accommodate a developer generated problem is not a real solution.
The second common solution was the one that caused all this ranting. Several posts, often by folks with “Insider” designations, suggested selecting the “Get OneDrive Insider preview updates before release” setting. They did so without context and it was clear that some people had no idea what this meant. So, people, whose forum designation suggested expertise, suggested to possibly less experienced folks that they switch their main machine to the developer channel without telling them they were signing up for beta product. That’s irresponsible on the part of the posters. They don’t know the experience level of the people reading their solution who could be newbies. It’s unusual to apply updates from a developer channel to a production machine. You especially don’t do this when you don’t know the people to whom you are addressing this as a solution.
I get that Microsoft maintains these forums so that users can help other users, thereby alleviating their support burden (and cost). It is for that exact reason that they should moderate these forums to make sure the information is factual and appropriate. Suggesting a bunch of end users of unknown experience and capability adopt beta software to solve a problem that does not affect their productivity is clearly not appropriate.
Microsoft has a duty to insure that solutions on their forums are not going to harm their customers. Allowing dozens of posts of this sort shows that they are either unable or unwilling to take that duty seriously. Given how many workers in the tech space have been laid off recently, it seems that they could hire a bunch more community managers or tech support technicians to scope out “solutions” that are potentially harmful to their customers and axe them. At the very least Microsoft should provide additional information that enables informed decisions.
It’s time for tech companies to police these user forums more, especially for products that effect end users and not just us techies. Microsoft may have dropped the ball with a OneDrive bug but their forums are dropping an anvil on their customers. Time to fix that.
During much of my tech career, I dealt in precision. Precision tolerances for hardware products. Precise specifications for software. marketing language that favored exactitude.
Oh wait. That last one is not entirely true. In fact, even in technical marketing where precise language would seem to be appreciated, vague and even obtuse language is often rewarded. This drives plausible deniability which, in turn, benefits companies when products don’t work as advertised. It’s true across all products, even IT ones. More importantly, it allows marketers to set their products apart from otherwise similar ones.
That brings me to my latest pet peeve – the term GitOps. This particular rant started on Mastodon after a tech journalist I respect a lot (one of the few that grok the technical stuff) wrote an article referencing the term. The article was, as usual, excellent. The title, however, lit my fuse about GitOps.
My complaint is that GitOps is just another name for Continuous Integration (CI) or maybe Continuous Integration/Continuous Deployment(CI/CD). To be more charitable, it was CI using some variant of the open source git (and yes it’s lower case) project. GitOps is, in my opinion, an example of slicing the baloney too thin. So thin, in fact that it becomes meaningless.
At that point, one of the maintainers of the OpenGitOps project, Roberth Strand, pointed me at the project’s website. I appreciate that, by the way. It’s always a sign of good community when members suggest resources to each other. Mr. Strand especially wanted me to look at the the guiding principles of GitOps. They are 1 :
What you may notice is lacking is any mention of git itself. That’s right, GitOps doesn’t require git at all. Why call it GitOps then? Weird, right?
The other thing that is immediately noticeable is that these principles would apply to most CI systems. Granted some are not driven by declarative languages, but I would argue most are. Ultimately this looks like a specific implementation of CI.
Back to our baloney. This is an example of trying to create an entire category – be it software, product, or community – from a specific case of an existing term. It’s good marketing. Afraid you might drown in the growing sea of CI/CD products, projects, and companies? Narrow the scope and call it something else. Now whatever you are doing sounds new and fresh. Yay!
The downside is, of course, confusion. It walks like a duck, quacks like a duck, but everyone is told it’s not a duck. Instead, consumers (IT pros in this case) are told to believe that a Mallard is different from a duck. The proliferation of technical terms that mean almost the same thing or that are just subsets of subsets makes decision making much harder. Consumers have to spend too much time just figuring out the starting point.
I suspect that enough companies and organizations such as the CNCF have taken up the term GitOps that it is here to stay. There’s no turning back. What is important is that GitOps not be seen as anything more than a specific case of CI, which is only part of the CI/CD pipeline landscape. Ignore the marketing and look under the covers. You might need some CI software or processes, and they may be called GitOps. You don’t need both and they are not competing with each other, except for the marketing.
Source: OpenGitOps, https://opengitops.dev/