It breaks on my machine
I am pretty sure that you are aware of the popular saying “it works on my machine” and a long list of how to go about it. But there is this opposite side of it that no one seems to pay attention to, “it breaks on my machine”.
The summary of “it works on my machine” is that the Engineer has the software working fine on his own machine but the end user gets a different experience when it gets deployed to the server. Or at a lesser impact, the product owner is unable to get the same experience on the staging environment, and the scrum master is not going to mark the task as done.
There is another side of the coin that may not affect the end user and thus may not be that important to the company but it does affect the Engineers. It is “it breaks on my machine”. You may wonder what that means.
Have you ever been the new member of this amazing team with a (not so) complex development environment/infrastructure setup and you spend ages trying to get to a stage where you can start contributing. Note that this is not even actual contribution yet.
You simply followed the docs, did exactly as the instructions and it just seems to break somewhere. But everyone else that claims to follow same docs have it up and running. Or, you are working on a task and lo and behold, go test or npm test fails only on your machine but not on your team members’. The list goes on and on.
You may argue that the Engineering team should have better processes, but not every company have the resources of the ideal tech company with dedicated people for those.
Yes, Docker helps. And yes, Vagrant helps. But there are numerous occasions that you figure it out after having another team member sit with you and troubleshoot it together.
One good approach that I’m a fan of is Async Collaboration in Koding’s new version, with their blog post here. Koding’s approach still involves a team member helping you. But it can happen in your absence and it will be your machine which sort of guarantees same experience as yours.
I also made a lame attempt of what my dream solution would be. I prototyped github.com/abiosoft/cmdplay that basically allows you to record your session and replay it. By replaying, it does execute the commands as well. There are many issues with cmdplay with the obvious ones being filesystem changes when recorded vs when played or when playing on an environment different from the recording environment.
You may argue Docker environments are reproducible with Dockerfile but that is not as detailed. Maybe a docker environment coupled with something like cmdplay would be the dream solution.
So do you agree with me that “it works on my machine” is as big of a deal as “it breaks on my machine”? I would love to hear your comments.
