4 ms·

The thing that I find really strange is that development is becoming more about putting the pieces together and writing code to make small changes than it is ab

by devmonk 16y ago

The thing that I find really strange is that development is becoming more about putting the pieces together and writing code to make small changes than it is about really writing much code. Between the many available jars, gems, plugins, etc. out there, many things we need have been written. While I know some semblance of a programmer will be needed to get things done for some years to come. But at some point, instead of craftsmen, we're going to have more "McDonald's" programmers that are following the book, throwing the code into a microwave, and bagging it.

gruseom 16y ago
This is certainly a trend. But it will never take over the entire programming world, and there will always be a supply of more challenging and interesting work for those of us who crave it. In my optimistic moments, I think maybe this trend is a solution for the fundamental problem of the software industry, that the demand for programmers has always by an order of magnitude exceeded the demographic supply of people who can really do it.
- Vivtek 16y ago
  It's not a trend. It's the very nature of computer science. COBOL was a way to program computers directly in something like English, without the need for a programmer to write all that machine code and manage the registers. SQL was a way to program computers directly by describing the data you wanted to retrieve, without the need for a programmer to write the COBOL to hit your VSAM tables. There will always be programming work, because there will always be a need to formalize knowledge and processes - I believe it will eventually be automated, but that is an NLP-equivalent problem. It's not going to be solved with today's technology. Perhaps a better take-away would be that such "non-programming programming" platforms should still be written by people who understand the processes we've developed to ensure more workable software, things like version control and unit testing. It's not like these couldn't be integrated with this sort of easy-to-access domain-specific tool that permits technically less savvy people to codify some of their own knowledge.
  - gruseom 16y ago
    COBOL is the nature of computer science? Couldn't disagree more. It is certainly the nature of the enterprise computing market, though. easy-to-access domain-specific tool that permits technically less savvy people to codify some of their own knowledge But this is the pipe dream that the OP argues against, that perennially comes up and inevitably fails. Well, to be more precise, it inevitably fails technically. It often succeeds, in the short term, at convincing people who want to be convinced, and those people are sometimes executives who write checks, so there's usually a buck to be made at it if you want to sell vaporware. (With, of course, the enormous exception of spreadsheets.)
    - Vivtek 16y ago
      In 1955, COBOL was the cat's pajamas. The fact that you're unimpressed fifty years later - when COBOL is still the most widespread single programming language on the planet - is precisely because it established the very foundations of your world. The "pipe dream" fails because it is implemented by people who honestly believe programmers are superfluous if you just automate them away - people who don't actually know how programming works. Excel being a case in point. Have you ever tried to shoehorn an Excel spreadsheet into an enterprise software maintenance program? It's really hard.
      - gruseom 16y ago
        I wonder if there's a version of Muphry's Law for condescension. I've been impressed with aspects of COBOL. I even wrote Robert Glass to buy hard copies of his detailed defense of it 5 years ago so I could learn more about what made it great. In certain ways COBOL was better than what came later. Nevertheless what you're saying is historically inaccurate: COBOL was never the cat's pajamas of computer science. It was the original success story of manager-driven development, and that is a very different matter.
        Vivtek 16y ago
        Hm. I suppose my use of "computer science" as the study and use of computers was sloppy; blame it on my having studied my computer science at an engineering school. Perhaps you'd be happier had I used the phrase "computing technology"?
jerf 16y ago
I remember people saying that, too. In 1980. It really isn't true, and the reasons why it isn't true have been known for a long time, and it will never be true, and it is this: A (good) programmer is always prototyping. Virtually by definition, you are doing something that hasn't been done before. If it had been done before, you would buy it or download it, it would be a component, and then you would move on to the part of the problem that hasn't been done before. It is not true that programming is moving towards a model where you just grab components off the shelf and wire them together. Or if it was true, it has happened, it is in the past, it isn't "becoming" true. All the components mean is that you no longer have to research the best way to handle images, and you get a lot farther before hitting the unsolved part of your problem... but it's only the unsolved part of the problem that is interesting. There's no money in solving solved problems. (Well, that's not entirely true, but this is a comment reply, not an exhaustive description of all programming niches.) The unsolved problem is always the focus and pretty much by definition there will always be more unsolved problems. If you aren't writing much code and you really, truly are just wiring bits together, it is time to either learn how to write metacode that wires the bits together for you and start wiring much, much faster, or to desperately cast about for a new skillset because you are easily replaceable (or possibly just discardable) and you really need to change that as quickly as you can!
- devmonk 16y ago
  Developers are using more and more code that has already been written. Sure we still code, but if you were coding in 1980 (like I was), then you know what I mean. I'm with you and the author that the non-technical customer is not going to be able to move the legos around on the screen until they have their working webapp. I've been a part of projects that promised those types of things, and they were failures for the most part. But, the trend is to have more and more complicated pieces that the developer puts together. The developer feels as if he/she has really done something significant, but what they did technically was more brainless than what a game programmer wrote in assembly in the early eighties, for sure. If developers need to know less and less about what is really going on, sure maybe they will still be called developers, but they'll be closer in function to the guy making your big mac. It won't happen overnight, but just because it hasn't happened yet and may not happen during our lifetimes doesn't mean it won't.

