This is something I can relate to very well - I work for a large company that out sources lots of work to India - some of the developers are good, some terrible (as they are everywhere) - but without fail they refuse to show you anything until its all done. There are at least two problems with this:

* Often they make poor implementation decisions that as the 'designer' (I hate branding myself with that term) I don't like and know it could be done a different way, but now that X weeks of development work have been done, its too late to change it.

* Reviewing a big blob of code like that is a nightmare - easier if I get drip fed it feature by feature. Also, often when reviewing code I have noticed a junior developer will use the same anti-pattern over and over again - so they have to refactor all through the code - if such an error was noticed early, it would have resulted in much less work overall.

"Often they make poor implementation decisions"

Are they coding to a spec? If you're outsourcing you better be or you're just asking for trouble.

"Reviewing a big blob of code like that is a nightmare"

Right. That's why "big blobs of code" are never acceptable. Use whatever strategy you want: structured code, object orientation, reuseable components, etc., but use something.

The problem isn't outsourcing. And it isn't lack of incremental reviews. The problem is in standards, methodologies, and project management. You'd think a "large company" would know better.

You're give a lot of credit to large companies - things are done wrong in them more often than not.

The developers code to requirements - a bunch of signed off requirements are handed off to them and they go make the thing work, so yea there is a spec, but it doesn't go to the level of 'use library x' or feature y or a 5 table join instead of 5 individual selects etc. The developers have license to code the thing in the best way they see fit.

The point of my comment was to agree with what was said in the article in that its bad to go and spring 5 weeks of coding on the team (whether its an open source or closed source team) without running what you are doing past the other team members or stake holders at frequent intervals.

In my case, I have been sprung with weeks of code in one go - it doesn't really matter if there are modular/OO approaches being used - 5 or 6 weeks of code can run into thousands of lines.

The same problem appears with other things too - eg I need a report for 20 components of a system, and it takes some time to prepare the stats (one off manual task) for each part - I would say send me the stats for each component as you get them, but they tend to hold everything back until its all done - then when the report isn't quite right its a much bigger job to fix it than if I had seen some stuff early.

Agile development is sort of like this too - show your customer things each week as its easier to fix when its going down the wrong path, instead of springing three months of work on the customer in one go to find its no what they wanted.

> Are they coding to a spec? If you're outsourcing you better be or you're just asking for trouble.

I see these two as quite distinct. Coding to a spec, even at the level of BDD, simply means making your implementation conform to some abstract behavioral specification.

If writing code that could both adhere to such as spec and was easily maintained and extended in the future were easy, then outsourcing (or simply relying on the most junior programmers you could hire) would definitely be the only sane way to build software.

Unfortunately (or fortunately, if you are a developer who wants to work and knows your craft) it is not nearly so simple. Even a perfect functional spec is usually at least 3-4 levels of abstraction removed from the actual code needed to implement it.

More fine-grained BDD specs or unit tests may come closer to allowing for mostly mechanical translation into working code, but they also must co-evolve with the code itself.

"Are they coding to a spec?"

A spec is a description of the expected behavior of the program, NOT a description of what the code will look like. Unless we have a different conception of "spec"?

If you are specifying the entire, detailed "design" upfront, you are not allowing for Hacking as a valid methodology (specifically, Bottom Up Programming). As we are discussing this on "Hacker News," I'm not sure we want to discredit Hacking as a valid model for software development.

"And it isn't lack of incremental reviews."

Aren't incremental reviews a valid part of project managemnt and software methodology?

For a couple of projects weren't particularly big, we required this set of "specs" before release (for internal use):

- Requirements specification

- Design specification

- Use cases

- Test plan

Plus some reports. The design included a functional specification, but all of these documents evolved iteratively, so as it turned out the design document was mostly an after-the-fact record of what we did. But I don't think anyone here is an avid supporter of BDUF, so what else can a team do to prevent foolish code, other than requiring everyone to show their stuff and explain themselves regularly? If your up-front specification is comprehensive enough to prevent any bad future programming decisions, you don't need a programming team to implement it, you just need a compiler for it.

Maybe that's the deep secret to "Worse is Better": bad ideas are exposed to the harsh glare of other developers early on, but it doesn't sting so bad because nobody expected perfection. Humble is better.