So you and the rest of your team are slamming out code, features rolling down the pipeline but you're starting to accrue technical debt and you know that things are slowing down a little bit and the releases are getting buggier and so you ask management for some clean up time. And the response is the answer you always knew you were going to get:
"We can't really push the deadlines back, there are business side concerns to this launch as well."So you shrug and maybe you think maybe you should call your significant other and beg forgiveness for the overtime you're about to commit and then it just gets worse!
"What about if we got you some outside help for a while?"Stereotypes of outside development experiences flash before your eyes - the guy who produces "results" by hacking that can barely even be described as "shortest path" given it'll probably need rewriting twice before it ever hits production; the people who come in and say "of course this will work but first we have to rewrite everything"; even the world famous Brilliant Paula. Or perhaps worse, people who'll sneer at your competency but not ever actually do anything.
Well, I'm here to tell you that it doesn't have to be like that.
Outside development shops can bring substantial value to your process provided they are engaged to work as part of your team, not independently from it.
Brad Hargreaves' recent article When You Should Hire a Dev Shop (other than "never") struck a chord with me, since it outlines a lot of good reasons why to not outsource your primary development in the vast majority of cases - reasons I thoroughly agree with - and yet a significant percentage of Shadowcat's clients are startup or still startup-ish companies and I also thoroughly believe that they made a good choice by hiring us.
So the question is, how do we resolve this apparent contradiction?
The answer is - there is no contradiction. Brad is absolutely right that in almost all cases you need a brilliant team in-house for your project, since they'll be steeped in your business domain and have direct access to the stakeholders (in a small startup this might be early stage customers rather than internal business staff). As Joel Spolsky famously outlines:
If it's a core business function -- do it yourself, no matter what.
However, that doesn't mean that you should do everything yourself.
If you're writing a web app, you're probably going to use a web framework - in perl, Catalyst is probably the most popular and if you're using an RDBMS as a backing store you'll probably also be using DBIx::Class to provide ORM facilities. In ruby, perhaps you'd be using Ruby on Rails. In python, Django. This reliance on open source software is "outsourcing" of a sort - though depending how critical the libraries in question are to your success you may have done more or less research and code reading in the process of selecting it.
The key question, then, to ask yourself, is:
Which parts of my stack are core business functions and which aren't?
The odds are that the finer details of running servers probably aren't, so long as you're confident they'll stay up, so you might push that out to Amazon Web Services. You're unlikely to write your own operating system either (unless you're Google, who by this point effectively have done so several times).
So ... are the details of effective abstraction patterns, or of how to set up a robust deployment infrastructure that works well with your chosen release cycle pattern, or even how to integrate memcached into your ORM part of your core competencies?
I'd argue that they aren't.
What's essential to you is the code that handles your business domain, the code that customers (or stakeholders) directly interactive with to get stuff done. And you're the only people who can do that. On the other hand, while having a well managed process from development through to production is important - and one can very definitely argue that the production deploy is a core competency so you'd better know how to do that one yourself - there's no reason you can't let somebody else handle the details.
You know more about your business domain and core competencies than anybody you can hire.
Outside experts on the technologies will know them better because they're focused on the technology.
Which is precisely where Open Source tied consultancies like Shadowcat come in. We make impedence mismatches between what our clients are trying to create and what the tools they're using were designed for go away by having long experience bending those tools to the needs of projects. We put together strategies for deployment management and then dry run them with clients until they know for sure they could do a deployment themselves in the middle of a hurricane. We teach techniques that we think are applicable to what's being worked on and let our clients decide whether those techniques are what they need right now.
The critical part of that is "let our clients decide" - we always work with an in-house team, and in the cases of clients whose teams are undermanned or just being assembled we work with them to help them build that team out. We also often take on the technology side components of getting new starters up to speed so that existing developers can continue to focus on delivering features - you can't beat the Mythical Man Month problem but you can certainly ameliorate it with a little help.
None of this would work well without a strong team inside the client that knows and cares about their business domain in a way an outside company never can - and the few times we've been persuaded by clients to try and become primary developers of code with only business staff working in house, it's been an unmitigated disaster. Which brings two more rules:
An open source consultancy helps you apply your chosen technologies to your chosen problem in the way that makes it easiest for your team to make progress.
A competent consultancy makes an overpriced incompetent contract development house.
So maybe my definition of a "dev shop" is stretching it a little compared to the post I was inspired by, but I think there's interesting thoughts here about how you deploy and best use your resources within a startup - and hopefully you'll look at the outsourcing possibilities in a new light.
If you want to flame me for posting borderline advertorial content, tell me I'm wrong and need to update the post with your essential point (I might!) or are feeling inspired and want to talk about how Shadowcat could work with your team to achieve the sort of good things I describe, I'm available as always on mst@shadowcat.co.uk.
For the moment, however, I'm very aware that it's not many hours until a deployment process we've put together and dry-run with a client's team a few times is going to have its first real live test tomorrow with their client watching, so I'm off to get some sleep, happy in the knowledge that I got through this entire post without using the word synergy once.
... ah, nuts.
-- mst, out.