“Oh, don’t worry, it’s just a quick fix.”

That short phrase has caused me much pain in the past… Let’s take it a step back.

Have you ever gone to a chiropractor so they could crack your back? We all know that feeling of euphoria when you feel those cracks. The release of endorphins into your brain such that you can’t help but smile from ear to ear, no matter what it was that was plaguing your mind only minutes earlier. And yet, the one part I remember most from that visit was the preface the chiropractor gave me. It went something like so: “You wouldn’t try to fix your car’s engine without knowing what the different parts are or how it works, right? Just like so, I ask you to not try to do this to yourself or your friends.” That point somehow really struck a chord with me. The chiropractor was able to release my pain in a few quick seconds without much effort, why couldn’t I do that by myself?? But the truth is that where I see a back, he sees the individual bones, muscles, joints, and the connections between them. He knows where to push, where to apply pressure, in such a way that is not harmful but actually helpful. The same goes for a car mechanic. And the same goes for software developers.

You see, while the end product of software is a gorgeous, user friendly mobile application (let’s stick with mobile applications for the sake of this post) that works beautifully, there is always a lot going on behind the scenes to make sure that your experience is great. Which is why software is so intriguing! A final product can have so many moving pieces on the ‘backend’ that the user doesn’t even know. One could argue that that’s what makes great software, the user not knowing its complexity.

However, what separates things like people’s backs and software is the fact that while most backs are created equal, most software is not. Given that multiple platforms, frameworks, languages, syntaxes, and even the individual styles and education of each programmer differ so much, any one app can be built in a multitude number of ways behind the scenes. Knowing this, we can then see that ‘simply’ making a ‘quick fix’ can amount to that much more. Giving a button an action that is similar to that other button on the other page could end up looking like a game of Jumanji. Not to say that it’s not fun, it most definitely is (that’s why we’re in this business!), but it’s not a walk in the park.

Let’s look at a real world example using the scenario described above. If we’re looking at an iOS application, it could have been built natively using either Objective-C or Swift as the main programming language. It also could have been built using React Native, a JavaScript framework built and supported by Facebook. It also could have been built using a hybrid platform such as Titanium (JavaScript) or Cordova (which could be built on top of various different front end frameworks). With each of these scenarios, the apps could look indistinguishable from one another, even though the backend could be worlds apart. Each of these different languages and frameworks have their own syntax, nuances, and best practices (also, plenty of bad practices). Now we see that to give a button an action that is similar to that other button on the other page could include a lot more digging around at first, as opposed to a simple copy and paste.

At the end of the day, there’s a reason I go see a chiropractor when my back hurts, or a car mechanic when inspection time comes around. These people earned a reputation with what they do and can bring experience to the table where I wouldn’t know where to begin. Because of that, I will never tell them how easy their job is.