0

If you drag & drop, you're letting the editor to build code for you. Surely that means you're not really programming. You're building an application that has no proper code logic, correct?

I drag simple controls on a web form in .NET, but surely you cannot rely 100% on building an app that way? Though some tutorial books in .NET have you dragging and dropping all over the place.

An example, reading from a database using ASP.NET. You can drop SQL controls onto the markup, or you can program the retrieval in the code behind.

I prefer the code behind as you have proper control imho.

Thoughts?

|improve this question|||||
  • 23
    I like to eat cereal in the morning. What do you think? – Job Feb 7 '11 at 18:31
  • 3
    Does it mean that someone writing code in Notepad is a good programmer? After all that person is writing from scratch .. :-P – Zerotoinfinity Feb 8 '11 at 20:26
  • 1
    @Zerotoinfinite notepad is a great tool if you don't have anything else except for Word. Of course, butterflies can be used but they are not always available. And Emacs raises a biological exception called 'Emacs Pinky' which you don't want at all. – rightfold Feb 8 '11 at 23:22
  • 1
    Relevant: charlespetzold.com/etc/DoesVisualStudioRotTheMind.html – Ezra Apr 20 '11 at 9:43
  • 1
    I think this could be a very interesting question if you posed some kind of idea about whether and how using the drag&drop-tools relates to a specific software quality. As it stands it can only turn into a discussion about whether wizards and macros in IDEs suck or not. – Deckard Apr 22 '11 at 13:58

17 Answers 17

Active Oldest Votes
2

Honestly, it's mostly about the project scope. As many have mentioned here, using visual tools does not make you any less of a programmer and can be a time saver. However, you have to be able to trust your tools and be aware of the code generated by your actions.

Are methods automatically generated? Is the positioning used absolute or relative? I've used Flex Builder and some Silverlight tools, as well as some good old Swing generators and the behavior of such tools can vary widely. While those tools can provide design speed and instant visual feedback of what your application can look like, the code can take a big maintainability hit, especially if you do not know the tools inside and out.

Therefore, both approaches have some merit:

Visual Assisted Approach

  • Instant visual feedback.
  • Very fast to create a UI.
  • Harder to review and maintain.
  • Modifications to the UI can have surprising consequences.
  • Some unused auto-generated methods may be left behind.

Coded by hand

  • Slower development.

  • Easier to maintain (given good code!).

  • You get exactly what you coded: no leftover functions, no undocumented features.

The first method is very useful for fast-moving projects, where you want to have a quick visual feedback. The second method requires more discipline, but is more useful for critical applications that might need to be maintained for a long time.

Of course, take it all with a grain of salt. If you're used to code an interface by hand, you'll be faster and more efficient going that way. On the other hand, if you (and your team) know about all the artefacts generated by a visual editor, then maintainability might not be an issue for you.

|improve this answer|||||
  • "you'll be faster and more efficient going that way" only if you keep working on the same set of tools and technologies. If you did web developing, and moved to native mobile application development, then if you came back to web development after some time later you don't have the same efficiency as you left. – Don Dilanga Aug 29 '18 at 9:49
25

I don't think I'm understand what you mean by drag and drop. I don't use .NET, but I do use Qt for user interfaces, and use Qt Creator for creating the layout of widgets.

I don't think this makes me less of a programmer, as the actual logic of the program is all done elsewhere, and I just use the Qt Creator to make things line up in a way which is:

  • much less time consuming
  • far easier to adapt to user requirements; and
  • generally easier to understand than if I built all the layouts up manually in C++.

I'm not "ashamed" of this. I don't see why anyone would be. My applications have a good deal of logic and functionality around, but it's not all about the user interface. Surely this is the case for most people? Interfaces provide a means to use functionality, they are not the functionality in and of themselves.

