• eric.cardinal (10/7/2010)


    At the end of the article it kind of sums it up for me where you are going with this...Henry Ford's craftsman didn't like the assembly line approach either. This is a very telling comment. To me this is more of a philisophical discussion than one of simple code efficiency, creating a code monkey is not what I want as a supervisor. I need people who can solve complex problems, creatively. I know you are only describing creation of "plumbing" here but the title of your article proclaims the production of limited interaction cookie cutter applications, a consistent approach to anything is admirable. But, the loss of the craftsmen creates a gap in ingenuity and innovation...I would hate to see the same thing happen to this industry as has happened to many others. Noble idea but I have a dissenting view on making things too cookie cutter. A few things you forgot to mention about the Japanese auto makers and their efficiency culture. They work 14-16 hour days...6 days a week, they have a negative population growth, and retirement is mainly a dream. I like people where I work but I don't want to spend my life with them...there is a balance.

    Cheers.

    My view as a technologist is that our job is to move things forward. We do this by relieving humans of relatively mindless repetetive work that shouldn't need to be redone, probably poorly, by every person who's trying to achieve something.

    In the 1800s every house had a weaving loom and of necessity the woman of the house spent many of her daily hours making clothes. Today factories do the same job more efficiently and consistently and women are free to do other things, including make clothes for fun if that is their inclination.

    In the 1960s assembly language programmers spent significant amounts of their time reinventing the plumbing of parameter passing, looping, and so forth. Today compilers do all these things consistently and accurately, vastly reducing the amount of time that we all need to create real functionality.

    RAP is in the same spirit. The objective is to properly and systematically do what most programmers currently do both imporperly and inconsistently. They do these things poorly because they're being paid to create functionality, not diddle with plumbing, and so the plumbing always gets short shrift and is done as an afterthought.

    RAP is to application design what compilers are to program writing ... it's a fundamentally different environment in which programmers are relieved of mundane tasks they shouldn't need to do and are rewarded with automatic functionality that they could never afford to implement if they had to do the mundane tasks by hand.

    RAP will not turn programmers into assembly line workers. With RAP, as with compilers that generate your machine code, the assembly-line work is done by the computer, leaving you free to think about grander things than how to implement auditing all over again (RAP gives you auditing, among many other things, for frree).

    So please, let's move forward. Automation ultimately leads to a higher standard of living, even if it forces some of us to re-educate ourselves. At the end of the day I would hope that creating a higher standard of living is what we're all about.