It seems to me that the programming industry is in a race to the bottom. If we take the practices of:

  1. Not taking time to implement best practices
  2. Using other's people code as much as possible (custom code as a liability)
  3. Using increasingly higher level languages to improve productivity
  4. GUI based development "tools" that greatly simplify "programming" and do not require people to understand the plumbing behind the code

These things imply to me that we are in a race to becoming like any other office worker. It is in the employer's interest for things to not require skill (easier to replace), for things to be prebuilt (less project time).

My point here is that a) is there a misalignment between skill and the economic interests of the employer? and b) if there is, how do you mitigate it to enforce professional standards?

  • 28
    Well, someone still has to make those tools. So in some sense it's a race to keep good programmers away from boring work.
    – Jeremy
    Feb 7, 2011 at 20:47
  • 11
    Why anyone believes that the future of software development will boil down to dragging and dropping components is beyond me. Seriously, do you honestly believe it will be that easy.
    – Pemdas
    Feb 7, 2011 at 21:10
  • 3
    @Pemdas: Human fear if progress and/or change. Steam locomotive 150 years ago was perceived as evil.
    – user2567
    Feb 7, 2011 at 21:20
  • 4
    @pierre I am not sure I understand where you are going with that.
    – Pemdas
    Feb 7, 2011 at 21:22
  • 3
    Dijkstra, is that you?
    – l0b0
    Feb 8, 2011 at 9:32

13 Answers 13


I think you've asked a very poignant question.

Creating GUI coding tools puts programmers out of a job as much as robots put assembly line workers out of a job. In my opinion, while there is a loss of jobs, there is also a shift in where the next jobs are.

The technology to get a task done changes, but the task still needs to be completed: The cars still need to be made/assembled before they can be driven; the code/business logic still needs to be put together for the application to function.

Shifts in technology present choices for programmers: Learn GUI-based programming or program GUI tools ... or ... something else entirely.

There can be a misalignment between the skills of the employees and the interests of the employer, but not for long, especially if the employer is savvy. It is therefore in the best interest of both employer and employee that they pursue what is to their mutual benefit. But one will inevitably be ahead of the other. Hopefully it is you (-:

Best wishes,


  • My thinking is to focus on more specialized software development: mathematical, statistical and computational intensive programming (though the 3rd may be going out of style with increases in VM power). I don't think these specialized domains are in that race to the bottom, though I don't have experience in them so I could be wrong.
    – q303
    Feb 7, 2011 at 21:22
  • @q303: There will always be plenty of applications that will take up all available computer power. Feb 7, 2011 at 21:36

To the trends you mention I would add one more, which IMHO explains them:

There is vastly more programmers (needed) than ever.

The amount of tasks which require or include programming is ever increasing, and in an even higher rate than the number of programmers. Nowadays there are several microchips in an average car. In 5 years there may be a chip in your fridge and your toaster. In 10 years, your underwear?... And someone needs to produce all that software to make these work. So there is every possible effort made to automate whatever is automatable, and to improve "productivity" (however it is defined). And more and more fresh brains are recruited.

This implies that the majority of today's active programmers are inexperienced and/or ill prepared for their job. It takes several years to get to an adequate level of experience and it takes constant learning to keep yourself there. The bottom line is, more and more of the programming jobs are becoming less and less challenging. But there is still enough challenges for anyone who is looking for them.

Let me play the devil's advocate against your points above:

Not taking time to implement best practices

A lot of people don't, a lot of people do. Tenish years ago when I first discovered unit testing and the agile approach, none of my colleagues had the slightest idea what it was. Nowadays it is almost standard material at universities, so many fresh graduates already understand it.

Using other's people code as much as possible (custom code as a liability)

As opposed to what? Reinventing the wheel? Or using other people's code to avoid that?

I think it is important to note that we are paid (mostly) to solve problems, and writing code is not the end, only the means to that. If a problem can be solved without writing a single line of code, it still makes the client happy. Especially if this way we manage to produce a more reliable solution faster and cheaper. I don't see any problem with that.

Using increasingly higher level languages to improve productivity

As opposed to coding everything in assembly? ;-)