|improve this answer|||||
  • 3
    +1 Good answer. Hand coding the interface would be silly. – Andres F. Feb 7 '11 at 18:28
  • That's correct. Tools like QT Creator are extremely useful for designing UIs without hard-coding them and help you avoid mixing everything together. But I also don't like people who think that the future of Software Engineering is not needing to write code at all (just drag and drop). – sakisk Apr 23 '11 at 8:20
  • "Interfaces provide a means to use functionality, they are not the functionality in and of themselves." What? Yes they are. The user interface is the application, just as the monitor, keyboard and mouse are the computer. Everything else is just an implementation detail. – Rein Henrichs Apr 25 '11 at 20:19
  • @ReinHenrichs My point was, people aren't clicking the buttons in my applications to have fun clicking buttons. They're clicking the buttons to have the action suggested by those button clicks performed. If I'm going to spend time on something, it's better spent on the functionality of the application than the user interface, so long as the user interface isn't so bad that it stops people accomplishing what they want to do. If I were to rewrite it, I would probably place emphasis on "the" in my final sentence. – TZHX May 20 '15 at 14:04
15

Dragging visual images around is just one of many development tools to make your life easier -- same as a debugger, or something that auto-generates getter and setter functions -- and there's nothing inherently wrong with that. It's like using a calculator. If you rely on it too much as a kid then you might not ever get good at your times tables. However, once you are proficient with the methods, you still might not have the desire to multiple 634*592 by hand. Yes, you can still use the methods you were taught in grade school, but unless there's a compelling reason to practice it, it's not relevant to the problem at hand, and it's faster to use the tools.

On the other hand, if you still reach for the calculator when multiplying 6*91 then you probably should think more about getting your own practice in. With practice, there are a lot of blocks of code that you will know by heart and should not need to drag and drop them.

So obviously the answer is: it depends.

  1. Which, as every Douglas Adams fan knows, is 42.
|improve this answer|||||
  • 2
    +1 I up voted you the moment I saw 42; I knew for sure, there and then, that your answer was correct. – Mateen Ulhaq Apr 10 '11 at 0:50
  • -1. It's overkill to use the answer to life, the universe and everything for a such small question... (just kidding) – Machado Apr 21 '11 at 0:25
  • No, "everything" just includes everything, including small questions! – maaartinus Apr 23 '11 at 19:07
8

it's simple: drag and drop when it works, hand-code when it doesn't

it's not an either-or situation!

|improve this answer|||||
  • +1 for not being on a religious geek mission – ozz Apr 20 '11 at 9:41
7

You are programming, it's just that you have less control over the generated code, which is usually why you would prefer hand coding. You could have the best of both worlds: use drag & drop to make a quick prototype, then fine-tune it by hand.

|improve this answer|||||
  • I wish life were that easy, most of the tools MS is producing of late (ASP being the exception) do not let you tweak the generated code to much of an extent. Take BizTalk, SSIS, SSAS, SSRS, Windows Work Flow, or some of the Azure tools as an example. – aceinthehole Apr 26 '11 at 15:34
6

Unless you are encoding 1 and 0 directly on the hardware you are using some level of abstraction. This is a good thing as it makes us more productive. Assemblers lets us write code faster than manually placing 0 and 1's. Early languages like FORTRAN and C lets us be even more abstract. Modern languages like C#, JAVA, and so on allow us to be even more productive. Tools like Visual Studio and Qt Creator allows us to automate some of the more boring and mundane portions of our applications. Allowing us to concentrate on the more important logic in our application.

Could you gain a small amount of speed by hand coding these sections, yes you could, and if you used a lower level language like C you make it even faster, but someone with the knowledge and time could make it even faster if they wrote in assembler or even directly in machine language.

Does not knowing how to write in Assembler make you less of a programmer. In some cases it does, but for most of us it does not in my opinion matter. As an analogy, how many engineers use slide rules instead of calculators?

|improve this answer|||||
  • Unless you are encoding 1 and 0 directly on the hardware you are using some level of abstraction. This is a good thing as it makes us more productive. Assemblers lets us write code faster than manually placing 0 and 1's. Early languages like FORTRAN and C lets us be even more abstract. Modern languages like C#, JAVA, and so on allow us to be even more productive. ^ QFT – trycatch Apr 25 '11 at 14:43
2

I don't think it's possible to build anything more than very trivial programs with easy-to-use drag-an'-drop, or very highly constrained programs with complex drag-an'-drop (usually domain specific, more complex and buggier than Forms Designer).

