From Shop Class as Soulcraft,
Given their likely acquaintance such a cognitively rich world of work, it is hardly surprising that when Henry Ford introduced the assembly line in 1913, workers simply walked out. One of Ford’s biographers wrote, “So great was labor’s distaste for the new machine system that toward the close of 1913 every time the company wanted to add 100 men to its factory personnel, it was necessary to hire 963.”
A dozen years ago people would talk of building “software factories” to crank out software projects. Back then someone tried to get me excited about joining an effort to create such a factory. I told him I did not want to work in a factory. He tried to back-pedal, saying that it’s not what it sounds like. But I’m sure it was exactly what it sounded like.
8 thoughts on “Walking away from factory work”
The Software Factory concept aimed to abstract the dev process – DSLs for MDA, guidance validation, project item templates, and IDE code gen wizards. Unfortunately, it was too much effort.
Software Engineering practices have hit a brick wall – no silver bullet for round tripping between functional spec and actual code. The level of abstraction has not noticeably increased in past 5 years.
Perhaps the upcoming massive multicore revolution will yield enough horsepower for brute force automated formal methods – A* driven behavior tree generation.
Interestingly, in Ontario anyway, some factory line jobs now are highly desirable: high wages, good benefits and (as long as your company stays in business) good job security. It’s not like that universally, but in the auto sector, for example, working in a factory is easily one of the best jobs around.
Good wages, benefits, and security, OK. But is the work satisfying?
The book I quoted goes on to explain that Henry Ford doubled his employees’ salaries to compensate for the lack of stimulating work. Given interesting work or dull work at comparable salaries, most chose to return to interesting work. But when the wages were no longer comparable, people stayed with Ford for the money.
Ford didn’t have to keep paying double wages. Once everyone adopted assembly line production, people didn’t have the option of interesting work elsewhere and wages went back down.
Your point is well taken but you are missing the bigger picture. The fact is that for most programmers, working in IT cubicles is hardly soul enriching “craft” work. Due to the clear disconnect between the realities of the demand and supply side in our field, a huge number of resources are required to keep the IT info-bulb screwed in. The bulbs in question are hardly worthy of being called craftsman artifacts, but the complexities inherent in the work requires the upper percentile of general population to provide what effectively boils down to book-keeping.
Every time I see a physicist, mathematician, or such brainiacs etc., in an IT project, it upsets me. I wonder to what degree the sucking of smart set from other fields is actually hindering human progress. And for what? For some stupid application that will likely be shelved in a few years. (That gorgeous bike on the cover is not what is currently produced by the majority of the practitioners.)
Software factories are required for IT and commodity software development — soon even the Indian outsource shops will be “too expensive” — so they are going to happen whether you or me likes it or not.
And just like the model-T didn’t do away with Merecedes Benz and Ferraris of the automotive world, it is safe to assume that ground breaking, truly demanding software creation and development, will remain a reality and people such as yourself will be able to continue to practice your chosen craft, while software factories crank out the meh IT commodity software, and the smart set working on those would likely benefit from the evolution of their chosen profession to a true professional field.
The mechanical, electrical (H/W), and civil engineering fields led the way and demonstrate this: You have a very few super stars doing fundamental work (e.g. design the next CPU), a relatively larger (but still small) set building on top of that (e.g. design sub-systems and systems). Beyond that it boils down to assembly.
That is the industrial process. Our field has industrial scale demand. The supply side is arts and craft. It can not go on like this much longer.
To cheer up: looking at my MBP, I wonder at the fact that it was assembled by workers who probably only have had high school education and will likely be replaced by robots in the future. But /no machine or process/ will replace Apple design teams of the field.
@ joshin4colours , John
Given a high unemployment rate and a situation where even those employed may be working for minumum wages or working two jobs–often both, at minumum wage it is not surprising that factory jobs are popular in Ontario.
On the other hand I have known of more than one person with years of experience in a factory job, often very well paid, who absolutely hated the job but could not see quitting as it was impossible to match wages and benefits in another job.
Job satisfaction seems non-existant in some cases but it beats abject poverty at 60 hours of work a week.
Security is another matter, Ford just closed in Talbotville and Catapillar, (EMC), in London is demanding wage and benefit consessions of 50% in the current contract negotiations or it moves to the USA.
John from Ontario
I think I would also have walked out on that job.
Basically, the requirements are awful and do not correspond to anything that seems profitable. So I expect the that the project would tank before I got anything interesting going.
Why are the requirements awful? When I think of how I would implement them, I realize that a spreadsheet, a word processor, a checkbook program and any of a zillion other applications “fit” what’s being described, especially if I think about myself in history before the application was written.
Put differently, this feels like a drive for “do what I want and I do not know what that is yet”. It’s exactly the opposite of Henry Ford’s industrialization — instead of “I know exactly what I want, and I want a lot of it”, it’s “I have no clue”.
Put differently, I frequently find myself able to contribute usefully in meetings just by knowing how the machines work. People come up with all sorts of ideas about what they want to do which fundamentally conflict with the way the underlying systems work. These ideas can sometimes be made to work, by sacrificing details which do not matter to the people proposing them. But that process takes understanding — you need to understand what they need and you need to understand the systems that they are working with.
Automating that process — combining ideas with facts? That automation has been done, at least for some of the easy cases: http://www.google.com
So, anyways, automating software development is easy: just go out and buy what you need. Oh, and learn how to use it. But good luck on getting a machine to figure out for you what it is that you need to do.
Or, I suppose, you could come up with the next spreadsheet replacement. But if that’s where you are heading, and you want to get there, that should be explicitly obvious in your requirements.
As a CEO of a software company, I would say that the best developers I have hired are like highly trained craftsmen. They continually develop their skills and toolsets to become more efficient over time. Given this freedom, they can ‘crank out’ customer specific and sophisticated software faster than a production line of inexperienced developers, or large teams, ever could. Typically, one developer per project works best. This gives them freedom plus responsibility. As the Mythical Man Month states: “One programmer can accomplish in a day what two programmers can accomplish in two days”!