Slashdot Mirror
Hackers As Factory Workers?
DevDude writes "A strangely interesting article is running on MSDN, entitled: The Case for Software Factories. It suggests creating 'development environments configured to support the rapid development of a specific type of application.' As a developer thrust into many an unsavory situation, I am constantly stepping in the remnants of some development methodology or other. Will super-specialization of software development teams help the industry to push out better software faster? Or are we hassled enough without being treated as an assembly line?"
This will never work. Not because it's impossible or inefficient, but because programmers will never submit to it. For some reason, people who type instructions into machines have gotten into their heads that they are underappreciated artists or that there is something uniquely heroic about what they do. The vast bulk of programming is just repetition. It's skilled repetition, but no more so than drafting or car repair.
It suggests creating 'development environments configured to support the rapid development of a specific type of application.'
That's all well and good, but after a developer codes 5 apps which work pretty much the same way, won't he just develop libraries so that any subsequent app will take less than an hour to code?
Which is here: genprog.pdf
I think this guy is going to get lambasted for saying things that are true. This is what people who don't subscribe to the SlashDotGroupThink (USPattent #43483598) have been saying for some time now: Software needs to get better.
Historically, the way to make things that people make better is to make them using methodologies derived from manufacturing. why is software not subject to the same rules?
sorry folks, it's 1840 again, and this "Steam Engine" is going away.
The up side is that you don't have to convince programmers that this is true, just outsorce them until it's true.
This article is merely reiterating the idealized world that was supposed to result from using structured programming, then objects, and all the other names that have been tossed in for variations on those themes. Code re-use, clicky visual development environments, automagical code generation thingies, scripting... it's always been about concentrating the "hard work" into prepackaged elements and lowering the barriers to producing a finished application. The jigsaw pieces in the article's illustrations made me smile. I had always assumed they would be LEGO bricks, but it's all the same idea, isn't it?
Well who says that existing programmers will be the ones to work these assembly lines? Couldn't traditional menial laborers be retrained for non innovative coding? just learning how to make some small part of an application? any shift in the way you make software would have to mean a shift in the mentality of the poeple who make the software. the quickest way to do that is to change the people themselves.
Or they could make the standard array of commodity software that the public seems to go through. Messaging apps. Forum software. Journal software. Hell, I've heard that Microsoft already runs its people this way to a certain extent, that they get to "Check out" and work on a piece of a project, not really knowing deep down how that piece interrelates to the rest of the main project.
Based on the quality of Windows this wouldn't surprise me in the slightest.
Do not look into laser with remaining eye.
Back in the early to mid nineties I became aware of how the software industry was changing and saw that programming would become like being a factory machine operator.
When I started, computing was more like being a scientist, the journeys one would undertake would lead to wild, mysterious and interesting places. Now you need 30 years experience in SOAP and XML and JSP and Java and etc. etc. and all you do all day is read documentation telling you how to use some crappy proprietary set of classes that some daft bugger threw together one Sunday night because the boss needed a color wheel widget that allowed him to choose colors based on the phases of the moon.
Sorry, but programming these days is so unbelievably boring and if you want to be a factory worker then knock yourself out and get an IT qualification.
Other evidence can be seen merely by walking into a software shop. You'll either be faced by rows of cubicles (which I'm actually quite envious of as at least you get some privacy) or, more likely, a huge open plan shop floor which is noisy as hell, totally unconducive to doing any sort of work beyond drone coding and ugly as fat in a liposuction canister.
There is no "will it be", IT already is a factory style production environment. It's just the "managers" that keep telling you how "valuable" you are that make it seem anything different.
From TFA: Total global demand for software is projected to increase by an order of magnitude over the next decade
Didn't I just read an article about how Tech Employment is dropping sharply this year ?
I have to say, I find this trend more than a little disturbing. I mean, have electronic or mechanical engineers been attacked as much as programmers? What about artists and teachers? Factory line production, this phrase is just another way for the suits to feel good about outsourcing the jobs of highly skilled and creative people.
It seems to me that this is coming to a showdown between the talentless parasites (sales reps, office politician middle managers, and marketing types), and the honest to god educated, skilled and productive members of our society. Mod me down if you want, but I can't honestly say that the IT industry as a whole and the individual programmers themselves are going to sit there and take this abuse for much longer.
What he can't kill, he has sex on. Trent.
Summary: Briefly presents the motivation for Software Factories, a methodology developed at Microsoft. A Software Factory is a development environment configured to support the rapid development of a specific type of application.
Well, I guess when the Software Engineering Institute held the Software Factory Forum in 1985 (or was it '86... I forget) with various luminaries from around the software industry to discuss just these issues, they were really helping Microsoft develop the software factory methodology. Who knew?
The effect of this is to make your skills non-portable. You won't want to leave your job because your experience is so highly specialized that you'd basically be an entry-level programmer wherever you end up. Not only will you be entry-level, but your MS will be only marginally more useful than the guy who took a couple community college courses in the cube next to you.
This whole idea is centered around getting more code written, cheaper. While it may in the short term improve quality due to specialization, in the long term it serves to replace software engineers with codemonkeys.
Ideas like this make Stallman look like an optimist.
WARNING: there is a trojan on your
This all comes down to money. How can we produce software that is just good enough for our customers to tolerate while minimizing up-front development costs. The irony to all of this is that simply hiring a bunch of good engineers, a good manager, and allowing them to write solid specs and live by them will, when all is said and done, result in better software for less money. And let's not forget keeping marketing away from any decisions on delivery dates.
All of this discussion about the front-loaded aspects of software development completely ignores the somewhat harder to quantify, longer term aspects of software such as support costs, customer satisfaction, and ease of software maintenance. However, such things only matter if a company cares about them: if the only concern is getting some kind of product to market before the competition, then a software factory (read: sweatshop) probably makes perfect sense to your average suit. The truth is, your average suit doesn't understand the nature of engineering at any level, and loves the idea of being able to run an engineering staff along the same guidelines as the production floor. They truly don't understand the complexity of modern systems, particularly those which must interact with the real world in some way other than a keyboard and mouse. The whole point, in fact, of having an engineering staff is to reduce those unquantifiables to a manageable level.
The higher the technology, the sharper that two-edged sword.
The MAMF often appears as "formal methods" or "algorithmic proofs" or in extreme cases "maturity models". The disease usually surfaces in comp-sci student authored articles, in CACM or IEEE, or other vectors for spreading academic ideas publicly. This suggests that universities publishing novel methodology ideas, have unanticipated consequences that are surprisingly dangerous to the common good. This is known and expected in some fields such as biological weapons, or nukes, its impact via software engineering may have been overlooked.
MAMF displays a broad class of characteristics:
What can we do to help avoid MAMF ?
Well the good news is that the answer does not involve Hobbits or Rings, or dark lords, or evil empires, unless you really want to get extremely philosophical.
The bad news is that this is like trying to cure the common cold, this marketing meme is successful because it mutates rapidly. I believe there is no simple cure. The common solution is to simply endure the parasites and discomfort, until the organizations natural immu
There is no god; get over it already! Never exchange a walk on part in the war, for a lead role in a cage.
The irony here is that programming requires decision making and analysis, even if you're a medicocre programmer. On the other hand, a mediocre businessman will be able to ask other people for advice.
Reasoning and analysis, as you put it (also called logic and deduction) are pinacle traits of programming. They are not even generally considered necessary skills for most run-of-the-mill business people, and there-in lies the problem: business folks fuck things up for everyone else.
The only reason programmers are at the bottom of the food chain is because they're socially inept (ie, very low social intelligence), more often than not, and thus they've not realized that they need to network with people to retain viability in a social environment.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
According to the article:
Without comparable increases in capacity, it seems inevitable that total software development capacity is destined to fall far short of total demand by the end of the decade.
There are a lot of unemployed sofware engineers out there who will be glad to hear this bit of news.
Of course, if market forces have free play, this will not actually happen, since the enlightened self interest of software suppliers will provide the capacity required to satisfy the demand.
Is it just me, or is it terribly ironic that Microsoft is talking about letting "market forces have free play"?
It disturbs me that the general public and MBA types don't seem to understand how difficult software actually is.
There is this curve where when you learn how to program and write a few small projects you extrapolate from that experience and believe that large projects must be the same.
Part of the misconception lies in the belief that the difficult part is knowing a programming language. Being able to competently write code is only being conversant. It is really the higher levels of organization that are difficult.
You don't need to hire a genius to slap together a porn site for you...it is a solved problem and much like hiring a factory worker, you don't have to look hard to find someone who can assemble the pieces. But as you start going out into uncharted waters doing things that are more technically interesting, you will find that you cannot just hire anyone who knows how to type out correct code.
The good news is that believing that all programmers are the equal doesn't make it so. Any company who wants to try this experiment does so at its own peril.
Yeah, it makes sense outsourcing writing the code to various companies. I suppose as the business of writing software matures, it's only natural for it for it to take on familiar manufacturing paradigms. (If your analogy of auto-companies is true.)
1. People not knowing what each other is up to. So someone builds a reusable module, but no-one knows about it.
2. People not working through the impact of changes in one part of a system on another. How do I find out all the places that a particularly column on a database table can be updated? How do I find out what it is set to? OK. This can be done, but it's very long winded.
3. Fragmentation of tools. As an ex-mainframe guy, we had COBOL and JCL. Now, people download pieces of software, build things in different tools. All these tools require training, which takes time to become mature in them (and often are discarded before maturity occurs).
4. Specs and code don't match. We should be at a point by now that this isn't an issue. The spec should be the code and the tool should run from the spec.