I personally really like drag-an'-drop for things like UI design, as it takes away a lot of the tedium of code that creates a control, sets properties, sets position, lather, rinse, repeat, blah blah... and it lets me get to the interesting algorithms and problem solving faster (once the UI is out of the way). Custom drag-an'-drop builders that try to do fancy workflow creation and business logic and then allow complex code-like expressions for runtime evaluation I'm a little more hesitant about. They tend to be more restrictive in what can actually be built and they still can't do everything they need to do. In those cases I'd much rather just write the code by hand.

|improve this answer|||||
  • 1
    +1. This sums it up IMO. The only time you should be using Drag-n-Drop stuff is for 1) UI work and 2) If you're doing an extremely trivial demo app. Anywhere else it's more of a hassle than a benefit. – Wayne Molina Apr 20 '11 at 12:29
  • 1
    @Wayne and poster, atleast for me the code generated by ANY UI-drag-drop tool is too ugly to use in production... And it's never UI tailored for resizing etc! – Max Apr 20 '11 at 21:33
  • Any code that can be generated is just a useless boilerplate. Using a better system reduces the code to just UI coordinates. – maaartinus Apr 23 '11 at 19:10
2

When I open Visual Studio for coding, yes... I call myself a "programmer" . But the story begins when I say I know the tool on which I am working. Specifically talking about Visual Studio, if I write the aspx page by my hand completely instead of dragging and dropping the tools from toolbox... than I won't be a good programmer because I am not fully optimizing my time.

|improve this answer|||||
2
+25

Noun programming (plural programmings)

...

3.(computing) The act of writing a computer program. "Management wanted to know how much programming the project would need."

4.The software that controls a machine, or the logic or expressed in such software; operating instructions A robot's programming doesn't allow for love.

http://en.wiktionary.org/wiki/programming

You're still programming, just like I'm still cooking when I pop a frozen meal in the microwave. Just because it takes less skill doesn't make it invalid, but you also won't see me on the Food network touting how good my Lean Cuisine meals are.

|improve this answer|||||
2

If you drag & drop, you're letting the editor to build code for you. You're building an application that has no proper code logic, correct?

In the beginning there was Frontpage. Dragging and dropping elements created many tables and nested tables. This is bad for maintenance. But, its also an outdated concept.

I drag simple controls on a web form in .NET, but surely you cannot rely 100% on building an app that way?

IDE's are productivity tools. Its faster to drag and drop. If there's no need to write the code manually, then don't.

Today, Visual studio allows drag-drop of many elements without producing lots of trash code. Also today, Microsoft has invested quite a bit of time/money researching good defaults. In fact, there's a whole campaign around framework/tool usability entitled fall into the pit of success.

So, you should take advantage of all MS's investments. Use the tools.

|improve this answer|||||
1

Customers don't care about what you are concerned about, they only care able bug free code delivered on time and on budget that most importantly add value to the business.

GUI builders that accelerate development and increase the quality of the code by avoiding human errors that go ignored are the mark of a poor developer.

The most beautifully hand crafted ones and zeros that don't actually provide any value to the business are completely useless.

|improve this answer|||||
  • -1 GUI builders that increase the quality of the code has to be smarter than the programmer. However, it may accelerate the development (but just because of the weaknesses of the API forcing you to write trivial stuff again and again). – maaartinus Apr 23 '11 at 19:15
0

There is nothing wrong with using a DnD editor to design user interfaces. Considering you're designing a graphical interface being able to see how your interface looks and might be interacted with as you build just makes sense, and if you can't get the DnD editor to give you just the right look/behavior, you can always go into the generated code and fine tune.

|improve this answer|||||
0

Well, I will say this from the two development areas that I know well enough to comment on: WPF/Silverlight development. I almost never use drag 'n drop with any of these because I find that the code that it creates, particularly the XAML stuff makes all kind of crazy margins and assumptions about what you are trying to do. When you're creating a form or some type of screen in WPF/Silverlight, you want to make sure that your controls will be able to scale well when the user is resizing things. Sure, there are times when you want to define a margin, but you should do it on your terms, not the IDE's. When I was doing more stuff with Windows Forms, I definitely relied heavily on the drag 'n drop because it was just so easy to bind to datasets that way, but you wound up having to undo like 1/3 of the code that was generated - which got very ugly.

