Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Software Businesses

Hackers As Factory Workers? 342

Posted by timothy 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.

Hackers As Factory Workers? More

Hackers As Factory Workers?

Comments Filter:

  • And while we're at it (Score:5, Funny)

    by Anonymous Coward on Sunday August 08, 2004 @02:37PM (#9914421)
    Do programmers really need to sleep and eat? What if we just give them implants and let them plug themselves into nutrient/rest bays at the factory? I'm sure it would be quite a bit more efficient. It worked well for the Borg.

  • Food chain (Score:5, Insightful)

    by Kris2k ( 676294 ) on Sunday August 08, 2004 @02:41PM (#9914444)
    Programmers are at the end of the food chain buddy. That's why you need to upgrade and become part of a function that requires decision and analysis. Or , if you're looking for the easy exit, a Sysadmin :)

    • Re:Food chain (Score:3, Insightful)

      by NineNine ( 235196 )
      You're exactly right. Programmers are equivalent to plumbers. They're relatively well-paid specialists, but they're always replaceable, and there's always downward pressure on wages.

      • Re:Food chain (Score:4, Insightful)

        by tsm_sf ( 545316 ) * on Sunday August 08, 2004 @05:04PM (#9915224) Journal
        And there will always be one ready to help (with a big smile on his face and dollar signs in his eyes) when you're ankle deep in water after hiring the lowest bidder.

        "Ooo. This not look cheap."

      • Re:Food chain (Score:4, Insightful)

        by tzanger ( 1575 ) on Sunday August 08, 2004 @06:16PM (#9915676) Homepage
        I take it you haven't paid for the services of a plumber recently. Actually most tradesmen are paid relatively well. The trades are always in demand. Price is an issue everywhere but people find out what the lowest bidder can often do.

      • Re:Food chain (Score:5, Interesting)

        by chickenwing ( 28429 ) on Sunday August 08, 2004 @08:48PM (#9916627) Homepage
        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.

        • Re:Food chain (Score:3, Insightful)

          by Bush Pig ( 175019 )
          > ... MBA types don't seem to understand how difficult software actually is.

          MBA types don't understand anything. They're oxygen thieves.

        • Re:Food chain (Score:4, Insightful)

          by Moraelin ( 679338 ) on Monday August 09, 2004 @06:47AM (#9918757) Journal
          "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."

          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.

    • Re:Food chain (Score:3, Interesting)

      by CAIMLAS ( 41445 )
      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

  • Yeah, right. (Score:4, Interesting)

    by Anonymous Coward on Sunday August 08, 2004 @02:41PM (#9914446)
    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.
    • Look, you can think what you want but this is BUSINESS -- and you need to adapt or die, if you cant cut it, get out of the way there is someone else who can.

      • From The Tao Of Programming (Score:2, Insightful)

        by Anonymous Coward
        A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: ``How long will it take to design this system if I assign five programmers to it?''

        ``It will take one year,'' said the master promptly.

        ``But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?''

        The master programmer frowned. ``In that case, it will take two years.''

        ``And what if I assign a hundred programmers to it?''

        T

    • code monkeys (Score:5, Insightful)

      by n3k5 ( 606163 ) on Sunday August 08, 2004 @02:56PM (#9914535) Journal
      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.
      That's one possibility. You can hire a dozen code-monkeys and let them type instructions until the product resembles the works of shakespeare to a degree that is sufficient for your business model (a.k.a. the microsoft method). But if you're lucky, you can get software that fits the same specification written by one 'artist' who designs well thought out components and two or three people who put them together, test them, document them etc. And you'll get software that is much better maintaineable, reusable, etc.
      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.

    • Re:Yeah, right. (Score:3, Insightful)

      by peachpuff ( 638856 )
      "It's skilled repetition, but no more so than drafting or car repair."

      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.)

    • The vast bulk of programming is just repetition.

      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].
  • push out better software, do it faster, employ mediocre 'mass production' coders for low pay: pick any two.

  • Assembly Line? (Score:2, Informative)

    by Anonymous Coward
    If we wont conform to an "Assembly Line" mentality they will probably just outsource it to another country.

  • Libraries... (Score:4, Interesting)

    by noda132 ( 531521 ) on Sunday August 08, 2004 @02:43PM (#9914458) Homepage

    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?

    • You've hit precisely where the assembly line metaphor for programming breaks down. If I need to make 20 cars, I need to make 20 engines. If I want to make 20 FPSs, I really only need to make 1 engine and include it in all three. There are fairly good parallels between the problems inherent in applying property laws to knowledge and the problems inherent in appyling assembly line techniques to software production: mainly that reproduction of information is free.
      • If I need to make 20 cars, I need to make 20 engines. If I want to make 20 FPSs, I really only need to make 1 engine and include it in all three.
        Not exactly the right interpretation of the metaphor. Your analogy refers to the duplication process (make 20 cars is equivalent to 20 copies of the same application). The article discusses the difference in economies of scale (making 20 cars vs 20 copies) and economies of scope.
        To go with the car analogy, if I need to make a sedan, a coupe, and luxury car.

      • Re:Libraries... (Score:3, Insightful)

        by crmartin ( 98227 )
        That's because the "factory" is the wrong metaphor for the whole process. Instead, we should think of programmers more like industrial engineers: they don't build widgets, they build processes that build widgets.

        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 ./configure file that knows which components to assemble and modify in place so we get the exact workpiece we want.

        We as
    • Yup, or tools to help out similar routineizable tasks, like porting.

      --dave

    • 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?

      Most of the code written today falls into one of two categories:

      1) Forms. Applications for getting data from a human into a database.
      2) Reports. Applications for getting data from a database and into a human.

      This sort of development is a commodity.

  • simple (Score:5, Insightful)

    by Hard_Code ( 49548 ) on Sunday August 08, 2004 @02:43PM (#9914459)
    this is simple - it's the difference between the mass production line worker, and a master craftsman.

    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).
    • Could you elaborate on what you see as the parallels between mass production and software engineering? I don't see them.

      Seems to me that anything that is well-understood and capable of being banged out many times repeatedly is instead coded up into a library. Reusing a library requires no coding at all.

    • Doesn't matter though... (Score:4, Insightful)

      by einhverfr ( 238914 ) <chris...travers@@@gmail...com> on Sunday August 08, 2004 @03:35PM (#9914718) Homepage Journal
      Open aspect of open source software which is often overlooked is that it allows smaller teams to develop software faster. If the software is maintained by large self-regulating networks, than the network itself becomes like an assembly line, but better. This accomplishes what the article is talking about and does it better.

  • Eliminating the "Good" option. (Score:5, Insightful)

    by Maul ( 83993 ) on Sunday August 08, 2004 @02:43PM (#9914463) Journal
    It has always been said with software...
    "Good. Fast. Cheap. Pick two."

    Outfits like the one proposed here elminiate the choice of "Good."

    • Re:Eliminating the "Good" option. (Score:5, Insightful)

      by quelrods ( 521005 ) * <(quel) (at) (quelrod.net)> on Sunday August 08, 2004 @03:08PM (#9914594) Homepage
      Uh since when did we have "good" commercial software? I've got mod points but I couldn't resist responding to your comment. Corporations 99% of the time pick fast and cheap. I lament the fact that we never are allowed the time to do things correctly. Software out of almost every company is massive hack on massive hack followed by massive rewrite due to lack of doing it right the first time.

      • 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 educ

      • You just aren't buying the right computers (Score:5, Insightful)

        by Sycraft-fu ( 314770 ) on Sunday August 08, 2004 @04:18PM (#9914939)
        There are plenty of systems out there that are made to be put in place for years and years. IBM makes mainframes that will be expected to last 20 years, and never fail during that whole time. They really deliver too, as their old ones do just that. You can get systems with hot swappable PROCESSORS, they are so redundant, and others where 2 CPUs run in parallel, checking on each other.

        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.
      • Hmm, I use 'good' commercial software all the time.

        Final Cut Express
        iDVD
        iMovie
        iTunes
        Mail
        Safari
        OS X
        Photoshop Elements
        iChat

        Where are you looking that you can't find good software?
    • Actually it's 3.

      Deadline, features and money. If you have one that's pinned down, you can usually move the other two in your favour.

      If the deadline is short, you can either a. hire more people to alleviate some of the work load (doesn't always work) or b. lessen the features. Want it for cheap? Decrease the features. Want more features? increase cost and time.

  • Maybe (Score:4, Insightful)

    by zors ( 665805 ) on Sunday August 08, 2004 @02:44PM (#9914465)
    It could work, but only on a limited basis. They could probably make junk applications, things that don't really need very much polish on them. Maybe programs that would only be used for a small period, and not necessarily for a large market.

    • Re:Maybe (Score:3, Interesting)

      by TWX ( 665546 )
      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.

  • It Won't Work Because Of Programmer's Personalitie (Score:5, Insightful)

    by TheWanderingHermit ( 513872 ) on Sunday August 08, 2004 @02:44PM (#9914467)
    Most programmers have a strong desire to be challenged and to solve problems. They want to use their brain and imagination. (Wasn't there an article here within the last few weeks about charactistics of good programmers?) That's why they hate cubicles so much. If you try to stuff them into "factories" where they're doing nothing but making modifications to existing code over and over, the tedium will get them.

    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.
    • 'factory' made software(that is made on an automatic assembly line of sorts) is "made" all the time..

      everytime someone creates some ms access db with some wizard that happens.. everytime someone uses some wizard to create something that does something it's akin to the factory model where there's only pre-designed assembling.

      when creating something totally new though.. do they create car designs in a car designs factory?(no they don't but they have their own model of how it gets done anyways.. software des
    • It can be useful as an apprenticeship program for actual code and tool development. For example, getting all the change orders in for a commercial project can be a hell of a lot of work, equal in scope to building the damn thing in the first place. Adding a field, making one display have a link that points to another one, porting it to a new OS or modifying it to be compatible with newer graphics capabilities or API changes, etc. can all suck away the creative time of the original author.

      So there is a role
    • 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.
    • I agree. I seriously wish more IT people would look at the facts: These companies you think you have "job security" at, you have no security at all. You are fodder. You are an easily replaceable renewable resource in their eyes, like paper. They do not care about YOUR quality of life, what YOU want in life, about YOUR security in life. All that matters is what they can get out of you and whether or not it's cost effective. And this will often be a deciscion made based on criteria other than your job perform

  • Think Peoplesoft, Oracle, etc. (Score:3, Informative)

    by Animats ( 122034 ) on Sunday August 08, 2004 @02:45PM (#9914471) Homepage
    This makes sense for companies that sell slightly customized versions of their packages. That really is an assembly line operation.

  • For well-understood problems... (Score:4, Insightful)

    by Homology ( 639438 ) on Sunday August 08, 2004 @02:46PM (#9914478)
    with well-understood types of solutions, one could presumely setup a "factory". Indeed, the off-shoring of programming task is part of that. On the other hand, there are programming/designing tasks where not even the problem is that well understood, or that require a high degree of independent, creative thinking.
    • It's not clear to me what software projects are well-understood and well-specified. Anything that is well-understood, well-specified, and been done many times before is turned into a library, reusable by all. Everything else is a custom job that requires creative thinking, innovation, and problem solving.
    • It seems like just specifying software products takes a lot of work. Part of my job as a developer is helping the stakeholders decide exactly what it is they want and pointing out risks. For example, they'll say, "I want it to work like this," and I'll respond, "Well, we can do this, but the consequence would be ..., and some alternatives are...." How would this kind of thing fit into a factory model?

  • Software development projects? (Score:4, Insightful)

    by AltaMannen ( 568693 ) on Sunday August 08, 2004 @02:47PM (#9914488)
    "According to the Standish Group [Sta94], businesses in the United States spend around $250 billion on software development on approximately 200 projects each year."

    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?
    • 200 projects sounds extremely low, unless they mean 200 projects per business which is extremely high. How do they define a project?

      I'm an electrical engineer at a relativly small company that designs and manufacturers auto parts. We are not a "software company", but we write a suprising amount of software, for example:

      Microcontroller/microprocessor code used in some of our higher-end products

      Ladder-Logic style (for simple tests) or LabView software for product validation test stands, end-of-line t

    • it's a typo (Score:5, Informative)

      by n3k5 ( 606163 ) on Sunday August 08, 2004 @03:34PM (#9914712) Journal
      200 projects sounds extremely low
      There's a reference to the source of this number right in there, why don't you just have a look at it? In the original paper, you find:
      "In the United States, we spend more than $250 billion each year on IT application development of approximately 175,000 projects."
    • My guess is that they mean that the top 200 software projects in the US costs $250 billion each year. Getting and reading the paper is probably the only chance of really figuring out what this quote is supposed to say though.

  • Similar to my paper... (Score:2, Interesting)

    by Anonymous Coward
    Which is here: genprog.pdf [theparticle.com]

  • Engineering (Score:2, Interesting)

    by kognate ( 322256 )
    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 co
    • 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?

      Because making software is a design effort, not a manufacturing effort. Any attempts to understand or control the process as if it were a manufacturing process is doomed to failure.

  • Same old same old. (Score:3, Interesting)

    by Meowing ( 241289 ) on Sunday August 08, 2004 @02:54PM (#9914525) Homepage
    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?
    • We do see this model at work in the modding community. Just look at all the cool things [unrealtournament.com] that can be done with the same core module.
      Mods take less time than the original game, because the original game you have the complexity of creating the engine, this is the economies of scope the article describes.

  • Right. (Score:3, Insightful)

    by jasmusic ( 786052 ) on Sunday August 08, 2004 @02:57PM (#9914537)
    Keep it simple. If your company competes against a large one that believes this mud, then punch it in its soft spot. If their outsourcing and/or code factory leads to bad quality, then market your product as having better quality. On the same token (though not necessarily in the context of this topic): If their outsourced customer support system is flimsy, then fight them with a local-hire system that gets the job done. And if that doesn't work, then you've just legitimized their operation. Boo hoo, not much more to discuss.

  • Around it comes again (Score:5, Insightful)

    by crmartin ( 98227 ) on Sunday August 08, 2004 @02:58PM (#9914549)
    One of the really odd things about a long career in computer science is that you often find the Big New Thing was a big new thing ten, or twenty, or forty years ago. Wilbur and TSO and VTAM become EMACS on a terminal which becomes "thin clients" (and its dual, dedicated compute time becomes workstations become personal computers.)

    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.
    • In fact, during the late "structured" and early "4gl" era, Honeywell tried to set up software factories. Net result? They couldn't be distinguished from ordinary labs like mine (TSDC). They then went on to building Unix-like development environments, which worked quite a bit better.

      --dave

    • Indeed. This looks a lot like 4GLs and application generators all over again.
    • 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

  • This nonsense has been around before (Score:5, Insightful)

    by njdj ( 458173 ) on Sunday August 08, 2004 @03:00PM (#9914555)
    The "software factory" analogy has been around before. It's nonsense, of course. The software analogy of a "factory" is the plant that presses CD-ROMs. Pressing the 10,000th CD-ROM of a software product is the software equivalent of building the 10,000th Nissan Maxima on a production line.
    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.
    • Excellent point. Software engineering is the design stage. The industrial stage is burning the CDs for distribution.

      Another analogy might writing a novel. The actual writing is a creative task that isn't amenable to mass production. But banging out 100k copies of the book once the writing is done is an industrial process.
    • Did you read the article. It specifically says this: We can now see where apples have been compared with oranges. Production in physical industries has been naively compared with development in software. It makes no sense to look for economies of scale in development of any kind, whether of software or of physical goods. We can, however, expect the industrialization of software development to exploit economies of scope.
      The article discusses economies of scope, which is like using the same basic design of

  • This is/was inevitable (Score:3, Interesting)

    by Anonymous Coward on Sunday August 08, 2004 @03:01PM (#9914564)
    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.
    • You'll either be faced by rows of cubicles (which I'm actually quite envious of as at least you get some privacy)

      Unfortunately, these are still noisy as hell, except you won't know where the noise is coming from. My next-cubicle neighbour used to have an admin visit him every afternoon. For the entire duration of the meeting, I kept hearing this "thump, thump, thump-thump". After three days it drove me nuts, and I just had to find out what the noise was... she was bending her knee and thumping the floor

  • this doesn't work! (Score:2, Insightful)

    by yagu ( 721525 )

    I've been under many different managements and the most common call to action when projects fail is, "Change the methodology!" For some reason this is the all too common diagnosis. I've worked with, under, etc. many "methodologies", and generally these methodologies correlate loosely at best to measured success. Of course authors, pundits, and visionaries continue to make fortunes rolling out countless new methodologies and writing books proving they are right.

    As for the notion of a "factory" -- I find

    • Of course authors, pundits, and visionaries continue to make fortunes rolling out countless new methodologies and writing books proving they are right.

      They are not new methodologies. They are just variants of the same old tired methodology, the algorithm. For a completely different non-algorithmic solution, take a look at the The Silver Bullet [adelphia.net] and Project COSA [adelphia.net]
  • I feel the article focuses too much on technological problems. Developing software is not only hard because of technical reasons. Tools have been growing in expressive power and abstraction by leaps and bounds, despite what is implied.

    They make the point for domain-specific frameworks by comparing them with SQL and GUI builders. But I feel they de-emphasize the importance requirements gathering and overall developer-stakeholder interaction has. It's not about better tools from a technical point of view, i

  • Will super-specialization of software development teams help the industry to push out better software faster?

    The answer is a resounding no. The problem is not how to manage or organize teams. The problem is in the way we develop software. We are doing it wrong. The solution requires a fundamental change in the way we program our computers. In my opinion, the main reason that software is so unreliable and so hard to develop has to do with a custom that is as old as the computer: the practice of using the a

  • The Hard Part (Score:3, Insightful)

    by the eric conspiracy ( 20178 ) on Sunday August 08, 2004 @03:19PM (#9914639)
    The hard part is not turning a specification or requirement into a working piece of software. The hard part is writing a specification that captures what the customer needs to have happen in unambiguous language.

    Software development should be treated as a multiplayer team communications game. The success of the team depends more on how successful the communications are.

  • ... a certain company [google.com] with the coolest remuneration [google.com] packages ever? And going public soon for tons of moolah?

    Code factories *will* work, but they'll only ever be bottom feeders: eating away at overpopulated markets because they're cheaper than anyone else. Companies which produce good quality, innovative products will win. But only - ONLY - if they're good at figuring out what they do best (searching [google.com], making computers nobody ever gets fired for buying [ibm.com], making gizmos [apple.com] or allowing interoperativity and caterin [microsoft.com]

  • 1. Every generation of software architects fights to find a way to build a software "factory". I've seen this go through at least 4 full cycles: mainframe toolkits (first CASE tools 1980-1990); client-server (early-Windows, PowerBuilder et al, 1990-1995); OO (VB, VC++, Delphi, 1994-1999), web applications (1999-present).

    2. Every model relies on pre-built components being glued together by programmers who understand a business issue (how to calculate a bank balance) but have no idea of the technology behin
  • Seems pretty stupid to me. The problem isn't really coding, the problem is to understand and describe to domain. This is (if any complexity is involved) an inherently iterative process - in essence the very opposite of the "Software Factory" model.

    The article seems to "solve" this with two pretty old ideas: abstraction and reuse. Both of these has, at one point, been hailed as the silver bullet of software development, and they have both failed to deliver their initail promise of fast and dirt cheap develo
  • I'll admit I just skimmed TFA, I didn't read it. But from what I got, this isn't that great of an idea.

    The basis of putting something into a 'factory' and mass producing it is that it shouldn't require much in terms of creativity, it should be just a process of putting together the parts. If that is all a particular piece of software is, shouldn't it be easier, quicker, and cheaper to automate the development than to stick it in an assembly line type of thing?

  • ...that which is not to their credit

    I wrote this in late 1996 [threeseas.net] and even more can be found here regarding autocoding [debian.org] and I'm sure there is plenty more I can bring up.

    Hey MS, how come you don't understand teh concept of "Credit where credit is due", Hmmmm?
  • Software creation is not something that can be effectively Taylorised; it's more akin to designing factories than working in one. However, the fallacy that all jobs can be Taylorised into a procedure is popular with bosses who resent what they do not understand. So it'll sell. Microsoft is expert at selling this sort of thing, even when it doesn't work. c.f. the common MCSE.

    A full explication of the disaster anyone buying this line of insane bullshit is setting themselves up for is detailed in The Programme [reciprocality.org]

    • Remember the Microsoft API and how they pre-encapsulated a lot if in in their MFC to try to cut out the tedium of all the minutiae of programming for a GUI?

      I thought the concept was really cool!

      I no longer had to re-invent the wheel every time I wanted to build an app.

      I saw this effort very similar to my construction in electronics where I buy components off the shelf and know what I'm getting. I wouldn't even think of trying to build an IC, resistor, capacitor, or large inductor.. albeit I could if I

  • Here's the deal. Approximately 5% (maybe 2%) of developers are god like creatures. Able to weave logic from gossamer webs of electrons and silicon. Stunning in their ability to move from ideas to usable systems in timeframes that leave the head spinning. Able to apply new paradigms ..... The other 95% (98%?) are hacks. They are the new medium skilled lathe operators of the 21st century. Their only claim to fame is that they execute their relatively unskilled efforts utilizing new technology. So did telegr

  • 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 met

  • I RTFAed: Empty Gibberish. (Score:3, Informative)

    by jjohnson ( 62583 ) on Sunday August 08, 2004 @03:57PM (#9914843) Homepage

    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)

    by ca1v1n ( 135902 ) <snook.guanotronic@com> on Sunday August 08, 2004 @04:01PM (#9914864)
    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.

  • Microsoft still doesn't get it... (Score:3, Insightful)

    by SwansonMarpalum ( 521840 ) <redina.alum@rpi@edu> on Sunday August 08, 2004 @04:05PM (#9914879) Homepage Journal
    Software is a service, not a product.
    • No, they do get it. Selling software as a product has made Microsoft a wildly successful organization.

      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)

    by Spazmania ( 174582 ) on Sunday August 08, 2004 @04:08PM (#9914893) Homepage
    The manufacturing model of software development is dead wrong, and the reason why ought to be ovious to any good software developer.

    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.
  • I decided to go back to college to get away from the ass embly line. It's a dismal life, becuase I really don't like someone telling me what to do, then watching my every bathroom break.

    If software engineering goes this route, I'll just find something t o do which gives me the freedom that I value and enjoy.
  • The big problem of course, is that the "industrialization" has already happened, and software in america looks disturbingly like steel factories of the previous generation: losing to overseas competition.

    In part, it's due to protective moves of foreign companies trying to establish their own software industry. But American software rarely enjoys the opportunity to compete with other American software companies. I was dissapointed with the Department of Justice's missing teeth once a conviction was upheld a

  • Software development has gotten harder (Score:5, Insightful)

    by trenobus ( 730756 ) on Sunday August 08, 2004 @04:39PM (#9915072)

    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.

    • In the old days of machines of 8KB of memory and sub-Mips processors, programming was easier.

      Oh PLEASE. Put any of today's PHP-kiddies in front of one of those and watch them crap their pants. Programming is EASY and it's going to get easier. Programming is data entry. The skill is in SOLVING PROBLEMS. Programming is just writing your solution down in a structured way, that's all. And really, it's no more difficult than typing. But some typists are just typists (like today's PHP/My First SQL kids), and so
  • Say that I specialize in middle-tier code. But if I'm working against a poorly designed database, my chances of delivering a successful product go down. If the front-end coder doesn't know what they're doing, again, my chances of delivering a successful product go down. The same with the documentation writers, the installer writer, the support staff, etc.

    The probability of failure in software is multiplicative, meaning that if any one person in the chain is a "zero" at their job, the result is a zero.

  • interesting tidbits (Score:3, Interesting)

    by YouHaveSnail ( 202852 ) on Sunday August 08, 2004 @08:00PM (#9916329)
    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"?

Slashdot Top Deals

Get hold of portable property. -- Charles Dickens, "Great Expectations"

Close