Now that ScoutDocs is in the WordPress plugin repository, I’d like to share some lessons I learned making it. Every project teaches me something — this one taught me a lot.
What is ScoutDocs? ScoutDocs is a WordPress plugin that adds simple file-sharing to your WordPress site. You can upload files (which are stored securely in the cloud and served over HTTPS via a global CDN), and share them with individuals or groups of individuals. Email notifications are also handled by the ScoutDocs service, getting around the issue of reliable email delivery on a shared host. You can require that recipients accept or decline the files you’ve shared, e.g. so you can see which of your employees has seen the new employee handbook. Instead of files living as email attachments (if they even fit) or off on some third-party site, people can access them on your site.
In this weekly series, I’m going to cover:
- WordPress Rest API
- PHP 7
- Build tools
- Unit testing
First up, lessons learned about outsourcing.
When we started making ScoutDocs, the question was raised as to whether it would be beneficial to outsource any of the coding. My time was valuable and limited, so I figured that if I had another developer code while I slept, I could spend an hour in the morning reviewing the code and giving them direction for the next workday. I had visions of quickly scanning code while my morning coffee brewed, twirling an invisible moustache, and muttering “good, good.”
This is not what happened.
The issue I quickly ran into was that for any nebulously defined problem, someone else’s solution was unlikely to match what I wanted. Their assumptions would not be the same as mine. As a result, the odds of me being happy with their solution were very low.
I spent a lot of time rewriting code.
And because I was spending all my time “fixing” the code I wasn’t really looking at the product as a whole.
When the contractors were done, my ScoutDocs partners and I looked at it, and we realized that it… was bad. Forget code quality, which despite all my vain reshuffling was still lacking: what we had was just overall a terrible user experience. Rather horrifyingly, we admitted that what we needed to do to give it the user experience we wanted was nothing short of a total rewrite.
I rolled up my sleeves, learned React, and rewrote ScoutDocs until almost nothing of the original code and user experience remained.
So was outsourcing a waste? Not completely. Some code was retained, mostly relating to the Amazon S3 interface. I was glad that someone else had experienced the singular joy of spending an eternity lost in a maze of Amazon Web Services documentation and confusing code samples. Additionally, if I had set out to build the initial version of the code, it would have taken a lot of my time (which I did not have much to spare), and might have meant that our horrifying realization would have been delayed for several months.
Knowing what doesn’t work is valuable, even if you have to throw it away. That’s mostly what we had gotten for our money: figuring out what didn’t work. If outsourcing can get you to these realizations sooner or for less money, it might be well worth it.
As I rewrote the software, my partners asked me a few times if I regretted outsourcing. I didn’t, for the above reason, but also because outsourcing had solved some of the coding issues that would have been a slog for me. However, if I was doing it all over again, I would have done more work upfront to identify specific, well-defined tasks that I wanted to outsource.
Delegation makes sense when the task is well-defined. At the extreme, you could spend so much time redoing work and asking for revisions that you’d have been better off just doing it yourself. If you can specify exactly what constitutes success in a task, and the time it takes you to specify that is much less than the time it would take you to do the task, outsource it.
Check back next week for my thoughts on rewriting ScoutDocs in React.