Nowadays with WPF and MVVM its a lot cleaner and lends itself to hand-coding applications, which I think in the long run also separates the real developers from those that can drop a form on the window and create a simple crud app. Anyway, I think its good to write code rather than just drop stuff on the screen because it allows you to really create efficient code and not just bloated pieces of code. I am also really digging deep into the ASP.NET MVC Framework for an upcoming project I need to do and I am happy that I got away from draggy droppy, because that will certainly NOT help you with the MVC framework!

|improve this answer|||||
0

I look at it in terms of tools and results. Each method, drag-and-drop or hand-coding, is just a tool. It's my job to determine per task which tool gives me better results? (Note: desired results per task will vary greatly.)

Sometimes I may want to hand-code because my desired result is that I completely understand and control the code. Or that I have small details that need to calibrated in a precise manner.

Sometimes I may want to use drag-and-drop techniques because my desired result is that I want to produce a large number of fast results.

In practice, I use both. I'll split a task into a series of tasks, and for a particular subtask I'll determine whether hand-coding or drag-and-dropping is more preferable. Then use the best tool for the task. Sometimes hand-coding is picked because I'm already in hand-coding mode. If one particular task requires one particular tool exclusively, there's not much to fret about.

"Surely that means you're not really programming. You're building an application that has no proper code logic, correct?" As far as DnD not really being programming: I would probably in most cases technically agree with that classification. But in reality, if DnD or hand-coding can produce the same result, the naming doesn't mean anything.

(Also, with DnD you're still building an application that has code logic; it's just that most of the details are being taken care of by a program. In a similar way to how when we write in high level languages, we're still writing for a machine somewhere, but most (or all) of the details of machine code are being taken care of for us.)

Finally, the amount or type of work put into a creation is not an indicator to the quality of the creation. For me personally, hand-coding feels like "real" work or "real" programming because it takes more time, thought, or other resources from me. But at the end of the day, my programming is judged mostly by my programs, not by my processes.

|improve this answer|||||
0

Do you have a nagging boss who spoke of timelines before he could say mama when he was born?

Most of us do.

Yup, you learn a lot if you have got all the time in the world to go figure things out for yourself. Now for the lesser mortals, who have timelines and family, and hopefully some personal priorities too, they'd prefer using some help.

Using only drag-n-drop is not programming but for stuff like UI design, they are a God send.

And frankly, even if I take your argument and say that I am a sloppy programmer if I use drag-n-drop what greatness is achieved by learning MFC or WPF? Why not expend energy on optimizing or fine-tuning the application logic and let the basics be taken care of?

|improve this answer|||||
0

If you've got the relevant programming knowledge why should care whether it is from drag and drop or pure coding. If you can make sure the code which is generated is not faulty and it is correct according to the core programming concepts and it supports the programming logic you are going to develop I hardly see any big disadvantage than not. In fact it will make the life of the programmer much more easier, provided that you are a good programmer.

If you are a newbie to the discipline of programming then you have a problem with drag and drop. What you will know about the specific language at the end of the day would not be the correct way it should be executed and optimized. But if you are an experienced programmer and if you can make a judgement on the code which is automatically created, drag and drop will definitely add on to your efficiency. That is why I guess there are drag drop supported tools available, to develop applications fast, how strong the logic is, programmer's concern; because the tool will not be able to create the logic but support one.

For an example integration tools in business intelligence; they definitely are pure drag and drop tools as far as the logic is concerned. The programmer should definitely know what he/she is doing. It only saves the pain of writing code to do an integration. There will be minimum differences if you compare coding against dragging and dropping in this context. I believe coding is more error prone this way, as you will be trying to re invent the wheel throughout the span of a project and beyond.

With all the ideas and examples I would like to conclude saying, dragging and dropping is to make the work easy for experienced guys and be more productive. They are not the tools for people who start learning (but may have exceptions) programming, may be coding on the note pad will definitely be advantages for as person who is starting up. If you know your context correctly you definitely will be able to use dragging and dropping extremely productive.

|improve this answer|||||
-2

I prefer to write all the code of a website, HTML, CSS, JS, AJAX, and PHP.

But I prefer to use drag & drop tools like Visual Studio, to make applications based on objects.

|improve this answer|||||

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