GUI based development "tools" that greatly simplify "programming" and do not require people to understand the plumbing behind the code

IMHO any tool can be misused. Which is not to say that GUI builders were necessarily perfect or even good - most (or at least some) of them are usable within their limits. But if someone doesn't know those limits, is it a problem of the tool or its user?

In general, I believe (although have no evidence to prove it) that back in the punch card and machine code days, roughly the same proportion of existing code was horrible as now, just both

  • the overall amount of code, and
  • the chances of outsiders ever seeing such code

was much much less.

Now, with the Internet and the Daily WTF, we get exposed to the worst examples day by day. It's a bit like watching all the news about terrorism and earthquakes and divorcing celebs, and crying out how dangerous and immoral this world became.

  • +1 I guess we are in a "every solution breeds new problems" feedback cycle -- can't say if it's a negative or a positive loop.
    – Maglob
    Feb 7, 2011 at 21:11
  • 6
    +1 If only good coders rewrite everything from scratch, then I will happily be a crappy programmer.
    – AndrewKS
    Feb 7, 2011 at 21:47
  • 1
    I don't want chips in my underwear unless the uptime is acceptable!
    – user1249
    Feb 7, 2011 at 23:06
  • @Thorbjørn: what's acceptable uptime for underwear? If it was self-washing then I'd worry about uptime... otherwise you gotta take them off every day anyway (I hope!) Feb 7, 2011 at 23:52
  • 1
    @back2dos, I don't consider this a disagreement. The bold line states the trend, or companies/managers view if you wish; you state the developers' view. I fully agree with you that it would be ideal to have better programmers, more practical education, mentoring, to raise the level of quality in the industry. However, the sad reality is different. Software has become a commodity so many people expect to get it fast and cheap, without understanding implications of such decisions (such as short vs long term costs etc.). Feb 8, 2011 at 10:42

You summarize the situation correctly, but completely misinterpret the meaning.

As software becomes more powerful, the tasks it takes on scale with it. So sure, it may not be necessary nowadays to be a database programmer to create a phone contact database when you can use Access. And it may not be necessary to be a web programmer to set up a blog when you can just go to wordpress. But, while 15 years ago it would be necessary to be a programmer to do those things, what programmers do now is orders of magnitude greater than what could be done 15 years ago.

Let me put it this way, 100 years from now, it will be trivial to set up a system as complex as facebook or google. I'm not talking their web pages, I mean their data centers. Anyone will be able to do it. It'll be built into phones, assuming we even still use them. BUT, there will still be programmers, and while they may not be working on such 'trivial' systems 100 years from now, they will be working on systems so much more complex and sophisticated that no one here can even begin to comprehend their scope and scale. And those systems, like the ones now, will be far out of reach of the average office worker because some people, called programmers, will chose to specialize in pushing the technology of that era to its extremes.

  • Interesting point of view...
    – q303
    Feb 7, 2011 at 21:54
  • 10
    I'd like GrandmasterB to write some sci-fi.
    – ocodo
    Feb 7, 2011 at 22:05
  • 5
    Can't wait to have my own google data center on my phone. Feb 8, 2011 at 0:16
  • 3
    @Slomojo Not as science fiction as you may think. When I was a kid in the 3rd grade I visited a computer demonstration at the college near my house. It was an experimental showcase to the public. One of the programs on display was a playable game of tic-tac-toe. At the time it was considered an oh and ah moment to be able to play a game against a computer. This was in the late 60's. What will the oh and ah moments be a 100 years from now?
    – Bill
    Feb 8, 2011 at 0:32
  • I was referring to the way he told it, not that the content was the stuff of fantasy, I was around when Pong was revolutionary, I'm fairly sure that Nintendo kids can also relate to the exponential changes in technology too.
    – ocodo
    Feb 8, 2011 at 0:48

I've read that sort of thing for forty years now, and I wasn't in on the beginning of the predictions. It hasn't happened yet.

