I went to a workshop a few weeks ago, called “Code Quality – Unit Tests” – sponsored by Avangate. What I have seen there confirmed what I already believed – that working in outsourcing won’t teach you how to build your own product.
Before diving into the arguments, I should clarify a few things. First of all, I’m referring to the technical aspects of a project, I’m not talking about the business challenges that every startup will encounter in its path to product market fit. Second, these thoughts come from my experience working in my own agency for almost 9 years and developing web projects for small and medium clients. Third, even though I’m generalizing, it’s true that some products are not so technically challenging and can be developed easier. But Appticles.com, our SaaS platform, is not one of those.
Getting the job done with what you know
Outsourcing is all about getting the work done, so you can invoice the client. Most outsourcing companies do not have corporations as clients, so usually the “job” is pretty basic: implementing a website, maybe based on an open-source framework/CMS, or an app. The client will always try to lower the budget, usually without much consideration for the consequences this will have on the code quality. If the end result is a functional project, with very few or no bugs, why should they care about what goes on behind the curtain?
This is the reason why so many projects are developed on existing frameworks, like WordPress. It’s very difficult to explain to a client why hacking into the code is most of the time a very bad idea, as it will not allow for future platform updates. They will see this issue further on, maybe if something bad happens – like their website being hacked because it was missing an important security patch.
Lower quality expectations from clients will in turn get you stuck in what I like to call “The Comfort Zone“. You don’t need to learn new stuff if you know the stuff that will get those projects done. Of course, you can always use your free time for research and study, but it is much easier to just sit on your ass and try to solve everything with the knowledge that you already have. On the other hand, you can’t take on more difficult projects because you don’t have the skills required for implementing them. Hence – a loop. You are stuck developing the same type of projects for the same type of clients, while everyone around you is evolving.
The saddest part of it is that some people don’t even realize they are stuck, which makes the whole situation even more dangerous. If you find yourself involved in a tech startup like I have, it will not take you long to realize you have become obsolete and it’s high time you change your game.
Nobody cares about tests
It is almost impossible to sell unit or integration tests to a client because it will significantly increase the price – unless they have the technical knowledge to understand why tests are important, but such cases are rare. Most of the time, the guy calling the shots will not have a technical background.
Also, testing is probably the most ignored and detested activity of a developer’s job. Nobody likes to write tests and why should they? Building a cool feature is much more exciting.
I have managed and developed more than 100 small and medium web projects and I haven’t written a single test during that time. You might think that the projects we made were of poor quality, but they weren’t. It was just so that the technical requirements were never that complicated and functional testing was enough. It was also fine when our product was in the early stages and I wouldn’t recommend ever writing tests for an MVP. But, for us, it is not fine anymore.
Our platform has grown. It is impossible to manually test every single feature when making a release and hiring an army of testers is not an option. So, the only safety net that we can cast are tests – as many and as detailed as possible.
There’s also a nice term for it, it’s called “technical debt”. It is the polite way of saying “our testing & automate deployments suck and we need to do something about it before we screw things up”.
I still have a feeling of uselessness when I write tests, which I do so quite often these days. I have despised them for so long that sometimes it is hard for me to see their usefulness, until I make a release and I realize that the little buggers do make life easier.
Little or no contact with the end user
It’s easy to say that a client is an idiot when you don’t agree with the way he wants things done and you don’t have to deal with him directly. Sometimes, their requests can be absurd. But, when someone uses your product and it doesn’t do what you said it does, you are the idiot.
In outsourcing, the development team doesn’t deal much with the client. There’s always some kind of buffer – the project manager, the company’s owner, etc. This is different for freelancers, so I’m talking about teams, not individuals. In a tech startup, every member of the team should answer to support. There is no hiding from it and it can be gruesome. Not everyone is all that nice, even if they have a just cause or not, especially when there’s money involved. Most people will not read the FAQ section and will get angry if something doesn’t work as expected, but dealing with the onslaught that follows is everyone’s job.
Outsourcing will put money on the table
On top of everything, outsourcing can be a very good business. Compared to a startup, outsourcing companies also have a more predictable path, if they do a good job and manage to secure some recurring clients they will not face the risk of running out of money. A lot of tech startups from Eastern Europe have their roots in outsourcing companies, so from this point of view, it’s obvious that outsourcing can be a good source for financing spin-offs. Overall, it can be a positive experience, as long as you are perfectly aware that you have to watch out for the negatives and plan ahead.