Developers, you are the last line of defense

One of the main reasons all of development isn't outsourced is that it's hard to replace an in-house developer's personal investment in the business, cultural understanding, and market understanding. Additionally, communication is typically orders of magnitude more efficient.

As an in-house developer, you have a clear responsibility to give technical feedback on product designs, but your responsibility doesn't stop there. You are the last line of defense for your company's product or service. If a bad feature makes it past you, it gets released. If you're implementing a feature that makes no sense for your target market, or is spammy, or rubs you the wrong way, it is your obligation to speak up.

There is a natural set of responsibilities and checks for a product company. The management team sets the product vision. The product team specifies the product vision. The development implements the product specification.
There are two ideal outcomes from you defending your product:
  1. You convince the product team or your manager that there's a problem.
  2. Your product team or manager convinces you that the specified solution applies well for your market, use case, or company culture.
Neither situation is bad. In #1, you make them think more about the problem and potentially reach a better solution. In #2, you learn more about your product and market allowing you to better defend your product in the future from poor designs. 

Alternatively, you could learn that your company doesn't accept feedback like this. If that is the case, you are likely undervalued, and your company should probably be outsourcing the work (and likely will in the future). You should start considering other employment options.

Remember, if you release a bad product or feature, it is your fault. "I just built what was specified," is not an excuse for full-time, in-house developers. You build the product, you understand its details, and you release it to customers. It's your duty to defend it.

Self promotion

I run a company on a mission to put recruitment agencies out of business. We host speed interviewing events using video chat where 20 job seekers talk to 20 companies for 5 minutes each. If you're looking to evaluate the software job market or looking to hire, check out Hirelite.com.
19 responses
After you get the recruitment sharks can you go for estate agents and bus drivers?
@andrewmcgregor - Hopefully. http://www.redfin.com is doing some great things for the real estate industry. Haven't heard of anything in the bus service industry yet ;-)
Actually, if you are interested in putting an end to outsourcing, just write software that enables US Companies to outsource different types of jobs. Nobody in the US seems really concerned about development jobs going overseas other then developers. ,, So, in response to that, just write software and connect with companies overseas to enable tasks like accounting, legal, radiography, project management, and any clerical job to be outsourced.

When this happens, it won't be strictly a programmer problem, it will be their problem too. It'll be great.

@Biff - We're not trying to put an end to outsourcing. There are definitely times when it is appropriate. We're trying to get rid of recruitment agencies.
Remember, if you release a bad product or feature, it is your fault. "I just built what was specified," is not an excuse for full-time, in-house developers. You build the product, you understand its details, and you release it to customers. It's your duty to defend it.
I don't agree that communication is necessarily more efficient. (Granted, you did write "typically" but I think that is more assumption than anything else.)

However: I will say that it takes a company that is willing to commit to working with remote developers. Those that have made the effort have often found it to be a very good arrangement. If you do it wrong, though, you will end up with just as you say: poor (or at least poorer) communication.

The last two full-time jobs I held (that is, aside from part-time work, contract work, and self-employment) were exactly the opposite of what you state.

At the first one, I would arrive at the office every day, go to my cubicle, and work all day, scarcely seeing or communicating with my co-workers or management at all. Other than short a meeting once a week to define tasks, there was very little communication there at all.

At the other one, even though I was several hundred miles from the main office, the team members communicated every day, via Campfire and IM and telephone. We gave each other feedback and coordinated our efforts. It was a much more pleasant atmosphere and a lot more productive work
got accomplished.

Maybe that isn't "typical". But again, in my experience, being an in-house employee is not necessary at all, or even necessarily desirable. You can work for a company in Chicago and live in Arizona, if you like, and IF DONE RIGHT, communications are hardly "an order of magnitude" worse. They can be even better.

@Lonny - Great counter-example. In your second example, were you an employee of the company? Or were you at a firm working for a client?

Perhaps, it's not as much about onsite vs remote, but "employed by the company" vs "client work through an intermediary".

I was a full-time employee, with benefits. So it wasn't "outsourcing", per se.

I understand that your intention is to drive out recruitment firms. I just wanted to pass on my experience.

I see a need because I work a lot with Ruby and Rails. A lot of cities (I can cite Seattle, Portland, San Francisco, and Chicago as definite examples) have been complaining about a lack of qualified Ruby people. But there are lots of qualified Ruby people. They're just not in Seattle, Portland, SF, or Chicago! And many don't really want to move there.

Working remotely can be a very good experience for both the company and the employee. More companies should consider hiring remote workers. And it doesn't have to be contract. Full-time remote employees can work out just fine, if the company sets it up properly and commits to it.

If you want to do it properly, all developers should have: (1) an Instant Messaging account (some are now nearly universal; the one I use interacts with Jabber, ICQ, Yahoo, MSN, AIM, GTalk, LiveJournal, and MobileMe). (2) Some real-time multi-person collaboration tool, whether that's Campfire, IRC, or some other service. (3) A phone line to the office, even if it's Skype. (4) The ability to conference call or conference video chat. And of course, last but not least, an SVN or Git repository is a must.

Pardon me, but I did leave something out. Those things are necessities for managers and immediate supervisors as well, of course. Management must be in the loop.
Great points for all tech companies to think about. I really appreciate the point about thinking things through, too many of the folks I start working with have not done that and I end up starting over. I recently posted here as to some of the problems I encounter.http://venturefizz.com/blog/selling-new-technol...
9 visitors upvoted this post.