What happens when people hack your shit? Well, when you have something that is hacked that is valuable to you, you probably are not too happy with the hacker.
So, what happens when you are asked to, and actually paid to as a web developer; hack someone else’s shit?
Well, this occurrence is becoming more and more prevalent in the web development communities as developers flit from place to place unbeholden to any single employer, and the level of shoddy requirements gathering, and application testing seem to never go away and merely increase.
Case in point.
A very popular and well known software developer has a commercially available and supported product line. In fact, they have 7 commercially available software products, all of them purchased many thousands of times over by companies and individuals the world over. For the most part, their products work as advertised. Say.. for 80% of their community. So, what happens to the other 20% of the community of buyers who wanted the product to work, but could not get it to work? Your work comes to a screeching halt as their product doesn’t work, and you lose money, subscribers, clients, customers, and relationships. Nobody likes that.
1. Visit their Support Blog
There ya go. Visit our support (aka complaint) forum where dozens of people each week vent about why their product doesn’t work, and our techs occasionally pop in to read and or respond to these complaints. If you even get a reply it is often sassy “you ARE a n00b” or you are relegated to sloppy seconds as they lay in a link to another forum post on the same forum that may or may not answer the question or complaint. (Let Me Google That For You comes to mind)
2. Pay them for Support
Seriously, they only charged you $59 for their product, so you can’t be on email or the phone with them forever trying to get your problem fixed. It’s probably user error anyways.. no way it could be shoddy coding or poor execution on their part. So.. each “premium support” ticket costs $59-$200. This is also sometimes a venue called: Pay us, to hack our own shit.
3. Pay others to Hack their Shit
Often times, the original software developer is unfortunately overwhelmed, under skilled, or otherwise detached from their software progeny. Or a buyer/customer has already visited the support blog (no help) paid them for support (still no help) and now is left to ask someone else to hack the program to get it to work. Life is good.
Paying an outside developer to hack something works 99.99% of the time. Because for any amount of money, any problem can be resolved. It’s an axiom in software development as it is in life itself. BUT you have to be prepared for several repercussions.
1. It may cost several times more than what you paid for the product, to have the product working as advertised. Simply, if you are not the creator of that ‘masterpiece’ chances are it will take you significantly longer to assess the problem, and come up with a working solution. (aka: hacking your own shit is way faster than hacking someone else’s shit)
2. It may take weeks to come up with a final solution. Often bugs are found in one place, but have dependencies all over the rest of the software product. So fixing the bug may create 10 or 100 or 1,000 more bugs. Outside developers are acutely aware of this fact, and this also contributes to cost overruns with this type of work.
3. If the original software developer updates the product, there is a great likelihood that YOUR hacked product that was working, will once again cease to work as the hacks have been overwritten or neglected in the new software build. This may cause you to ask the outside developer to re-hack someone else’s shit.
4. Licenses and stuff. There is so much open-source/open license software out there right now, you rarely run into intellectual property arguments over web software, but say for example you hack someone’s shit and make it 1,000x better than the original commercially available software?? You may end up with some sort of conversation with that overworked software savant that couldn’t get their product to work properly 20% of the time.
Now bottom line, don’t be a knucklehead and buy software that has a forum full of pissed off customers complaining about the product. Attempt to contact the developer in charge and ask them questions BEFORE YOU BUY that may help you gauge just how active the developer is with their project, as well as how ready and willing they will be to help you when you get stuck (and you will) in shit.