Slashdot Log In
Hackers As Factory Workers?
Posted by
timothy
on Sun Aug 08, 2004 01:36 PM
from the but-zey-are-artistes dept.
from the but-zey-are-artistes dept.
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 discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
And while we're at it (Score:5, Funny)
Re:And while we're at it (Score:3, Funny)
Food chain (Score:5, Insightful)
Re:Food chain (Score:3, Insightful)
Re:Food chain (Score:4, Insightful)
"Ooo. This not look cheap."
Parent
Re:Food chain (Score:4, Insightful)
Parent
Re:Food chain (Score:5, Interesting)
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.
Parent
Re:Food chain (Score:3, Insightful)
MBA types don't understand anything. They're oxygen thieves.
Re:Food chain (Score:4, Insightful)
Good to see I'm not the only one who's noticed this. People write some 10 line BASIC program, and then can't understand why writing an 100,000 line one is a much bigger problem. (And that's not even the biggest of projects.)
You don't even need to go into uncharted waters: if you tried writing an 100,000 line as the same kind of unstructured mess, you'd end up with a nightmare to debug and/or maintain anyway. The size alone, and the fact that you're essentially looking at it through a keyhole of 25 (or 50 or 100) lines at a time makes it a fundamentally different kind of problem than that 10 line BASIC exercise.
And it's not only MBA types. Most programmers (and I mean actual programmers) come out the college without ever having had to maintain anything _near_ the scale of actual projects. And some of the flamewars (e.g., about how any kind of structure or strong typing sucks) are nothing but proof that someone never was in a large project, but is extrapolating out of their ass anyway.
Either way, IMHO that's only one of the problem types. The ones I've had trouble with include, but are not limited to:
1. The extrapolating type you've just described.
2. The "form before function" type. If it's easy to drag and drop some buttons in a form editor, surely any monkey can put the code together in no time. I mean, phbt, programming is easy. It was dropping those buttons that was the real problem.
3. The living proof that "just a little knowledge can be dangerous."
E.g., someone who doesn't really understand XML, but just heard that it's good. Dunno for what. Probably for everything. 'Cause SUN said so. So next thing you know, everything _must_ happen in XML. Even calls inside the program have their parameters passed as XML, and every method starts by parsing its arguments out of XML. (Not a joke: I know at least one project based on that idea.) Or since XSLT is all the rage too, let's have business logic and workflow control in XSLT. (Again, sadly not a joke.)
E.g., the PHB (or even programmer) who bought some book about patterns or best practices on Amazon, didn't really understand it, but now everything must use every single one of those. If every single of your objects doesn't also involve a singleton, which gives you a factory, which gives you an object registered with a manager, etc, it's coming out of your pay. (Again, not a joke: one PHB actually went through a phase where everyone was required to write endless reports about which patterns they used. And would get berated if they didn't use enough. No matter for what.)
4. The invisible man. Now much as I'm weary of over-management, the worst situation so far was basically not being managed at all. Everyone just go code something, and, hey, you can go talk to the others (and other teams) personally if you need something from them.
Parent
Re:Food chain-Bowling for IT. (Score:5, Insightful)
At least for Google we had a recent article right here on Slashdot: they have a very high number of well paid Ph.Ds. Quite the contrary of what your average clueless PHB or beancounter does in the name of efficiency.
Microsoft makes money by selling PHBs the illusion of "buy our patented snake oil, and you can make quality software fast with any burger flipper turned VB.NET developper." But suspiciously enough that is _not_ who Microsoft employs.
Yes, you may rant and rave about how much Microsoft's software sucks, or how it misses deadlines too. But guess what? Most other companies software sucks twice as hard, and costs more too.
While Microsoft does have buffer overflow exploits, other companies had those _and_ a bunch of bugs or broken design decisions of their own. Or shipped downright broken and non-functional software, just to keep a badly planned deadline.
Among the closed source world, Microsoft actually does an outstanding job. So, you know, maybe hiring smart people actually does something for them.
Parent
Re:Food chain (Score:3, Interesting)
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
Yeah, right. (Score:4, Interesting)
Re:Yeah, right. Adapt or DIE (Score:2, Insightful)
code monkeys (Score:5, Insightful)
Not every programmer who resents the idea of typing repetitive instructions all day has gone crazy. In fact if implementing your project requires lots of mindless, repetitive work, then your design decisions are crazy. The very term 'project' implies that you're doing something new you haven't done before.
Example: the cheap, unskilled code monkey spends lots of time repetitively building mediocre GUI components with his, err, GUI builder, while the 'artist' uses the same time to write a factory that constructs the GUI components on the fly, considering things like the data structures they'll edit etc. One central place to enforce consistency and human interface guidelines. No mindless repetition.
Parent
Re:Yeah, right. (Score:3, Insightful)
Neither of those is done on an assembly line, in a factory, or with an emphasis on speed. (They probably also take more skill and creativity than you think.)
Repetition is not Programming (Score:3, Insightful)
If so, something is wrong. Computers are good at repetition, humans can do better things. If your programming is repetitive, you are using the wrong tool. Heck, you should spend your time developing exactly this missing tool. Build a decent library or a preprocessor, then use it to automate away the repetition. It pays off soon. Compare http://c2.com/cgi/wiki?SharpenTheSaw [c2.com] and http://c2.com/cgi/wiki?ThreeStrikesAndYouRefactor [c2.com].
everyone knows it's like this: (Score:2)
Assembly Line? (Score:2, Informative)
Libraries... (Score:4, Interesting)
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?
Re:Libraries... (Score:3, Insightful)
The real work piece is the executable, and once we've built our source code, we can turn out as many copies of the executable as we need. If it's really complicated, we need a
We as
simple (Score:5, Insightful)
It would be foolish to say that there is no place whatsoever for one or the other type of worker in the programming ecology (extrapolate this analogy to society and economics at your own risk).
Doesn't matter though... (Score:4, Insightful)
Parent
Eliminating the "Good" option. (Score:5, Insightful)
"Good. Fast. Cheap. Pick two."
Outfits like the one proposed here elminiate the choice of "Good."
Re:Eliminating the "Good" option. (Score:5, Insightful)
Parent
You just aren't buying the right computers (Score:5, Insightful)
This is all real, and is what runs mission critical stuff across the world.
However, as the orignal poster pointed out, it's good/cheap/fast pick two. I'd even say pick at most two. These systes are neither cheap nor fast. They do not use the latest greatest shit, they use proven reliable hardware that has undergone lots of testing. They are also not in any way shape or form cheap. Whatever level of processing they offer you, you can beat 10 times over with commodity hardware and still be under their price.
The software that runs on them is likewise ultra reliable. Crashes just arne't an option, and they don't happen. The OS and apps are just rock solid. Of course, that means they also don't support all the whiz-bang features. No happy candy-coated bouncing docks or the like.
It's the same deal as in consumer electronics. I continually see peopople lament how poor quality theri $40 DVD player or $20 VCR is as compared to the $500 model they bought years ago. Well DUH, they could afford to put some quality into a $500 DVD player, they can't in a $40 one. Thing is, you can still buy high end electronics, they just still cost lots of money. Go get a studio grade DVD player. It'll be built to last, produce a better picture, but it'll cost $500.
Whatever the level of reliability you demand, there is probably a solution out there that can meet or exceed it. However, don't whine that it costs money. Quality costs money, always has, always will. If you want it cheap, be prepared to accept the consequences that come with that.
Also, in computers, many times it's better to just go with multiple cheap systems. Ends up being as reliable and much cheaper. I mean say you have a server app that is prone to crash, because it is continually hacked and updated. Also, it runs on cheap hardware, so that's not reliable. Ok, so you design it such that it runs on 3 parallel servers, each capable of taking 100% of the load. So even if the hardware fails on one, you still have two, and your testing indicates that it's likely that if one crashes, it'll get back up quick enough that the other won't crash in the mean time. Maybe you go for 4x just to be safe.
You end up having what appears from a user perspectinve to be an ultra-reliable setup, however it still allows you to quickly hack out new versions, that may not be as stable as they should.
Parent
Maybe (Score:4, Insightful)
Re:Maybe (Score:3, Interesting)
Based on the quality of Windows this wouldn't surprise me in the slightest.
It Won't Work Because Of Programmer's Personalitie (Score:5, Insightful)
Those that don't quit will burn out and self destruct. While there is a surplus of IT workers, a sweatshop like this will burn through programmers fast enough that it'll only last a few years before the quality of code gets shoddy because there's no good programmers left that are NOT burned out that will willingly work at such a place.
Re:It Won't Work Because Of Programmer's Personali (Score:3, Interesting)
Think Peoplesoft, Oracle, etc. (Score:3, Informative)
For well-understood problems... (Score:4, Insightful)
Re:For well-understood problems... (Score:3, Insightful)
Software development projects? (Score:4, Insightful)
200 projects sounds extremely low, unless they mean 200 projects per business which is extremely high. How do they define a project? I would guess there are nearly 200 videogames a year so they can't be included in this figure. Does a project need to be >1000000000$ before it is considered as a project in this group?
it's a typo (Score:5, Informative)
Parent
Similar to my paper... (Score:2, Interesting)
Same old same old. (Score:3, Interesting)
Right. (Score:3, Insightful)
Around it comes again (Score:5, Insightful)
In this case, we're seeing the re-awakening of the notion of "commoditizing" programming. Back in the day, it was the notion of "deskilling" programming with forth-generation languages; before that it was the development of general high-level languages like FORTRAN and COBOL; before that it was the realization that you didn't have to be either Goldstein or von Neumann to successfully program a computer.
So, yeah, it's possible to improve programming productivity by building specialized environments for certain classes of problems. That trick worked for report programs with RPG in the 60's; works marvelously with parser generators; works pretty decently with GUI tools for UI programming now; and will undoubtedly work for other classes of programs in the future.
Then you'll find people programming new classes of programs by hand, and a few years later someone will say "wouldn't it be better if we could do this with specialized tools?"
And you can bet that 50 years from now the big issue will still be figuring out what you want to do, and figuring out how to describe that.
Re:Around it comes again (Score:3, Interesting)
All of this discussion about the front-loaded
Re:Around it comes again (Score:3, Informative)
Twenty years ago.
Sometimes I think I should have been an English major.
This nonsense has been around before (Score:5, Insightful)
But writing the software which will go on that CD-ROM is the software analogy of designing the 2005 model of the Nissan Maxima. Now, some software development is not very creative. Just as tweaking the design of a car model that's been around for 10 years, to get something a little bit new for a new model year, is not very creative mech engineering. But it's still design, not assembly-line production. A competent software engineer will be able to do it better and faster than a bad one. And a factory worker will not be able to do it at all.
This is/was inevitable (Score:3, Interesting)
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.
The Hard Part (Score:3, Insightful)
Software development should be treated as a multiplayer team communications game. The success of the team depends more on how successful the communications are.
I RTFAed: Empty Gibberish. (Score:3, Informative)
It's "10 printed pages" of Business 2.0 cliches that was probably lifted out of some dot-commies VC proposal:
One way to do this is to give developers ways to encapsulate their knowledge as reusable assets that others can apply. Is this far fetched? Patterns already demonstrate limited but effective knowledge reuse. The next step is to move from documentation to automation, using languages, frameworks, and tools to automate pattern application.
This is about the most concrete sentence I found, and it ain't all that concrete, besides simply repeating the same mantras we've been hearing for the last decade or so: code reuse is good, frameworks increase efficiency, design patterns are distilled knowledge... There's a bland and unhelpful, not to mention trite, rejection of comparing software development to the production of physical goods in manufacturing.
Don't bother wading through it. It's tripe.
Read between the lines (Score:4, Interesting)
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.
Microsoft still doesn't get it... (Score:3, Insightful)
Re:Microsoft still doesn't get it... (Score:3, Insightful)
The people who don't understand what's going on are their customers. They're content to get a junk product with no service, and Microsoft cleans up at their expense.
Manufacturing model dead wrong (Score:5, Insightful)
Programming computers is an almost entirely an art form. It was the same way 10 years ago. It will be the same way 10 years from now.
Parts of programming which were art forms 10 years ago are a science today. Memory management, for example, is now a very well understood process. What happened? It ceased to be a programming task. Think: Java verus assembly language. Don't spend much time juggling pointers in Java, do you?
Unlike manufacturing, once we've solved a problem it stays solved. That means the role of a specialist who is very good at some technique is necessarily short term: As soon as someone gets good enough to automate the technique, the need to repeat it disappears.
As a result, computer programming remains a high art form: programmers are only needed for the tasks which still defy rigid definition. Art favors the renaissance man, the master of a breadth of disciplines who works with all of them. Computer programming will continue to favor such broadly skilled artists.
So, those of you who style yourselves java coders or C coders or MSCE's, take heed: Become a generalist because your days as a specialist are numbered.
Software development has gotten harder (Score:5, Insightful)
In the old days of machines of 8KB of memory and sub-Mips processors, programming was easier. The space of what programs you could potentially implement was much more limited than today (although both are obviously very large spaces). Most of the development time back then was devoted to figuring out how to implement a program, e.g. how to fit it in memory and make it fast. The was no operating system and the language was assembly (for the 8KB sub-Mips machines anyway).
Today we spend a great deal more time deciding what a program should do, since better machines have expanded the possibilities to an extent we could scarely imagine 35 years ago. But we also spend more time deciding how to implement programs, though for different reasons than before. Now we choose languages, databases, GUI frameworks, and on and on. And the basis for making those choices intelligently involves much more knowledge than was needed before, i.e. not just knowledge of the target machine, but knowledge of the capabilities of the potential languages, operating systems, databases, etc. So the how part is now much more knowledge intensive, whereas it used to be more like solving a puzzle.
So programming really has gotten harder! Is it really any wonder it takes longer and is so often screwed up?
How to improve the situation? Well, the what part is only going to get worse, and we want it to, because that means we can do more with computers. The how part, on the other hand, can and probably will get easier. Standardization is the easiest way that can happen, though I wouldn't call standardization "easy". Using higher levels of abstraction is another way, but the current means of achieving this is mostly through components, the use of which narrows the spaces of both what and how. The problem is that component packages often make incompatible decisions about the how of their implementation, which often makes it difficult to combine multiple packages. And that gets back to the need for standardization.
interesting tidbits (Score:3, Interesting)
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"?