You weren’t hired to make it work on your machine – you were hired to make it work on every other machine in the world…
An Engineer, a physicist, and a mathematician are standing in a field of cows. They are there because they have been asked to build the most efficient, smallest fence possible to contain the cattle. The mathematician steps up and boldly declares that a circle is the most efficient use of fencing for a given area and then proceeds to build a circular fence around the field and all of the cattle. The physicist, being more practical, takes the idea of the mathematician, walks into the field and proceeds to herd the cattle into the center and makes a much smaller circular fence with the cows tightly packed inside, thus achieving the same objective with quite a bit less fencing. The Engineer, having watched each of them build their fences, grabs a single piece of flexible fencing, walks into the middle of the packed cows, wraps the fence around himself in a tiny circle and shouts: “I am outside the fence!”
Designing desktop applications is hard. It may be one of the hardest disciplines within software engineering. The amount of variability that exists in regards to PCs out in the wild is amazingly huge. According to statcounter, between November 2018 and November 2019, Microsoft Windows accounted for 77.21% of all desktop operating system market share. From these numbers, this is further broken down with 64.7% Windows 10 systems, 27.45% Windows 7 systems, 4.97% Windows 8.1, 1.29% Windows XP, 1.22% Windows 8, and 0.31% Windows Vista.
Source: StatCounter Global Stats – Windows Version Market Share
This doesn’t even get into the variables created by CPU type. In 2019 AMD made a significant push into desktop CPU market share with some estimates putting them around 30% of current market share. However, when only considering Intel-based systems, using PCPartpicker, a great site for designing a custom PC build, shows over 900 possible Intel CPUs to choose from. Then estimated count of over 243,245,835 PCs having been sold throughout 2019 and an estimated 2 billion PCs in everyday use worldwide (from worldometers) needs to be taken into account. The sheer number of variables in host PCs to run a developed application are massive.
Guess what? You have been hired to build a desktop app that runs out in the world. On at least some of those 2 billion PCs. Good luck.
This is an extremely difficult challenge. While developing software has never been easy, right now we may be at the absolute pinnacle of difficulty in software development, at least in regards to outstanding variables on host machines. There are big movements afoot to minimize these challenges. There are lightweight environments like Electron that are effectively OS-independent. Big modern apps like the Slack desktop client have been re-designed using this methodology. This minimizes variables so much that the minimum requirements page for this application doesn’t even mention any hardware requirements, only minimum OS versions.
There is new technology around software like Docker containers. Per Docker, “A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.” This is wonderful because now an application developer doesn’t need to worry about any of these PC variables – if the host computer can run the Docker engine then it should be able to run the application.
Even Microsoft is aware of these problems and is working on solutions to address them. .NET Core is a cross-platform solution that allows for .NET APIs, languages, and frameworks to be used across Windows, macOS, and Linux distributions.
The problems still exist, however, for desktop applications that are “locked in” for one reason or another. Maybe they require full blown .NET, which is limited to the newer windows ecosystems. Maybe they require 3rd party libraries that haven’t been ported to technology that is available cross-platform. And thus we get back to the crux of the issue. There are more variables, CPUs, OS’s, and hardware out there today than there have ever been before. So how does any one Engineer or Engineering team build something that works out in the wild?
The solution is actually called out in the joke at the beginning of the article. Instead of people, we need to think of the fences as containers for the population of PCs that the application will support. While it would be great to think of this as the Engineer solution, where the developer PC is inside the smallest circle and the range of devices to support is the rest of the world, that is not practical. For this exercise, the ideal target is actually somewhere between the Mathematician’s solution and the one created by the Engineer, with the Engineer’s PC right smack dab in the middle. Please note – the solution here is the doughnut-shape in the middle and the Engineer’s PC is actually outside of this shape!
This is a critical point to this exercise. The Engineer’s PC is outside of the target solution. Therefore, it does not count if it runs on that PC.
Stop and think about that statement for a moment: It does not count if it runs on your PC.
Sorry if this disappoints you or doesn’t seem fair. This article is not here to debate the merits of fairness. This is also a statement that like it or not, we have all thought and most likely have said out loud. That instance where you have all of the debugging and tracing possible connected to an instance of an application and, surprise, nothing goes wrong. But then someone else, a customer, tester, or other random person, installs the app and it crashes. And not just crashes, explodes in a flaming heap of wreckage like a modern day Hindenburg. You know the scenario. The one where no logs are produced and all that is left is a defunct application and an unhappy customer.
Still – even in these dark hours you need to resist! Don’t say it! *sigh* But it runs on my machine. *sigh*
Let’s take a moment and step back here. As someone with plenty of experience developing software, I certainly understand the frustration that an Engineer feels when hitting an issue like this. But what you as an Engineer need to understand is how this is perceived by those around you. This is very important as to understanding why this phrase should not be part of your vocabulary. From a perception standpoint, this is a horrible message to communicate to the people around you. Here are a few of these possible perceptions:
The Customer – But It Works On My Machine
- What they might say: Look, I don’t care if it works on your machine, their machine, or whatever. It doesn’t work on MY machine. I paid for this and I don’t see you doing anything about it.
- What they might hear: You built something that you don’t understand and you don’t know how to fix it so you are throwing your hands up and walking away while I am sitting here and can’t get my work done.
- Why this is important: This messaging is weak and doesn’t do anything to build confidence that the customer’s issues are being addressed. Maybe they only use your product for 5 minutes out of their day, but that is an important 5 minutes. They can’t complete their assigned tasks for the day without this working. This response puts the onus back on them to figure out a problem for something that they just want to work for the time that they are using it. Your response isn’t helping them achieve this goal.
Your Manager – But It Works On My Machine
- What they might say: I don’t pay you to build applications for your machine, I pay you to build applications for every other machine out there!
- What they might hear: You don’t have the ability to do this job. You just built something that you don’t understand, and now you can’t fix it. Additionally, instead of working on coming up with possible theories and solutions you are just bringing me more problems to deal with.
- Why this is important: This statement really shows a lack of initiative and a lack of communication skills. This breaks one of my stated rules for Engineers: Never Present A Problem Without Presenting At Least One Possible Solution. By throwing this out there and waiting for someone else to do the thinking it puts you in a bad light. Make some effort to research things first, communicate that effort second, and ask for help third. It is a good thing to ask for help – but just making this statement with no additional context makes you look helpless.
Your Co-Workers – But It Works On My Machine
- What they might say: That sucks.
- What they might hear: I have my own work to do and my own problems to solve. I also don’t hear a question or a request for help in that statement so I probably am not going to go out of my way to help you on this one.
- Why this is important: You are not practicing good communication with your teammates. It is ok to ask for help or suggestions, but that is not what is happening here. This has a good chance of simply coming across as complaining or venting which is not a positive interaction with your teammates. Also, if those teammates are involved in supporting the product you are not helping them do their jobs appropriately as you are not giving them anything that can help their communication with the customer regarding this issue.
Some people feel that this statement is something that separates junior Engineers from more senior Engineers. However, in my experience this is not the case. I have heard this statement from both junior and senior people. I actually believe that this statement reflects more of a Developer mentality versus that of an Engineering mentality. There are many differences between the two, but one major difference is that Developers need more definition around solutions and often need someone else to do the heavy lifting around thinking through a comprehensive solution to problems. The statement “but it works on my machine” reflects this mentality. Someone with an Engineering mentality believes that there are solutions to every problem and that they are the right people to come up with that solution. This drives additional research and ideas and potential solutions. This drives better communication with teammates. This mentality focuses on the solution rather than on the problem.
Remember – we live in a world focused on what have you done for me lately. There will always be another problem to solve. There will always be a hard bug that doesn’t manifest itself on the machine you are using. The challenge and goal is to get through that in the most efficient way possible. So I challenge you to embrace the Engineering mentality and remove this statement from your vocabulary along with all of the other excuses, deflections, and absolutions listed below. In doing so, it will make you a better Engineer, a better employee, and a better teammate. Thanks for reading!
Comments are closed, but trackbacks and pingbacks are open.