<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Pervasive Code &#187; labor</title>
	<atom:link href="http://www.pervasivecode.com/blog/category/labor/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.pervasivecode.com/blog</link>
	<description>Jamie Flournoy's Software Development Blog</description>
	<lastBuildDate>Mon, 26 Jul 2010 05:29:53 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Software Project Estimation: Inaccurate and Unavoidable</title>
		<link>http://www.pervasivecode.com/blog/2008/08/06/software-project-estimation-inaccurate-and-unavoidable/</link>
		<comments>http://www.pervasivecode.com/blog/2008/08/06/software-project-estimation-inaccurate-and-unavoidable/#comments</comments>
		<pubDate>Thu, 07 Aug 2008 04:04:04 +0000</pubDate>
		<dc:creator>Jamie Flournoy</dc:creator>
				<category><![CDATA[labor]]></category>
		<category><![CDATA[management]]></category>
		<category><![CDATA[process]]></category>
		<category><![CDATA[strategy]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://www.pervasivecode.com/blog/2008/08/06/software-project-estimation-inaccurate-and-unavoidable/</guid>
		<description><![CDATA[This is a follow up to On Our Project, We&#8217;re Always 90% Done.
The coder is the one on the hook for long nights, weekends, and stress-related health problems if the estimates suck. It&#8217;s in your interest to exert as much control over estimation and scheduling as you can. If you&#8217;re not making the estimate, someone [...]]]></description>
			<content:encoded><![CDATA[<p>This is a follow up to <a href="http://www.codinghorror.com/blog/archives/001161.html">On Our Project, We&#8217;re Always 90% Done</a>.</p>
<p>The coder is the one on the hook for long nights, weekends, and stress-related health problems if the estimates suck. It&#8217;s in your interest to exert as much control over estimation and scheduling as you can. If you&#8217;re not making the estimate, someone is making it for you.</p>
<p><span id="more-76"></span></p>
<p>If you think about it, <strong>you&#8217;re opting out of an ongoing salary negotiation process</strong>. You&#8217;re going to work more for the same amount of money, and worse yet, you&#8217;re going to have to squeeze that work into the same amount of time, under stressful conditions. Why would you do that?</p>
<p><a href="http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351">McConnell&#8217;s &#8220;Software Estimation&#8221; book</a> addresses this problem of wildly inaccurate early estimates quite well. I highly recommend it. In a nutshell, estimates need to carry error bars, so early estimates would be given but with a disclaimer of +/- 100% (or more!), and later estimates get closer to being correct.</p>
<p>You will have to manage expectations, though. Human nature leads to the shortest end of the date range becoming the remembered end date, the guess being remembered as a promise, and the latest feature set being remembered as if it were the original feature set.</p>
<p>This is a big reason to hire a good project manager: they&#8217;re there to facilitate the change control process, or planning game, or whatever you call it in your organization when the paying folks want more stuff, and the PM reminds them that need to pay more and wait longer in order to get more out of the dev team. A good project manager can make a huge difference to the stress level and likelihood of success of a project.</p>
<p>It&#8217;s psychologically icky for developers to have to participate in the estimation and scheduling process &#8212; &#8220;eww, it&#8217;s a non deterministic domain with lots of ill-defined inputs!&#8221; &#8212; and I&#8217;ve seen some managers play head games like &#8220;Oh, you need more time? I thought you were really good at programming&#8230; I guess not&#8230;&#8221; to try and manipulate developers into working nights and weekends out of a sense of guilt or wounded pride. But you need to suck it up and keep providing status updates and reminding people how the process works, because you-the-programmer are the expert on the nature of programming.</p>
<p>Yes, it&#8217;s more like Lewis and Clark or the Apollo project than like building a house, and there are just going to be a lot of surprises, but you can still provide a framework and exert a tremendous amount of control over how the team will operate. Things like whether you plan to build a technology proof-of-concept to make sure your architecture doesn&#8217;t suck, or whether you intend to spend lots of time writing automated tests and doing daily code reviews in order to control that horrible &#8220;bug fixing&#8221; phase toward the end are in your hands if you participate in the estimation process. You&#8217;re being offered an opportunity to make sure that all those important tasks like performance testing and cross-browser testing and writing an installation guide and an operations manual for the sysadmin get done. <strong>It doesn&#8217;t matter if the estimates for those tasks are completely wrong at first &#8211; what matters is that they&#8217;re on the list.</strong></p>
<p>And really, the largest battle you&#8217;ll probably have to fight is the one over scope creep: we can&#8217;t launch until it has all the original features plus all these additional changes and new features perfectly working, but we need to launch tomorrow. That&#8217;s also human nature, and you need to train people to release early and often. Agile methodologies can help here, if you can get your software working and stable from a very early point in the project, and keep it that way. Then you probably have a launchable product very early, and you can just push highly-desired features into post-1.0 releases.</p>
<p>In any case, a list with a bunch of crappy numbers and low confidence factors is a lot better than no list, or a one-item list with a crappy number and an implied 100% confidence factor.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.pervasivecode.com/blog/2008/08/06/software-project-estimation-inaccurate-and-unavoidable/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Bad, Bad Code</title>
		<link>http://www.pervasivecode.com/blog/2007/08/04/bad-bad-code/</link>
		<comments>http://www.pervasivecode.com/blog/2007/08/04/bad-bad-code/#comments</comments>
		<pubDate>Sat, 04 Aug 2007 22:21:02 +0000</pubDate>
		<dc:creator>Jamie Flournoy</dc:creator>
				<category><![CDATA[humor]]></category>
		<category><![CDATA[java]]></category>
		<category><![CDATA[labor]]></category>
		<category><![CDATA[management]]></category>
		<category><![CDATA[offshoring]]></category>
		<category><![CDATA[outsourcing]]></category>
		<category><![CDATA[sql]]></category>
		<category><![CDATA[testing]]></category>

		<guid isPermaLink="false">http://www.pervasivecode.com/blog/2007/08/04/bad-bad-code/</guid>
		<description><![CDATA[I&#8217;ve written before about tips for offshoring. One specific thing I said to watch for is the bait-and-switch of talent: during the sales process you&#8217;re shown rockstars, but the real code you get is written by clueless newbies. When you set up a project such that you&#8217;ve minimized the cost per hour of development, but [...]]]></description>
			<content:encoded><![CDATA[<p>I&#8217;ve written before about <a href="http://www.pervasivecode.com/blog/2007/02/20/tips-for-offshoring/">tips for offshoring</a>. One specific thing I said to watch for is the bait-and-switch of talent: during the sales process you&#8217;re shown rockstars, but the real code you get is written by clueless newbies. When you set up a project such that you&#8217;ve minimized the cost per hour of development, but you don&#8217;t have anyone checking the work product (i.e. code reviews) coming from the subcontractor, very bad things happen.<br />
<span id="more-40"></span><br />
Here&#8217;s a doozy: <a href="http://www.discursive.com/blog/2007/07/in-2007-people-are-still-writing-jsp.html">In 2007, people are still writing JSP like this&#8230;</a></p>
<p>Check out the 4th message in the thread, with the big code sample.</p>
<ul>
<li>Table based HTML layout, and no CSS at all? Check. Heck, the table width % values don&#8217;t even add up to 100%.</li>
<li>SQL in the JSP? Check.</li>
<li>Making a new JDBC connection for each page view, instead of using a connection pool? Check.</li>
<li>Unescaped strings in the SQL? Check. (Not strings coming from the browser in this particular JSP page, but you don&#8217;t know where those strings originate. Why wouldn&#8217;t you escape it just in case?)</li>
<li>Failing to use a prepared statement? Check. (That would also solve the escaping problem.)</li>
<li>Using a string literal in a SQL or command line context, so you can&#8217;t log it beforehand? Check. Even better, the code makes a query string first, prints it (commented out), and then <i>uses a different string in the actual query</i>. Nice!</li>
<li>Using the JdbcOdbc driver? Check. (From <a href="http://java.sun.com/docs/books/tutorial/jdbc/basics/connecting.html">Sun&#8217;s JDBC Basics</a>: The JDBC-ODBC Bridge driver provided with JDBC is recommended only for development and testing, or when no other alternative is available.) I&#8217;m guessing that the use of ODBC here is the only reason why the database username and password aren&#8217;t embedded in the code sample and posted for all to see.</li>
<li>Empty exception catch block? Check.</li>
</ul>
<p>I&#8217;d have a hard time coming up with a fake example of bad code that was worse.</p>
<p>But wait, <a href="http://forum.java.sun.com/profile.jspa?userID=908177">what else has this person asked about</a>?</p>
<p>No way. Yes! <a href="http://forum.java.sun.com/thread.jspa?threadID=5156702&#038;messageID=9593464#9593464">Error in Socket and File Writing</a>!<br />
The post includes the router&#8217;s username and password, and its configuration including:</p>
<ul>
<li>Its IP address, and all of the routes it contains, and all of its interfaces and where they go</li>
<li>A couple of other passwords stored in the router</li>
<li>A crypto key that appears to be to a VPN (looks like a pre-shared key, meaning not a public key but one that must be kept secret)!</li>
</ul>
<p>I&#8217;m not gonna say &#8220;you get what you pay for&#8221; since open source software has served me very well, but I will say that you get what you bargain for. If your bargain includes not looking at the work product of the people you hire, which is to say, hiring the cheapest people available and not supervising them, you&#8217;re not going to be happy with what you get.</p>
<p>Of course, this <em>could</em> have been written by a U.S. citizen who works in a cube on-site and makes $200/hour. Point is, hire carefully, and supervise your workers. It seems simple when put that way, but it&#8217;s amazing how often companies are willing to hire software subcontractors carelessly (solely on price?) and then pay little or no attention to the resulting work, when the arrangement involves offshore outsourcing.</p>
<p>By the way, the IP addresses in the original post (with the awful code sample) are listed next to the name &#8220;Areva&#8221;, implying that this code is part of a project for Areva. Who is Areva? <a href="http://www.areva.com/servlet/operations-en.html">They make nuclear power plants</a>. Sweet dreams!</p>
]]></content:encoded>
			<wfw:commentRss>http://www.pervasivecode.com/blog/2007/08/04/bad-bad-code/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>Great contracting advice from Josh Berkus</title>
		<link>http://www.pervasivecode.com/blog/2007/06/27/great-contracting-advice-from-josh-berkus/</link>
		<comments>http://www.pervasivecode.com/blog/2007/06/27/great-contracting-advice-from-josh-berkus/#comments</comments>
		<pubDate>Wed, 27 Jun 2007 07:34:39 +0000</pubDate>
		<dc:creator>Jamie Flournoy</dc:creator>
				<category><![CDATA[databases]]></category>
		<category><![CDATA[labor]]></category>
		<category><![CDATA[management]]></category>
		<category><![CDATA[outsourcing]]></category>
		<category><![CDATA[postgresql]]></category>

		<guid isPermaLink="false">http://www.pervasivecode.com/blog/2007/06/27/great-contracting-advice-from-josh-berkus/</guid>
		<description><![CDATA[Most of his rules are applicable to generic software consulting.
Josh&#8217;s Rules (of Database Contracting)
]]></description>
			<content:encoded><![CDATA[<p>Most of his rules are applicable to generic software consulting.</p>
<p><a href="http://blogs.ittoolbox.com/database/soup/archives/joshs-rules-of-database-contracting-17253">Josh&#8217;s Rules (of Database Contracting)</a></p>
]]></content:encoded>
			<wfw:commentRss>http://www.pervasivecode.com/blog/2007/06/27/great-contracting-advice-from-josh-berkus/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>The Mozilla Platform&#8217;s Catch-22 Problem</title>
		<link>http://www.pervasivecode.com/blog/2007/04/30/the-mozilla-platforms-catch-22-problem/</link>
		<comments>http://www.pervasivecode.com/blog/2007/04/30/the-mozilla-platforms-catch-22-problem/#comments</comments>
		<pubDate>Mon, 30 Apr 2007 23:00:58 +0000</pubDate>
		<dc:creator>Jamie Flournoy</dc:creator>
				<category><![CDATA[C++]]></category>
		<category><![CDATA[Firefox]]></category>
		<category><![CDATA[JavaScript]]></category>
		<category><![CDATA[Linux]]></category>
		<category><![CDATA[Mac]]></category>
		<category><![CDATA[Mozilla]]></category>
		<category><![CDATA[Thunderbird]]></category>
		<category><![CDATA[Windows]]></category>
		<category><![CDATA[XML]]></category>
		<category><![CDATA[labor]]></category>

		<guid isPermaLink="false">http://www.pervasivecode.com/blog/2007/04/30/the-mozilla-platforms-catch-22-problem/</guid>
		<description><![CDATA[Starting with Netscape 4.5, I&#8217;ve used Netscape, then Mozilla, then Thunderbird for email. I have a similar relationship with Firefox. I&#8217;ve watched with great hope and been disappointed over the years as Thunderbird bugs that really annoy me just&#8230; stay. I think I know why. It&#8217;s because Firefox and Thunderbird are built in such a [...]]]></description>
			<content:encoded><![CDATA[<p>Starting with Netscape 4.5, I&#8217;ve used Netscape, then Mozilla, then Thunderbird for email. I have a similar relationship with Firefox. I&#8217;ve watched with great hope and been disappointed over the years as Thunderbird bugs that really annoy me just&#8230; stay. I think I know why. It&#8217;s because Firefox and Thunderbird are built in such a way as to create a catch-22 situation &#8212; one that actually discourages new contributors.<br />
<span id="more-23"></span><br />
Here&#8217;s a good example of a bug that would seem to be trivial to fix: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=271222">&#8220;Entire message&#8221; quick search criteria is only the body</a>. You can&#8217;t search the entire message in Thunderbird. Can&#8217;t do it. Never been possible, as far as I know. Lots of people noticed it; it&#8217;s been marked as an &#8220;enhancement&#8221; in &#8220;New&#8221; status for years, even though it&#8217;s quite obviously a bug in my opinion. So, go to the source code, find the part where it decides what parts of the body to search, and make it search the whole thing. Should be easy, right?</p>
<p>Hell no. Firefox and Thunderbird are built using an <a href="http://www.mozilla.org/docs/#core">incredibly complicated set of tools and technologies</a> created by the Netscape and Mozilla folks, specifically for the purpose of building Firefox and Thunderbird.</p>
<p>Low-level stuff is written in C++, but if you know C++ already you still have to learn their coding standards and class libraries. Yeah, it&#8217;s great that they have coding standards and libraries; I&#8217;m just sayin&#8217;, that&#8217;s more stuff you have to learn in order to write a single line of low-level code.</p>
<p>High level stuff is in a combo of JavaScript and XML. Of course you have to learn the XUL platform stuff, so just knowing JavaScript and XML isn&#8217;t sufficient. You&#8217;ll also probably need to learn to use the low-level classes from the XUL side, so that you can get anything done.</p>
<p>Now if you want to actually build it, you&#8217;ll also need to understand their build system, and maybe their installer. You might need to learn how their help system, documentation system, internationalization sytem, etc. etc. work.</p>
<p>Now, I&#8217;m in awe of the monumental amount of new and working code that the Mozilla community has created. But the problem is just that: they built this huge application stack, and in order to get working on Firefox or Thunderbird, you have to learn a big chunk of that stack.</p>
<p>In theory, this wouldn&#8217;t be any more of a barrier than if they had coded to a single platform&#8217;s GUI widget set, class library, etc. But if I were to learn .NET and Visual Studio, or Cocoa, or GTK+, I would then have skills that I could use to work on thousands of other applications, either open source or commercial. That&#8217;s because those technologies are designed for general purpose application development.</p>
<p>The Mozilla application platform, however, has no life of its own outside of Mozilla. There&#8217;s an effort to extract it and make XULRunner a viable standalone platform that you could build your own XUL applications on, but that&#8217;s currently just a &#8220;stable developer preview&#8221;. What that means is that it&#8217;s still not suitable for use if you wanted to, say, <a href="http://www.songbirdnest.com/development">build your own iTunes killer</a> with it. It&#8217;s almost there, and maybe if you throw a lot of effort at it you could hack it so it&#8217;s usable, but as-is, it isn&#8217;t readily useful.</p>
<p>So, when a developer (such as myself) looks at this technology set, they ask themselves the question, &#8220;can I justify spending this much time learning all this stuff just to fix a little annoying bug?&#8221; If you spend a week or two downloading and learning and hacking and that gets you a certain amount of skill with the technology set, was it worth it? Maybe you could go get a job working with this technology set, except almost no one else is using it, not even open source projects.</p>
<p>When a corporation looks at this technology set, they have to ask a similar question: &#8220;is this the platform that will give me the best bang for my developer buck?&#8221; If they invest the time and money in hiring developers to work on this mostly-complete platform, so that they can then build an application with it, will it pay off? What about alternatives? Will the pool of available developers be so small that the project will fail before it starts?</p>
<p>These are not insurmountable barriers; some folks know some of these technologies already or only want to work on a corner of the application, so the overhead is smaller. Or, they may really want to work on Firefox or Thunderbird very badly. For an employer or open source project, their goals may match the goals of the original platform designers very well, in which case the payoff of using the Mozilla platform would be much higher than if you were (for example) making a Windows-only IM client.</p>
<p>But the barriers do exist, and they discourage the platform and the applications built with it from being improved. Developers don&#8217;t want to spend all that time learning things they can&#8217;t use elsewhere, and employers don&#8217;t want to pay developers to fix the platform so that other projects could find it useful. <a href="http://developer.mozilla.org/en/docs/XULRunner_Hall_of_Fame">A few projects do exist</a> and obviously somebody somewhere is working on Thunderbird bugs, but for a platform this sophisticated with this much mindshare (via Firefox), it&#8217;s remarkably unsuccessful in terms of adoption by developers.</p>
<p>All it would take to fix this would be some cash. Somebody could donate (or spend, in pursuit of a business goal) money toward the completion of XULRunner for general use, and toward clear and useful beginning developer documentation for the rest of the Mozilla platform.</p>
<p>Any takers? I could thrown in a hundred bucks or so, but I have a feeling this is more like a $50,000 undertaking. Otherwise we&#8217;re stuck waiting for Joost and a handful of others to slowly move it along.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.pervasivecode.com/blog/2007/04/30/the-mozilla-platforms-catch-22-problem/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Tips for Offshoring</title>
		<link>http://www.pervasivecode.com/blog/2007/02/20/tips-for-offshoring/</link>
		<comments>http://www.pervasivecode.com/blog/2007/02/20/tips-for-offshoring/#comments</comments>
		<pubDate>Tue, 20 Feb 2007 10:53:05 +0000</pubDate>
		<dc:creator>Jamie Flournoy</dc:creator>
				<category><![CDATA[labor]]></category>
		<category><![CDATA[management]]></category>
		<category><![CDATA[offshoring]]></category>
		<category><![CDATA[outsourcing]]></category>
		<category><![CDATA[process]]></category>

		<guid isPermaLink="false">http://www.pervasivecode.com/blog/2007/02/20/tips-for-offshoring/</guid>
		<description><![CDATA[Having just read Why you need to get rid of your freelance developer ASAP, and the comments under it, I can see that people are really clueless about offshoring. It&#8217;s a magic box that you put pennies in, and great code comes out a few weeks later!
Having worked for a few companies that sold themselves [...]]]></description>
			<content:encoded><![CDATA[<p>Having just read <a href="http://www.carsonified.com/misc/why-you-need-to-get-rid-of-your-freelance-developer-asap">Why you need to get rid of your freelance developer ASAP</a>, and the comments under it, I can see that people are really clueless about offshoring. It&#8217;s a magic box that you put pennies in, and great code comes out a few weeks later!</p>
<p>Having worked for a few companies that sold themselves as &#8220;a magic box that you put millions of dollars into, and great code comes out a few weeks later&#8221;, I know that this is a serious misconception. Subcontracting is fraught with peril. Offshore subcontracting is fraught with more peril, but it costs less per hour. In both cases, the peril is avoidable, but avoiding it requires that you manage the relationship carefully.</p>
<p>I&#8217;ve worked with offshore teams on a couple of occasions, and in one case I was fortunate enough to get sent overseas to work with the team in their own offices. I think I probably have more direct experience with offshoring than most developers or technical project managers, and I&#8217;ve seen how offshored projects can go awry, so I thought I&#8217;d share some tips for those of you considering offshoring a software project, or those involved with such a situation already.<br />
<span id="more-15"></span></p>
<p>One thing to think about first is whether you&#8217;ve really looked for folks locally. Pretty much everywhere I&#8217;ve worked, the management has been vehemently opposed to posting a public job listing. Simply spending <a href="http://www.craigslist.org/about/job.boards.html">$75 or less on Craigslist</a> was too much to spend for someone who&#8217;d probably be paid about $75/hr. Seriously. I&#8217;ve basically been limited to finding people I know, from past work or a mailing list or LinkedIn, and if nobody is available, panic! We need more people but there&#8217;s noooobody out there! Really? Have you tried?</p>
<p>A second question to ask is whether you could use a part-time (fixed # of hours/wk) or freelance person, and if they have to work in the office or not. If you&#8217;re about to hire someone thousands of miles away in a different time zone, you might want to make sure there&#8217;s not someone in town who just doesn&#8217;t feel like commuting but who&#8217;ll answer the phone during your business hours, or if there&#8217;s someone with a kid to take care of, who would be happy to work their butt off 5 hours a day in the office, but who needs the rest of their day to spend with the kid. Remember, you&#8217;re considering adopting a serious amount of communication overhead in order to get someone to work for you; you might do better to just find a 1/2 time person who is in the next room for a big chunk of each day.</p>
<p>Anyway, let&#8217;s assume you&#8217;ve exhausted those options and you&#8217;re going to definitely hire some folks in a foreign country far away.</p>
<p>Here are some questions to ask about the specific situation you&#8217;re evaluating, some of which are similar to things you&#8217;d want to ask about non-offshored situations.</p>
<p>Can you fire the developer without firing the project manager? Or are they a team that you have to fire as a unit, and lose all institutional knowledge? This gets even worse as the team gets bigger. Can you afford to can the whole development organization if you don&#8217;t like the way things are going? In other words, are you clear on whether you&#8217;re hiring a PM and having them hire developers in turn, vs. hiring a company that will act as a subcontractor?</p>
<p>Will the project manager fire the developer and find someone better, if the PM determines that the developer is not working out? Or will they try to cover up for it, or not worry about it since productivity is not their incentive, but keeping billable hours high is? Bear in mind that you may be paying the PM&#8217;s company one rate and that the developers may be paid 1/2 of that, and both you and the developers may see that as a really desirable hourly wage. If you think the PM works for you, then the developers should be paid by you, not by the PM, or at least you and the developers should have agreed on what the PM will pay them. Skimming contractor wages is common practice in the US, too, and depending on how extreme it is, it can create serious incentives for the PM to find new and inventive ways to cheat you.</p>
<p>Will the team&#8217;s primary language be the primary language used in your source code, and if so, will that limit your options if you decide to fire them and hire someone else? This isn&#8217;t a big issue for India, China, and Russia, but for some languages, you might have a very hard time finding another team that can read and understand the source code. You might also find that it&#8217;s impossible to integrate a local developer into your team because they only speak your language, not the language of the offshore team.</p>
<p>Are you sure they&#8217;re only working on your project, full time, and billing you their actual hours? Again, 150% of a low wage for you may not be a lot of money, but to them it might be livin&#8217; large, and worth the risk of getting caught padding hours. As far as my moderate research can tell, there&#8217;s no systematic, reliable, direct way to measure programmer productivity (not that people haven&#8217;t been trying for decades to come up with a way to do this), so you pretty much have to have someone on your end working closely with the team who can make a subjective judgement as to whether they really need 12 weeks to do something, or if 8 people are really working on your project all day every day on their end, or if they&#8217;re just scamming you.</p>
<p>Do you know that the developer you thought you hired is the same person who is coding for you? This is a textbook US consulting company scam: bring in the rockstars with the stellar resumes for the sales pitch, and then gradually roll them off onto the next new project, backfilling with clueless newbies, at the same billable rate as the rockstars.</p>
<p>Of course, falsified resumes are a problem too, just as they are here. If the company is in another country, they may do things like making up impressive-sounding universities and companies to pad resumes, or just copying someone else&#8217;s resume and putting their name on it. I have had a resume sent to me by a colleague who said it sounded strangely familiar. It belonged to a person that we had worked with, and was copied verbatim, with the name changed. I was on a 2 person team with the actual owner of this resume; I&#8217;m pretty darn sure the third guy wasn&#8217;t sitting in the little office in Mountain View with us unnoticed. In another case, a large offshoring company introduced a team from India and even flew some of them over to meet us. Two of them were supposedly the project technical leads, but in 3 months they never responded to my emails, never checked in code, and never were available for conference calls, and the PM made up excuse after excuse for why they were missing. We received invoices with their hours on them, and I couldn&#8217;t get our folks to stop paying for them. I&#8217;m convinced that they never worked on our project.</p>
<p>Is the professional culture in the offshore country the same as in yours? For instance, do they work exactly 8 hours a day and then bail, even if they promised they&#8217;d get something done today and it&#8217;s not done? Will they stay late, work weekends, etc. if you say something is an emergency? Most cultures in the rest of the world consider U.S. and U.K. working hours and work culture to be too long and too intense (and they&#8217;re right, but that&#8217;s a different issue). A colleague told me a story about an offshore team that was working on fixing a serious production bug which the U.S. team was freaking out about and clearly communicating the level of urgency of, but which didn&#8217;t stop the offshore team from quitting at the usual time on Friday and not working again until Monday even though the problem wasn&#8217;t resolved. ASAP doesn&#8217;t necessarily mean what you think it does, if the person on the other end is not on the same wavelength about work culture as you are. Getting someone to work all night or all weekend may not be negotiable, or it might just cost time and a half, or double, or something like that. Just make sure you have that spelled out explicitly, and if that means you need a &#8220;B team&#8221; in another time zone, or a local developer resource, so be it.</p>
<p>My favorite model for offshoring basically eliminates the subcontracting agreement, making the PM and developers (and anybody else you want to hire offshore) part of a wholly owned subsidiary company in their country. Instead of treating them as a unit, treat them as individuals working for a unit that you own, so you can give raises individually, replace the manager if necessary, and generally so that you can keep working with your subsidiary continuously no matter what happens. This means that you need to be pretty hands-on with managing them, but you have to do that no matter what.</p>
<p>Hope this helps!</p>
]]></content:encoded>
			<wfw:commentRss>http://www.pervasivecode.com/blog/2007/02/20/tips-for-offshoring/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>