COBOL was the original development tool intended to remove the need for business programmers, and was a much higher-level language than assembler. Code libraries (to avoid having to write one's own code) are of similar antiquity.

Every so often, something comes up that allows nonprogrammers to do something more like programming work. There were the 1980s "fourth-generation languages", fancy spreadsheets like Excel, report generators, and the like. What they have uniformly done, if successful, is remove some of the scutwork from programming and allow programmers to do other, more interesting, things.

This pattern won't last forever, but I'm going to need something more than theoretical arguments and predictions to convince me that programming is indeed going downhill.

The issue from COBOL to modern development tools is that they don't replace the ability to take an inexact specification and turn it into something precise and useful. That is the fundamental ability of programmers, and why we're not going away for a long time.

  • 7
    +1 - "take an inexact specification and turn it into something precise and useful."
    – ocodo
    Feb 7, 2011 at 22:06
  • +1, I haven't been in this game as long as you, but definitely I've heard the same sort of thing as this question stated and re-stated for 20 years, now. Feb 8, 2011 at 0:58
  • +1 for 4gl's I came to say exactly that. All that promise, so little delivery :)
    – Ian
    Feb 8, 2011 at 12:13
  • "This pattern won't last forever" - why not? Jun 20, 2015 at 15:25

Assembly and FORTRAN programmers probably said the same things when structured programming and widespread interpreters were coming into the picture.

At the end of the day, software is a creation meant to automate something which previously had been done by hand. An accounting department in a moderate corporation would have previously required dozens of people, now all that work can be accomplished by the work of one or two. As a result, the goal posts have moved and we now expect that extra capability standard from an accountant.

It takes Pixar longer to render movies than ever before. Despite the enormous increase in computing speed, along with it, the animators have demanded ever increasing complexity and detail in their scenes. Toy Story caliber animation is not acceptable in 2010 like it was in 1995. As their tools have advanced, so have their capabilities and thus expectations.

When drag and drop or other programming methodologies are common-place, the world will demand solutions to even more challenging and complex problems, and they will need programmers using those newer fancy tools to solve them. The goal posts will move.


While I agree with most of the answers that point out that there will still be plenty of work to do I will give a different answer for you to consider:

Yes it is, and it SHOULD be

I am here to design a solution to problems that others cannot. Anything in the toolset that takes my time away from solving problems to deal with all the small details of how to implement my design is waste.

The only reason I would fear going to a higher level language or a simpler and more abstracted tool is that those tools often make assumptions that get in my way and require my time to work around the assumptions to get the desired implementation.

There are always more problems to solve than there are good problem solvers. Even if the entire dev chain became so simple preschoolers could use it most of the solutions designed would be insufficient or inefficient enough that people would pay for a better solution because most people are just bad at seeing the correct solution to issues with all the edge cases and what-ifs that you need to consider to make a good solution.

Our jobs are to solve problems better than most of the rest, the toolchain complexity is not terribly relevant in the big picture view as long as it gets out of the way and lets you build and you build something good.


Even though programming technologies may change, the underlying complexity of a software product is still there. If software could be written completely using diagrams or flow charts (or some other 'simple' way), all of the complexity of the software still needs to be understood and addressed. For that reason, it is important for employers to have programmer(s) who know the company's products inside-out in order to update them or add new features. And it can take quite a while for employees to learn a software product.


No matter what you can automate or pull off the shelf, most packaged software falls into two categories:

  1. It's simple to use, but it doesn't quite match what the business really needs
  2. It's highly customizable, but it takes a specialist to understand and leverage the customization

I guess I forgot the third It's standard productivity software (email, browser, word proc, etc. The software in category one leads to businesses hiring software developers to customize the off the shelf software (if that's possible). The category 2 software, well they might as well hire a developer because the person who knows that customizable system inside and out is either highly sought after (think SAP, PeopleSoft, etc.) or a dying breed (think any system similar to SAP and PeopleSoft that doesn't quite have the same market penetration).

There will always be a need for developers. What I am seeing is that more of what used to be manual, tedious, repetitive work has become automated (think writing code for data access by hand versus using an O/RM). This allows developers to deliver more value to the business with less effort.


I don't take your arguments:

  1. Not taking time to implement best practices

except that.

  1. Using other's people code as much as possible (custom code as a liability)

Code reuse is a best practice. Used code is tested. Of course you should use code from good sources, which is maintained and used by many.

  1. Using increasingly higher level languages to improve productivity

Productivity isn't bad per se - is it?

  1. GUI based development "tools" that greatly simplify "programming" and do not require people to understand the plumbing behind the code

If the tool does the job: Use it. If not: refuse it. If the promise holds, and people really don't need to understand the code - well done! You seem to tell that this is a promise which doesn't hold?

(The numbers here are automatically rerendered wrong. :) )

  • The point is that to be effective, you need less skill. There is nothing inherently bad about GUI based development "tools." What is bad about them is that repeated use reduces the skill level required to do what we do. The same thing goes for using other people's code: eventually, you start programming on the Google platform. Finally, higher level languages abstract a lot of subtleties away that, again, require skill. None of this is bad from an employer, project management point of view. It does, however, make me question the profession's future.
    – q303
    Feb 8, 2011 at 16:27
  • It all depends on your requierements. When I don't need a fine-tuned special-purpose sorting technique for specifically distributed data, I can perfectly use libraries with some quicksort algorithm. Why should I lern it before I need it? Maybe I need the time to learn something else - fontkerning, database-access, GUI-design ... - you name it. Skills are nice to have, but there are too much skills you could have. Sometimes it is right to say: YAGNI. Feb 8, 2011 at 16:34