by devmonk 16y ago

gruseom 16y ago

This is certainly a trend. But it will never take over the entire programming world, and there will always be a supply of more challenging and interesting work for those of us who crave it. In my optimistic moments, I think maybe this trend is a solution for the fundamental problem of the software industry, that the demand for programmers has always by an order of magnitude exceeded the demographic supply of people who can really do it.

Vivtek 16y ago
It's not a trend. It's the very nature of computer science. COBOL was a way to program computers directly in something like English, without the need for a programmer to write all that machine code and manage the registers. SQL was a way to program computers directly by describing the data you wanted to retrieve, without the need for a programmer to write the COBOL to hit your VSAM tables. There will always be programming work, because there will always be a need to formalize knowledge and processes - I believe it will eventually be automated, but that is an NLP-equivalent problem. It's not going to be solved with today's technology. Perhaps a better take-away would be that such "non-programming programming" platforms should still be written by people who understand the processes we've developed to ensure more workable software, things like version control and unit testing. It's not like these couldn't be integrated with this sort of easy-to-access domain-specific tool that permits technically less savvy people to codify some of their own knowledge.
- gruseom 16y ago
  COBOL is the nature of computer science? Couldn't disagree more. It is certainly the nature of the enterprise computing market, though. easy-to-access domain-specific tool that permits technically less savvy people to codify some of their own knowledge But this is the pipe dream that the OP argues against, that perennially comes up and inevitably fails. Well, to be more precise, it inevitably fails technically. It often succeeds, in the short term, at convincing people who want to be convinced, and those people are sometimes executives who write checks, so there's usually a buck to be made at it if you want to sell vaporware. (With, of course, the enormous exception of spreadsheets.)
  - Vivtek 16y ago
    In 1955, COBOL was the cat's pajamas. The fact that you're unimpressed fifty years later - when COBOL is still the most widespread single programming language on the planet - is precisely because it established the very foundations of your world. The "pipe dream" fails because it is implemented by people who honestly believe programmers are superfluous if you just automate them away - people who don't actually know how programming works. Excel being a case in point. Have you ever tried to shoehorn an Excel spreadsheet into an enterprise software maintenance program? It's really hard.
    - gruseom 16y ago
      I wonder if there's a version of Muphry's Law for condescension. I've been impressed with aspects of COBOL. I even wrote Robert Glass to buy hard copies of his detailed defense of it 5 years ago so I could learn more about what made it great. In certain ways COBOL was better than what came later. Nevertheless what you're saying is historically inaccurate: COBOL was never the cat's pajamas of computer science. It was the original success story of manager-driven development, and that is a very different matter.
      - Vivtek 16y ago
        Hm. I suppose my use of "computer science" as the study and use of computers was sloppy; blame it on my having studied my computer science at an engineering school. Perhaps you'd be happier had I used the phrase "computing technology"?

jerf 16y ago

I remember people saying that, too. In 1980. It really isn't true, and the reasons why it isn't true have been known for a long time, and it will never be true, and it is this: A (good) programmer is always prototyping. Virtually by definition, you are doing something that hasn't been done before. If it had been done before, you would buy it or download it, it would be a component, and then you would move on to the part of the problem that hasn't been done before. It is not true that programming is moving towards a model where you just grab components off the shelf and wire them together. Or if it was true, it has happened, it is in the past, it isn't "becoming" true. All the components mean is that you no longer have to research the best way to handle images, and you get a lot farther before hitting the unsolved part of your problem... but it's only the unsolved part of the problem that is interesting. There's no money in solving solved problems. (Well, that's not entirely true, but this is a comment reply, not an exhaustive description of all programming niches.) The unsolved problem is always the focus and pretty much by definition there will always be more unsolved problems. If you aren't writing much code and you really, truly are just wiring bits together, it is time to either learn how to write metacode that wires the bits together for you and start wiring much, much faster, or to desperately cast about for a new skillset because you are easily replaceable (or possibly just discardable) and you really need to change that as quickly as you can!

devmonk 16y ago
Developers are using more and more code that has already been written. Sure we still code, but if you were coding in 1980 (like I was), then you know what I mean. I'm with you and the author that the non-technical customer is not going to be able to move the legos around on the screen until they have their working webapp. I've been a part of projects that promised those types of things, and they were failures for the most part. But, the trend is to have more and more complicated pieces that the developer puts together. The developer feels as if he/she has really done something significant, but what they did technically was more brainless than what a game programmer wrote in assembly in the early eighties, for sure. If developers need to know less and less about what is really going on, sure maybe they will still be called developers, but they'll be closer in function to the guy making your big mac. It won't happen overnight, but just because it hasn't happened yet and may not happen during our lifetimes doesn't mean it won't.