Specialization Is For Insects

time to read 3 min | 589 words

Rocky Lhotka paints a grim picture of our industry 20 years from now:

“Developers” employed in corporate settings become general practitioners: people who know a little about a lot, and pretty much nothing about anything. Their role is primarily to take a guess about the issue and refer the customer to a specialist.

As you can probably guess from the title, I don't agree. Rocky makes a good point, but I simply do not agree with his prediction.

I have not a clue about how SQL Server Tabular Data Stream work, nor do I have any interest in it. That doesn't mean that I need to find a SQL guru to do my databases. Or understand what goes on the bus when I am drawing an image using GDI+. The whole point of abstracting away the underlying layers is to let me focus on doing what I want without getting distracted by the implementation details.

I am one of those that like to have a good understanding on what is going on under the hood, mainly because I am also one of those that keep running into problems because of this stuff. Nevertheless, quite a bit of it Just Works. And unlike the medical field, which is what Rocky compare the devs into (at least it is not construction again :-)), we can move into new areas relatively safely.

There is a place for specialists, certainly. If my database is running slow, and I can't figure out why, I'll call up a SQL guru to point out where I am being stupid. But, that is not something that I would need on a general basis. I expect developers to know a lot, about a wide variety of subjects, but I don't expect them to be experts in all those fields. They need to have a good understanding of what they are doing in any field they are going to spend significant amount of time on, and they should definately have at least one or two areas of expertise where they excel.

I expect to see a lot more work going into building non leaky abstractions in the future, and I think that we are getting better and better at it. Furthermore, I believe we will see a lot more emphasis on Not Surprising The Developer. I fully expect being able to get a new framework, read the overall idea and be productive in a matter of a day or two. If I am not, then the fault is with the framework, period. This means good naming convention, discoverability and googlability, among other important attributes.

In short, technology scale better than people, so I expect technology to fill the gaps. The alternative that Rocky suggest doesn't hold water, in my opinion. If I need to hire a whole bunch of consultants at 250$/hour just to get a BuzzwardTechnology working for my forms over data scenario, I'll simply stick with what I have now. BuzzwardTechnology be damned!

Technology doesn't exists for the sake of technology alone, it exists to answer some sort of a business need, and if it can't handle that, it wouldn't succeed. Handling that, by defination, means that I can get my money's value back.