Visual programming is no less valid or deserving of scorn than text based programming.

There are certain deficits and challenges when programming visually, but the underlying component plumbing being potentially perilous when ignored is not monopolized by visual components and more relevantly, visual designers. Underlying plumbing being ignored is a risk to any development.

If you get a chance to try Labview, you might see the potential (or even a specialized variant in the Lego NXT environment). While not without flaws or shortcomings, there are inherit benefits. Seeing is believing.


Programming practices not only increase productivity and reduce costs for certain types of development (your race to the bottom), but increase application capabilities and customer expectations (thus encouraging a race to the top). Witness the bonuses that Goole and Facebook are paying to get top technologists.


There's no other profession that deals with existence engineering that strives towards change as much as programming. As soon as you simplify something, you just open a can to new problems that breed new ideas.

So I wouldn't soil other people's endeavors to share code and solutions in order to help us move towards novel challenges, ideas and user experiences with the individual practitioner's bad practices, bad habits and manners devoid of humanism.


If we take the practices of:

  • Not taking time to implement best practices
  • Using other's people code as much as possible (custom code as a liability)

WTF? Did you mean for this list to be inconsistent? Lists should come from the same side for each element rather than switching back and forth without warning. Thus your list should read:

If we take the practices of:

  • Not taking time to implement best practices
  • Not using other's people code as much as possible (custom code as a liability)

  • 1
    @NoahRoberts: Your edit changes the meaning of the second bullet point. This is also not an appropriate answer to the question and should've been a comment instead.
    – Adam Lear
    Feb 7, 2011 at 21:35
  • @Anna - this wasn't an edit, of course. That's why it doesn't appear as changes to the original question. It IS an answer because it addresses a flawed premise in the question. Feb 7, 2011 at 21:39
  • What is the premise?
    – q303
    Feb 7, 2011 at 21:47
  • 3
    @NoahRoberts: It is a bit oddly worded, but I believe the list is consistent in its meaning -- q303 is taking "using other people's existing code instead of writing custom code in-house" as a supporting point in his argument.
    – Adam Lear
    Feb 7, 2011 at 21:54
  • @q303 - Apparently that using other peoples' code as much as possible is a bad practice. That's what I'd get out of your list anyway. Feb 7, 2011 at 22:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.