Home > software development > The Extinction of Programmers

The Extinction of Programmers

I read an article named The Future of Software Development by Alex Iskold. He predicts a future where only a few high quality software engineers will be able to serve the world’s need of computer systems.

With a bit of discipline and a ton of passion, high quality engineers are able to put together systems of great complexity on their own.

The idea is that fewer but more specialized people will be able to do more in less time.

Equipped with a modern programming language, great libraries, and agile methods, a couple of smart guys in the garage can get things done much better and faster than an army of mediocre developers.

I’d like to take this prediction a bit further. Well, quite a bit further actually. I see the extinction of software engineers altogether.

Programming as we know it, is a tedious, highly repetitive and error-prone business. It’s the task of telling the computer how to do things, rather than what to do. In other words: we are still dealing with computers at a very low level. To me, programming sounds like a task suitable for computers.

I see a future where we tell the computer, a kind of super-compiler, what we want to achieve. The input is our specification, and the output is a complete and tested system. All we have to do is specify, verify and then push the deploy button.

That would, using my definition, make us Developers rather than Programmers. There’ll be, as Alex pointed out, room for less and less programmers until they finally face extinction. The last programmer will probably live to see the super-compiler’s AI get clever enough to perform self-debugging and self-improvement. (I didn’t say this was in the near future.)

When I mentally put myself into this version of the future, a part of me protests: Where’s the fun in that? Well, I guess that’s just a sign of wrong focus. That part of me still embrace technology rather than business value.

Cheers!

