I think smith's early take on "division of labour" unfortunately conflated two different things, either of which could be called division of labour.
One is what he described in the pin factory, some basic precurser to a factory/assembly line. One person draws wire, another cuts it, another sharpens..
This is not about specialized skills, or even labour. It's industrial engineering. Break a process down to components and optimize individually. In simple cases like this, just breaking down the proccess is 90% of the way. Give 3 people the job of sharpenning an endless pile of pins and the improved tools/methods will follow.
This bleeds into industrial labour (Smith's example for this is pin packaging) in a few ways. Once you have small, efficient, tooled compnent processes... you don't need skilled labour. Pinmaking might be a specialized craft, but anyone can be taught to sharpen.
This is the opposite of the other kind of division of labour.
When historians (especially british ones from the same period) theorized about early civilisation, specialized division of labour featured often. Early cities had enough people that not everyone had to farm. You could have specialist priests, soldiers, artisans, stonworkers, smiths, boatbuilders..
This is where specialized skills and depth of knowledge comes in.
So... data science & pins... The first kind of division of labour is the "organization as a machine" kind. People do a consistent reptitive process. This works very well, but only if you need a cvonsisten, repetitive result.
I think what this article is mostly argueing is that data science (like programming, engineering and a lot of "information economy" jobs) is but shouldn't be organized this way. You don't need a consistent, repetitive result. If you do, that's what computer programs are for.
I agree, I think. Like with a lot of software domains, there's a stark differenc ebetween small projects where requirements, design, architecture & implementation can be done in one head and big projects that can get bogged down in bureucracy, misunderstandings and the inability to move back-and-forward between elements. I think data science has the extra problem of datasecurity and other things that require controls and rigidity.
I expect a lot of these problems will lessen with time. The field is still in growth phase, and both tools and skill levels will improve.
Circa 2005, a problem I cam across all the time was impractical designs for web apps. You'd have a designer who had been designing posters and liveries. They'd make a picture. Then you had a html guy, who would try very hard to make it happen in html. Then it'd go to a JS or server-side specialist, who discovers that and arbitrary amount of text needs to fit neatly into a box that fits exactly 416 charachters of lorem ipsum.
To "break a process down to components" is what the division of labour is, and the division of labour is nothing else but that. Smith didn't conflate shit. Specialization is a posterior an effect of the division of labour. There's no opposite division of labour, labour is divided in the same sense in the two cases: one worker straightens the pin, another sharpens it; a machine straightens it, another sharpens it.
"Labour" does not just mean what a labourer does, it can mean what is to be done, "a labour", such as the labour of making a pin. If you had attempted instead to infer what Smith meant through the example, you'd not have written any of that.
Having wrote a book on this, I kinda agree. But it's not the people, and it's the job. It's whatever you're currently doing. My belief is that a key skill in the upcoming century is to be able to sort whatever you're doing into those two categories and automate those things that fall into your first category, organization as machine.
In fact, if you look at most of the waste in tech development, it's people continuing to do this first category of work when they should be working in the second category. (Insert long rant here about the importance of everybody being able to automate things in order for this to happen.)
One is what he described in the pin factory, some basic precurser to a factory/assembly line. One person draws wire, another cuts it, another sharpens..
This is not about specialized skills, or even labour. It's industrial engineering. Break a process down to components and optimize individually. In simple cases like this, just breaking down the proccess is 90% of the way. Give 3 people the job of sharpenning an endless pile of pins and the improved tools/methods will follow.
This bleeds into industrial labour (Smith's example for this is pin packaging) in a few ways. Once you have small, efficient, tooled compnent processes... you don't need skilled labour. Pinmaking might be a specialized craft, but anyone can be taught to sharpen.
This is the opposite of the other kind of division of labour.
When historians (especially british ones from the same period) theorized about early civilisation, specialized division of labour featured often. Early cities had enough people that not everyone had to farm. You could have specialist priests, soldiers, artisans, stonworkers, smiths, boatbuilders..
This is where specialized skills and depth of knowledge comes in.
So... data science & pins... The first kind of division of labour is the "organization as a machine" kind. People do a consistent reptitive process. This works very well, but only if you need a cvonsisten, repetitive result.
I think what this article is mostly argueing is that data science (like programming, engineering and a lot of "information economy" jobs) is but shouldn't be organized this way. You don't need a consistent, repetitive result. If you do, that's what computer programs are for.
I agree, I think. Like with a lot of software domains, there's a stark differenc ebetween small projects where requirements, design, architecture & implementation can be done in one head and big projects that can get bogged down in bureucracy, misunderstandings and the inability to move back-and-forward between elements. I think data science has the extra problem of datasecurity and other things that require controls and rigidity.
I expect a lot of these problems will lessen with time. The field is still in growth phase, and both tools and skill levels will improve.
Circa 2005, a problem I cam across all the time was impractical designs for web apps. You'd have a designer who had been designing posters and liveries. They'd make a picture. Then you had a html guy, who would try very hard to make it happen in html. Then it'd go to a JS or server-side specialist, who discovers that and arbitrary amount of text needs to fit neatly into a box that fits exactly 416 charachters of lorem ipsum.