Tag Archives: it

Software, Work

Offshoring means your job too

I quite often come across a strange attitude amongst people in favour of offshoring development work. It reached a kind of apogee in a recent quote that “The thinking will remain in the UK but the work will be done abroad where it is cheaper.”

Don’t kid yourself! If you outsource the work then you also outsource the thinking. If you are an architect, or a designer and your implementation team is offshored then your work has also been offshored. Without the vital feedback from your implementers your high-level input is very quickly going to go stale. The understanding of how to do a job lies with those who do it, not those who raise the purchase orders.

Don’t flatter yourself! For some reason a lot of people in the UK seem to think that the IT staff in places like China, Eastern Europe and India are incapable. I know from experience that there are more smart people in all of these countries than there are in the UK. It’s a simple case of numbers. Don’t confuse offshoring to a lowest cost bidder with being incompetent. You pay so little for your code that it sends a message: we don’t care about our software. If you don’t care why is the wage slave that is eventually contracted to produce it?

So if you are involved in “higher food chain” work, don’t get caught up in the hype. The thinking will always end up following the doing, and then, ultimately, the purchasing does as well.

Standard
Software, Work

The cruel young men and their DSLs

When faced with the question about how people are meant to learn more and more languages some pundits say that perhaps people shouldn’t be programmers if they cannot learn new languages. When you’re young, bright and brilliant that may seem a reasonable answer. However the truth is that no matter how high you try to set the bar on programming, the amount of programming to be done is far in excess of the capacity of the relatively small number of brilliant people in the world who are inclined to do it. Telling the people who make a living trying to answer this demand, with less stellar qualifications perhaps, that they should shape up or ship out isn’t going to win any friends.

It’s also pointlessly antagonistic. Getting to learn many languages should be seen as a chance to broaden and enhance skills. However that is not going to be attractive if organisations continue to provide incentives in terms of pay and opportunities to specialists. To respond negatively to the suggestion that you discard your hard-won investment in your language of choice is both natural and rational if you run the risk of earning less than the single-focus individual. DSLs will die a death unless they can be incorporated within the scope of an existing big beast language or employers adopt a capability rather than knowledge-based metric for pay rewards.

I also think that DSL aficionados often fail to point out to the broader audience of programmers that learning a DSL or even a variety of languages (most probably meaning at least one functional, dynamic and object-orientated language) will not be the same experience as the current depth learning of languages. Since a DSL should be for a specific purpose and have a small syntax or grammar customised to a particular problem or domain it will not be the same as being able to answer trivia such as what the problems with the Date API are in Java and what the Calendar class sets out to address and whether it succeeds or not. Interview questions may have to revolve around applying a new syntax for dealing with a particular problem instead of the usual language pop quiz.

Advocating languages as solutions should also involve advocating changes in employer priorities. If you don’t link the two then threatening someone’s livelihood actually makes it harder to achieve the DSL’ers joyful Babel of languages that matches tool to problem.

Standard