Why Drag & Drop doesn't work
time to read 3 min | 404 words

Moran commented on my Thinking about Developers post, and it got me riled up enough to post an immediate response*. Here is his comment (emphasis mine):

The bottom line, Drag-and-Drop kind of programming works. You can’t blame companies for hiring cheap developers with poor skills that can produce a working outcome.

If the end results of such developers were poor exactly like they are, perhaps something would change in the world, but Microsoft made it pretty easy for these guys to keep their jobs… thus lowering costs of developing using their drag and drop products… hence… profits. Go figure.

Sorry, I don't see it this way. Drag and drop programming works for a very narrow scenario, when you are in an assembly line, endlessly producing similar pieces of software, never going back to maintain it. How often is this the case?

Quoting Wikipedia:

Most (70% or more) software engineering effort over the total lifetime of a system goes into maintenance and upgrades.

This means that anything that can make it easier to work with the software is going to drastically improve the cost of working with the system. Hell, the moment I have written more than three lines of code, I get into maintenance mode. And you know, that scenario that I outlined above, I can still be more productive using smart tools and frameworks than any Drag&Drop assembly line worker.

The problem with Drag & Drop is that the real cost of this method begins to show itself three months into a project, when most people are afraid to say: "We have to throw this mess and start over with a clean slate**"

* Yes, Moran, I do assume that you didn't mean to advocate Drag & Drop programming.

** Even though I am a big believer in not throwing code away. (I am a huge believer in throwing snippets of code away, which may be large snippets).

Tweet Share Share 0 comments
Tags: