41–50 of 51 posts
Earlier quoted context omitted.
You can still get crudgy code with TDD.
Yes, but I might not care. If I ask for a function that takes a particular data structure and writes it to a particular file format, as long as it's not in my hot loop, I don't care how badly it's implemented (assuming it works on all my edge cases). On the other hand I might want to make sure it's maintainable or fast enough, in which case I might just write it myself.
Earlier quoted context omitted.
You can still get crudgy code with TDD.
Yes, but I might not care. If I ask for a function that takes a particular data structure and writes it to a particular file format, as long as it's not in my hot loop, I don't care how badly it's implemented (assuming it works on all my edge cases). On the other hand I might want to make sure it's maintainable or fast enough, in which case I might just write it myself.
I've read many articles critical of offshoring to India over the past few years, and they all seem to have the same pattern. The authors all seem to want to describe what's wrong with offshoring, but what they end up describing are great examples of the kind of thinking in American companies which leads to failure. The pattern is almost identical: - It all starts with, out of nowhere, 'pressure' to 'outsource/offshor…
What you're describing doesn't sound like outsourcing or even offshoring to me. It sounds like expanding the business in new geographic areas. Successful manufacturing companies would never think of sending off a spec sheet to the cheapest contract manufacturer and then just sitting back and waiting for the first production run. But somehow, companies have no problem sending off a software spec and just sitting back…
From that experience I gathered that the reason that most outsourcing doesn't work has little to do with the actually outsourcing and much more to do with the type of management that thinks that outsourcing all their development is a really good idea.
I've read many articles critical of offshoring to India over the past few years, and they all seem to have the same pattern. The authors all seem to want to describe what's wrong with offshoring, but what they end up describing are great examples of the kind of thinking in American companies which leads to failure. The pattern is almost identical: - It all starts with, out of nowhere, 'pressure' to 'outsource/offshor…
What you're describing doesn't sound like outsourcing or even offshoring to me. It sounds like expanding the business in new geographic areas. Successful manufacturing companies would never think of sending off a spec sheet to the cheapest contract manufacturer and then just sitting back and waiting for the first production run. But somehow, companies have no problem sending off a software spec and just sitting back…
Another reason to call it offshoring is that every time the company stock is under pressure, US top management wants to let go some people in the US and move more to the India office. This is often not what the India teams want. Over the years, they've developed strong relationships with devs in the US office, with respect for their abilities and acknowledgement of having learnt a lot from them, and don't want to see themselves as taking away the US devs' jobs. The best devs in india want to go off and do new things they've thought of themselves, but are pulled into 'transitioning' new stuff. Managements are the same everywhere, and these kind of things don't figure in their calculus.
Earlier quoted context omitted.
It's a girl ("I am the daughter and granddaughter of immigrants (Indonesian/Chinese on one side and Russian on the other side)"). 1) The problem with domestic outsourcing is you frequently come up against the issue of "I wont need to support this in a month so fuck it I'll just finish it the quick hacky way now." For small site projects like wordpress blogs this may be acceptable, but for actual software I still can'…
The domestic firms to which you outsource typically don't want #1 to happen. They want to build a long-term relationship and hold your repeat business. They want to become such experts on your software that it's not cost effective for you to pay their competitors to work on it. The way they can stay less expensive than in-house development is simple. They can use time division multiplexing to put an entire team of wo…
Earlier quoted context omitted.
No, you're really paying your developers to build domain/business knowledge and familiarity with the codebase. Then when you need a bug fixed or a new feature, it's a snap. You're also paying them so the competition can't hire them. Remember the value of any company engaged in IP is not in the stuff it owns and not even in the stuff it's already done: it's in its ability as an organization to identify and solve new a…
These are all valid points, but I think you're overstating the case a bit. Certainly, IP creation should not be routinely outsourced, but it can be outsourced in limited cases to the benefit of the organization. I think there's a common misperception that outsourcing firms charge higher rates because their resources are (supposedly) more technically proficient. But, at least at my company, this is rarely what's going…
Oh most definitely.
Earlier quoted context omitted.
The domestic firms to which you outsource typically don't want #1 to happen. They want to build a long-term relationship and hold your repeat business. They want to become such experts on your software that it's not cost effective for you to pay their competitors to work on it. The way they can stay less expensive than in-house development is simple. They can use time division multiplexing to put an entire team of wo…
I'm sure that's true for many, many firms. But, in my experience running a domestic product development firm, the single best way to acquire repeat business is to exit completely and gracefully. Doing so builds a trusted relationship not only with the business managers who authorize our work but also with the technical resources who have to live with our code. When we give both groups reasons to trust our integrity,…
Very much so the truth. Additionally, giving great business advice to go with your software works well too. The business of software is unfamiliar to most of the people hiring software developers.
1> Vast difference between domestic and overseas outsourcing. Domestic outsourcing gets rid of a lot of his beefs. 2> You're not paying the developers to develop software, you're paying them to go away afterwards (so you don't have to keep paying them a salary). The big savings don't come from the hourly rate, but instead the fact they're not employees. You get this same benefit domestically. Disclosure: I run a dome…
No, you're really paying your developers to build domain/business knowledge and familiarity with the codebase. Then when you need a bug fixed or a new feature, it's a snap. You're also paying them so the competition can't hire them. Remember the value of any company engaged in IP is not in the stuff it owns and not even in the stuff it's already done: it's in its ability as an organization to identify and solve new a…
Software companies that are primarily software companies can't.
Companies that are primarily not software companies can and thrive on it. Content companies using tools, factories creating tools, etc.
Businesses are also their relationships. You can have plenty of those with very little ongoing development to support what you have already
The types of businesses YOU'VE been in, the IP creation is that important, however the types of companies that often hire out aren't software companies, they're other companies adding a piece of software to their process/infrastructure/product line
1> Vast difference between domestic and overseas outsourcing. Domestic outsourcing gets rid of a lot of his beefs. 2> You're not paying the developers to develop software, you're paying them to go away afterwards (so you don't have to keep paying them a salary). The big savings don't come from the hourly rate, but instead the fact they're not employees. You get this same benefit domestically. Disclosure: I run a dome…
It's a girl ("I am the daughter and granddaughter of immigrants (Indonesian/Chinese on one side and Russian on the other side)"). 1) The problem with domestic outsourcing is you frequently come up against the issue of "I wont need to support this in a month so fuck it I'll just finish it the quick hacky way now." For small site projects like wordpress blogs this may be acceptable, but for actual software I still can'…
IBM and AT&T both hire outside resources....
>the concept that you WANT them to go away afterwards
I was making a riff off a joke about prostitutes which is why I chose that exact phrasing...you don't want them to go away, but you don't want to pay them except for a very occasional upgrade.
>I wont need to support this in a month so fuck it I'll just finish it the quick hacky way now.
On quality: Some places would rather get a hack for 1/3 the price than a stable piece of software. Not that should be the baseline, but people are (unfortunately) highly tolerant of crappy software if it fixes budgetary problems. Does that mean you should offer the hack? Sometimes. I have done it, but I offer the better thing too when possible, and explain you're going to pay a lot more for V2-4 if you buy the really cheap V1.