paradox (II)

The original paradox urged me to look for some answers. I've been thinking but mostly I've been asking around. I am not alone in this as a few others in other software companies could tell the same kind of stories.

The most mentioned reason is boredom. Developers' boredom. Laziness. Not incompetence. Which is sad. You can do a thing right, still the day is too alike the others, so you do a poor job just to finish earlier, or cause you've done it so many times before.

The original post title was Don't hire contractors ... It doesn't say it all, but it's catchy and with a reason. It turns out that in case of my project a major cause of poor code was the work of contractors. Not that they were incompetent, not they were even bored (cause those were the times in the lifecycle of this project when no one could get bored), it was the market forces that made them write code fast, not test and ship early. But they grew and got market share. (See here a post that says they might have even chosen the right path from a business point of view). They provided a job for me, the one who swears at their code.

No automated tests, no code reviews, no time for a best-practices catalog, an outdated wiki. Great programmers. This is the recipe for a best selling product !?

Anyway, back to the original title: if you can afford to ignore the business and only care about code, don't hire contractors if you don't have a good development process to oppose some forces to their fury of producing lots and lots of code. Contractors come and go, so they have to produce code to justify their cost (Permanent employees have to do that too, but they are not under the same time stress. They are hired forever, or until a bad review following the last bad review comes, which might take two years in some companies).

Build contractors a light but working development process, allow them to be creative, but don't let them fool around with code, nor leave garbage behind. Or else a developer like me in a post-contractor era will complain that the code is poor and lose time solving paradoxes instead of producing code ... top-quality code.