The view of how to build software efficiently has changed over the years. The promise of far cheaper labor and a hyper-connected world makes many wonder why anyone would pay what is often viewed as “premium pricing” for “domestic” software development.
One of the things that surprises people about Arc90 is that our development team is right here in our offices in New York City, alongside our project leads, designers and strategists. We’ll often get a “That’s interesting” or “Oh? That’s unusual.” It’s a response that usually leads into a conversation about the nature of conceiving, designing and ultimately building great software.
At Arc90, We Feel Your Pain (In Fact, We Need To Feel Your Pain)
The single most important benefit of building and designing near our clients is, well being near our clients. If you want to deliver something great, team proximity is everything. To get it right, we need to not only have a tight feedback loop with you, we want to become you. This means internalizing all the experience and expertise you bring to an engagement. We don’t just want a “discovery phase.” We want to inherit your instincts, fears and innate knowledge of where things need to go and what pitfalls lay ahead. That’s hard to do across two oceans.
It’s also hard to compartmentalize that dynamic into any single phase. The challenges and unexpected puzzles crop up throughout. This isn’t only about unforeseen “problems” but the inevitable “how can we do this better?” challenges that we can’t help but ask. It’s great to have the client nearby to collaborate on elevating something from passable to truly compelling.
The Value Of First, Second and Third Drafts
When any decision you make needs to be shipped 11,000 miles, it better be the right decision. As we form a strategy and design out an attack plan for an effort, we know it’s going to morph and change and we know there will be missteps along the way. What may feel absolutely sublime in a design comp may fall flat in a prototype. What may shine in a prototype may fizzle out when it’s wired to real data.
We want to be able to make decisions, test decisions and change course, however slightly, as we go. It’s nearly impossible to do that if we’re shipping chunks of an effort in packages halfway across the world. You may well have the most talented group of developers in some far off place, but if they don’t appreciate the rationale and the overarching context of why things are the way they are, you’re going to pay a heavy communication tax.
Ready For This? In-sourcing Is Cheaper
It is a myth that outsourcing is a cheaper way of building quality software. Software can always be built elsewhere, but the basic premise that the early blueprints are 100% dead-on are a fantasy. Once an effort begins, almost invariably, a rat race ensues and the cumbersome task of project managing across geographically dispersed teams kicks in. The result is a frustrating, oftentimes painful endeavor. We’ve seen firsthand how an out-of-synch outsourcing effort can spin out of control and destroy morale. It’s a painful thing to witness.
Great Product 101
Great product hides away all the pain and anguish associated with its inception. It feels organically grown, rather than a visible patchwork of exposed “systems.” To build great product – product that feels intuitive, thoughtful and in tune with the needs of the user – you need the freedom to iterate and be innovative. The tighter the loop, the more room for refinement.
For some efforts, outsourcing may be the right approach. If you can afford to have your product management team, project leads and designers in the same physical location, it can work. If your product is so elaborately defined or prototyped to extreme detail, it may also work. Few companies have either the time or resources to go to such great lengths. Instead, we trudge forward with the resources and time we’ve got.
Ultimately, it’s about bringing product leadership along for the ride. It’s about pairing up the right people – the people that care about the outcome and the people that get you there – all the way through from inception to creation. One of our clients summed up their own struggles with outsourcing: “They just don’t get it.” It wasn’t meant as a jab towards particular talent pools out there. It’s meant to illustrate how truly difficult it is to get everyone in sync throughout an effort.
The world truly is a flatter place today. We are more connected than ever. But connectedness alone doesn’t lay the groundwork for building great product. Until some killer tool comes along that provides a new, more effective way to work together, proximity and tight collaboration between all the players remains the most effective way to build great things.
Deniz said:
I partly don
Matt said:
“But our result show us that it works even better than being all in the same city”
How can you have deluded yourself into believing this? Humans always communicate better in person than over a remote mechanism. Live demos with people sitting in front of you, their body language, their inflections, all this is missed in remote working. And that’s before the cultural barriers of off-shoring even come into play.
If what you claim was remotely true we wouldn’t waste money sending sales people to client sites. There’s so much more to good communication than text and video. Anything else than face to face just increases the likelihood of miscommunication.
There’s a certain type of team that can work well remotely because they’re good at communicating in a way the only others of their ilk can understand. They’re called geeks, they’re a-typical and it only works if there’s a damn good geek-interpreter somewhere in the loop between the geeks and the client. And the geek-interpreters are bloody hard to find.
Scott said:
Just as one should not use words such as “always” and “never”, I think one should also be careful to call something a myth just because your model works another way.
I agree with your premise that “outsourcing” is fraught with opportunity for disappointment. I would say, however, that “offshoring”, if done right, is both highly productive and very cost effective.
The benefits of offshoring are not just restricted to financial, though that is a component to be sure. You also get:
- work being done more or less around the clock
- access to world class talent that you would not be able to use if just using an onshore model
- you are raising the collective standard of living in other parts of the world, allowing other countries to move up the ladder in terms of economic growth and buying power.
I have built software for the last five to six years using both in house and off teams. There is no one right answer. It depends on what you are building, and how you are building it.
I have found that the offshoring model works very well if:
- you have people that can go to the client site, understand requirements, and be able to disseminate those requirements into bite-size chunks
- be good enough at architecture to be able to break systems apart to leverage a global workforce, but still have it work at the end
- be very demanding in terms of availability for consistent times of communication
- be willing to spend the time to review work daily and iterate quickly, rather than spend more time on design up front.
My .02
David Hainlin said:
I agree completely with your post. In my experience, the lack of high context communication / participation with the users is a killer. Another factor I’ve experienced is you cannot ensure continuity with an external team because the provider’s business model or demands may be biased to roll as many junior staff through your project as it can. Doesn’t seem to work well for building a skillful product team (but probably helps the provider grow their collective pool).
The best reason for localizing the development with users (IMHO) is to take advantage of more agile (e.g., scrum) methods which rely on person to person rather than deliverable documents and the like.
So in my experience, two additional factors that can make insourcing a better value -1) local teams may have more business continuity and product motivations, and 2) they can take fuller advantage of agile methods where a key ingredient is frequent user interaction.
Rich Ziade said:
Scott:
I used the word “myth” because I think some automatic assumptions do get made about how outsourcing is just “cheaper” and that the story ends there.
I think the cooling down of the whole outsourcing buzz is testament to a tempered view of outsourcing being a silver bullet. I remember 3-4 years ago, it was all the rage and it was almost assumed as an imperative that work absolutely had to go offshore to survive. I think that sentiment is being tested more and more now (at least from the anecdotal evidence we’re witnessing).
Deniz said:
Sorry the late answer matt, i did not came back somehow.
Well, you are right on some points again. You dont have to be a geek to communicate well and of course the communication part is the most difficult one. But it works better because we bring in different horizons. Having someone sitting in Mx City, guatemala, Switzerland, Urugay and Vienna just makes the whole picture more diverse. the communication has to be worked on, and it works well with communicative people – not necessarily geeks. The creative and innovative part is doubeling through this.
again, with the client direct communication is very important and definitely good to have if somehow possible, because he/she did not have the time to elaborate remote team work, as the teammembers did.
Greetings working from Vienna at the moment, Deniz