Categories: software development Tags:
  1. November 10th, 2007 at 00:31 | #1

    Wow, it’s the ’80s all over again. You might want to look into Prolog and the 4GLs before you make a prediction that has been made every 10 years since 1940, with nothing to show for it today except a graveyard full of languages nobody likes and research nobody reads.

    • November 11th, 2007 at 21:56 | #2

      Fourth generation languages have their own set of problems, and are not, in my opinion, the answer.

  2. November 10th, 2007 at 02:15 | #3

    Then we’ll be troubleshooting and debugging specs, instead of code.

    Sometimes it is harder to figure out what users really want than to create the code to produce it. Especially if they have never had it before, and they they don’t know themselves.

    When we can develop something that can read their minds they we will really have something.

    • November 11th, 2007 at 21:59 | #4

      Then we’ll be troubleshooting and debugging specs, instead of code.

      True, but since the programming is automatic it takes less time, which makes room for faster iterations. We’d probably still be agile.

  3. November 10th, 2007 at 14:57 | #5

    Hi Hans-Eric,

    Thanks for your comment. Glad you liked the post. Not sure how automatable all coding will be in the future. Even if we invent super blocks, someone will have to assemble them. Likely, software engineering is still going to be around, but as we both are saying the level of interactions will be different.

    Alex

  4. November 10th, 2007 at 17:48 | #6

    Hope at least we will be part the super compiler maintenence team if not dev team. 🙂

    Thanks
    Prashant Jalasutram
    http://prashantjalasutram.blogspot.com/

  5. November 11th, 2007 at 11:52 | #7

    These days I find myself dreaming about the same thing: when we gonna stop writing code (painfully said) and start creating software. I mean it’s so much frustrating to see how much time it takes to create simple apps (and no, rails is not the answer 🙂 )…
    It may be possible to write an simple app in few hours with basic functionality but for this you really need to know what to do, step by step for 10’s of steps from “create table foo…” to “…”, to project build and deploy. And you really need to master all the details to stay on rails…

    I started to look around for some natural language processing tools that would help us simply create software more easily. I am not sure if this is a new or old thing (it seems that it’s old) or even if it’s not something related to each developer age: sometime we just get tired of thinking faster then coding.
    We shall see! 🙂

  6. November 11th, 2007 at 17:48 | #9

    I would suggest that studying a little history would be a good thing here. It’s not like the idea of automatic programming has been bandied about since oh, gee, I dunno, since the 1950s…

    Fantasies of self-writing software systems and AI-like software generation that will make programmers extinct have been around as long as modern stored-program computers.

    And, you know what? Just a few small technical problems stand in the way, among them are solving: complexity theory, correctness theory, completeness theory, theorem proving, and about a dozen other “trivial” areas of information theory and computer science. Solve those and you’ve got automatic programming licked. (Do keep us posted on your progress, mkthanks 🙂

    If we have to live with imperfection in our systems its because we are imperfect; in the real world conditions change, and inputs/process/actions to not always match our ideal specifications. Welcome to life.

    Fortunately we have really great systems than obviate the need for automatic programming systems: human intelligence. It’s our experience, passion and drive that make computers useful and worth programming.

    Computers and software are systems that augment US; if and when we develop system that replace that, then we have met our own> replacements… which is probably not what we wanted to achieve…

    • November 11th, 2007 at 19:53 | #10

      I must say that programming history is not my strong point. Actually I have a background in theoretical physics. In mathematics one theory builds on top of others and must not prove something to be true if already had been proved to be so. That’s why is hard for me to accept (please allow me to insist, it’s been only few days since I have started thinking about this 🙂 ) that we can’t do any better then simply repeating ourself thousands and thousands of times by creating tables and classes and arranging components on screen.

      I am really confident that is our passion and intelligence that will allow us to step to a next level (whatever that step will be) in software production. We just need to save some energy and effort and get to a higher level. Maybe domain specific languages are the answer. My thoughts now are about how can we make these languages be similar to human language.

      Last Friday I have played a little with a NLP library and made a simple program that understands sentences like: “A book has a title and an author”. And I was thinking we should be able to build a platform that will “understand” various types of human expression and try to generate software out of them. The idea would be to restrict ourself to unambiguous expressions and to choose a subset of human language that may be directly translated into computer programs.

      Although this may sound to you like repeating failure/history I dare to think that still we are 60 years from 1950’s and meanwhile things, technology and people have changed.

      Nonetheless, scepticism like yours is precious: temperates, redirects and empowers other’s enthusiasm and does not let them fall into traps!

    • November 11th, 2007 at 22:03 | #11

      I never said it would be easy 🙂

  7. November 11th, 2007 at 20:39 | #12

    Hans,

    To see the future, one of the things that you will have to do, is to compare Computer Science with other established and more mature disclipines in Engineering.

    In manufacturing, for example, people have been able to robotize large amount of repetitive jobs, as wells as those jobs which are hazadorus or require a high amount of precision.

    But has this rendered Mechanical Engineers useless?

    Today’s Mechanical Engineers are either working in R&D, desiging and building those automations tools, or are shop floor managers, managing scores of people that run those robots.

    What may eventually happen is essentially what Alex told.

    Ordinary programmers (like me) will find it dificult to find real programming jobs.

    The best ones will do R&D, and design and build those nifty little compilers and DSLs, while others will have to shift to Managerial roles, just like shop floor managers in the manufacturing industry today.

    Whatever happens, the glory days for programmers are over. Next year’s financial crash will prove that, there are too many ordinary programmers doing, far too many ordinary things. Their jobs will have to be automated, and this is precisely what the markets will push for.

    PS: Incidentally those same jobs have also been offshored to India, in the past.

    • November 11th, 2007 at 22:08 | #13

      Whatever happens, the glory days for programmers are over.

      Do you think this is true for developers as well?

  8. November 11th, 2007 at 21:22 | #14

    I’ve heard the same at the end of the 80s when I started studying computer science. Everyone and his dog predicted that off-the-shelf software and CASE-tools would kill the software developers. Then the number of development jobs exploded.

    It was the same with the arrival of 4G languages.

    Someone needs to model and mold complexity. Whatever you call him. . Complexity cannot go away.

    Peace
    -stephan


    Stephan Schmidt :: stephan@reposita.org
    Reposita Open Source – Monitor your software development
    http://www.reposita.org
    Blog at http://stephan.reposita.org – No signal. No noise.

    • November 11th, 2007 at 22:12 | #15

      Someone needs to model and mold complexity.

      True, the first time. But once it’s done, the complexity could be abstract.

  9. Paul Watson
    November 11th, 2007 at 21:37 | #16

    @Swapnonil: “Their jobs will have to be automated, and this is precisely what the markets will push for.”

    Meh. The markets have been pushing for that for decades. The first I read about it myself was back in the early 80’s, but I’m not one of the real old-timers. They’ve been seeing this sort of thing for much longer. And we’re no closer to automating the task of programming than we were back then.

    I am unconcerned.

    • November 11th, 2007 at 22:14 | #17

      True, and I’m not concerned either – just tired of all this inefficiency.

    • November 12th, 2007 at 11:25 | #18

      Paul,

      For every mass produced car like the Toyota Corolla, there will always be a hand crafted car like a Ferrari or an Aston Martin.

      But the efficiency that Toyota has achieved with the Corolla, or even the efficiency that Henry Ford achieved with the Model T, has never been replicated in the assembling or developing, even run of the mill software like an e-commerce website, for example.

      Why? Two reasons.

      1. Lack of standardization.
      2. Requirements in software development, tend to change often.

      To solve inefficiency we will have to either standardize so as to produce run of the mill software, more efficiently, or adopt Agile Methods and Practices to develop software which are prone to change.

      The task of programming cannot be automated. But developing solutions for a given problem, should be more about assembling things, rather than writing them all over again. Ruby on Rails touches on this subject, but even they are still on the tip of the iceberg.

  10. November 11th, 2007 at 23:28 | #19

    I think it’s more likely that we’ll develop a super-AI before we develop a super-compiler.

    If that happens, the AI becomes the one who writes both the program and the associated tools. It won’t even necessarily have to make it human-readable. It could port, patch, and upgrade all existing software automatically. We’ll all be pretty obsolete when that happens…

  11. November 12th, 2007 at 11:09 | #20

    When software gets good enough to make programmers obsolete, it will be good enough to make *all* humans obsolete. I for one am looking forward to the super-intelligent pleasure-bots of the future.

  12. November 12th, 2007 at 11:44 | #21

    I think the languages and the tools will be of a higher level each time, and certainly, this could reduce the need of programmers, but it is imposible to totally replace the work of a programmer/designer with a computer.

  13. mccoyn
    November 12th, 2007 at 15:16 | #22

    I’ve had this feeling, too. The mere fact that software engineers have been talking about it for decades just confirms it. If people are talking about it, then people are thinking about it and trying to make it happen.

    I don’t think the super-compiler was possible 25 years ago, especially if you are worried about assembly, and manual garbage collection. These days that can all be automated, freeing developers to focus on more difficult problems. In another 25 years we are likely to find some way to automate the repetitive tasks we do today. No more SQL, no more concurrency bugs, maybe even self-assembling UIs.

    The super-compilier will be much easier to implement in that environment. Software engineers will have been thinking about it for 50 years. Computers will by orders of magnitude faster. Maybe the super-compilier will still by far-fetched.

    OK, jump ahead another 25 years. Software engineers have fixed more repetitive tasks, things which don’t seem repetitive today because we are spending so much time writing HTML and avoiding concurrency bugs. Again, computers will be faster. Its hard to think that no determined software engineers could build the super-compiler given those kinds of resources.

    I wouldn’t worry though. All the cool natural born programmers out there will find something else cool to work on. They did 100 years ago, and they will 100 years from now.

  14. Collin Cusce
    November 12th, 2007 at 15:40 | #23
  15. mccoyn
    November 12th, 2007 at 16:05 | #24

    I’m not sure that humans are much better than computers at solving the halting problem even today.

    • Collin Cusce
      November 12th, 2007 at 19:19 | #25

      Humans are not, however they have one advantage… they wont get stuck in infinite loops.

      Computers fail at halting problems because they think they can solve it even if they cannot. Humans give up.

      That’s why you cannot verify the accuracy of an algorithm via a compiler, and why compilers tend to stray away from algorithm analysis all together.

  16. November 12th, 2007 at 17:21 | #26

    Congratulations on winning the “Newb” award when it comes to writing about software development.

    As someone else pointed out, they tried to replace programmers with CASE (Computer Aided Software Engineering) tools. It was felt that the same productivity gains seen with CAD tools in the drafting world would be felt in programming. These are the same people who feel Donald Knuth’s “The Art of Programming” would be better titled “The Act of Programming.”

    Trying to become more productive by optimizing the programming aspect of software creation is like trying to put a spoiler on a sports car with a flat tire. Technically, things will be “faster”, but at the end of the day, you’re still going nowhere just as fast. Often the problems with software creation are on the PM side. Software Development is inherently a people-centric process.

    Programmers are inherently valuable not because of their ability to write lines of code, but for their ability to translate imperfect requirements and an imperfect spec in workable software. Many a times, the software is not workable — the project has failed, again most likely due to a people-centric problem.

    There are too many people managing in software projects that haven’t read the mythical man-month or think its laws don’t apply to them in this day in age.

    Bottom line, there is no silver bullet to ease the pain of programming.

    I look forward to your next post, undoubtedly about how Indian Off-Shoring will decimate American programmers. (Hint: The Japanese also tried this in the 80s, and we’re still here.)

  17. November 12th, 2007 at 19:35 | #27

    @Chris: “Programmers are inherently valuable not because of their ability to write lines of code, but for their ability to translate imperfect requirements and an imperfect spec in workable software. Many a times, the software is not workable — the project has failed, again most likely due to a people-centric problem.”

    Couldn’t said it better. Thanks.

  18. Dave G
    November 12th, 2007 at 21:29 | #28

    I see a future where we tell the computer, a kind of super-compiler, what we want to achieve. The input is our specification, and the output is a complete and tested system. All we have to do is specify, verify and then push the deploy button.

    You’ve just described exactly what a compiler/assembler does. The source code written by programmers is nothing more than a minutely-detailed specification of what the output should be. Someday, the input that programmers currently write may be more declarative, but it will still require a lot of thought and expertise to produce, and the people who do it will be the programmers of tomorrow.

  19. November 15th, 2007 at 20:43 | #29

    You can’t remove “programming” without replacing it with some type of intelligence; the existence of which is the subject of very long and complex arguments. You could, however make programming so “trivial” that virtually anybody could do it. Spreadsheets are a fore-shadowing of this, so are those video games that let people pretend to play guitar.

    The computer will probably never be “smart”, but it can be of enough assistance that more and more of today’s users can do programming “like” tasks. Just think about how easy it is to configure new menus in XP as compared to doing the same thing with X-windows and TWM, twenty years ago. Another example is how “digital” photography is so much easier than film; you get instant feedback, so you can correct your shots immediately. That’s having a huge effect on industries like wedding photography because so many more people are able to get into the profession quickly.

    Software as a tool for our minds can make us smarter and more effective in the same ways that a bulldozer helps a construction worker to move more earth, faster.

  20. Peter Schulz
    December 31st, 2007 at 17:38 | #30

    Taking out the programmer out of programming would remove the only causative element out of the “team” which creates a program – the computer / programmer team. It’s both which have to do work on it but the programmer is the one who propels it. The computer is NOT capable to do anything else than what he has been carefully told. Man is not a machine and only he is capable of creating.

    Also you are taking the entire subject from a programmer level which is below the level of system programmer. While you may have the super compiler – who will write and maintain it? Yes you may not release many versions of your programs, but the system program writers (operating systems that is) do advance their systems continuously, and both hardware and software concepts are changing radically every few years? Who will program the next generation super-compiler? Millions of programmers?

    The super compiler itself won’t do it. It willnot be able to do anything what it has not been told.

    Peter Schulz

    • January 3rd, 2008 at 10:05 | #31

      Good points!

      I too believe that a even a super-compiler needs to be told what to do. But my vision was that in the future our specifications would look more like natural language, and less like source code. Kind of like taking programming to a higher level, to a point where we’d be more Developers than Programmers (as we know them today).

      The human-computer “team” would still be very much working together.

  1. November 11th, 2007 at 13:50 | #1
  2. November 29th, 2007 at 06:11 | #2