Skip to content

Convenience Kills, or the Case Against RAD Tools

August 18, 2008

A rather heated discussion erupted last week on Twitter and IRC concerning so-called “drag-and-drop demos” — point-and-click demonstrations of “software development” that just involve dragging controls around on a graphical designer without a lot of actual coding involved. Being entirely unable to resist joining in on debates, I had to chime in and give my two cents.

At root, drag-and-drop (D&D) demos are really nothing more than a marketing tool, and they do little to illustrate the actual way software is written. It’s kind of like the scene in Swordfish where the main character is “programming,” but all the audience actually sees is a spinning cube with nodes flying on and off. Why? Because real software development isn’t interesting in the least to a layperson. Real software development means hammering away on a keyboard for hours, drawing squiggly boxes on a whiteboard, and debating design with your team. People with passion for software relish this process, but if you don’t understand what you’re looking at, I imagine watching it would be pretty mind-numbing.

This is also why programming, sadly, will never be an Olympic sport, nor will we tune in on Sundays to National Software League competitions. :)

D&D demos, on the other hand, provide visual indicators and guides which allow people with any level of technical skill to understand the basic process. However, any software developer will tell you that drag-and-drop tools fall very far on the 80% side of the 80/20 rule — the second you try to do something more complex (read: useful), you have to write code.

This is why D&D demonstrations are actually extremely dangerous. They only serve to blow smoke up the asses of non-technical people, and convince them that software development is easier than it actually is. For example, let’s say a non-technical manager sees a demonstration of ASP.NET WebForms, with a data-bound grid control. It can become very difficult to convince them that, in order to support our actual requirements, we need to create a real domain model, and write the HTML directly so we can get better support for CSS, and write some tests so we can make sure it actually does what we claim. None of that was in the product demonstration, so it’s not surprising that non-technical people balk at estimates that include more of the nitty-gritty tasks.

I’ll take this argument a step further, also, and say that all tools geared around RAD (rapid application development) are harmful when considered out of context. Microsoft in particular has had a long-standing obsession with RAD, and you can see it in many of the graphical features of Visual Studio. Since the vast majority of the work on software is maintenance and extensibility, rapid development is the antithesis of good software design. If tool vendors were really interested in making software developers’ lives easier, they would focus more on providing features to maintain software rather than develop it quickly and shove it out the door. That’s why refactoring tools like ReSharper have become so popular — their entire focus is on making it easy to mold your code into a useful application.

However, vendors are in business to make money, and RAD tools are much easier to sell than tools for refactoring. You can only sell a refactoring tool to someone that understands code, but you can sell a RAD tool to anyone — “look how fast we wrote this useful application!” I’m not faulting Microsoft or other vendors for wanting to make money, and I’m not saying that drag-and-drop tools are never useful. If you’re writing disposable code, that you’re certain you’re going to throw away, there’s nothing wrong with slamming something quick and dirty out. If you’re writing something for keeps, though, you better spend at least a few cycles thinking about how to make it maintainable.

Writing software is all about managing change. You start by building a core, and then you start building layers on top of it. With each added feature, you are applying changes to the application as a whole. This is why most of the tenets of good software design focus on limiting the impact of change on your system as a whole — or maximizing orthogonality, if you prefer. This is true throughout the software’s life, both before and after the initial release (the only real difference being the risk associated with adding each change).

Real software design cannot be drag-and-drop, because it’s an organic process, where your code is molded, sculpted, and cultivated over time. I commonly refer to malleable software, which evokes the right idea — flexible software that can be molded into something that solves your business problem. I would argue that there will never be a visual design tool that is more effective long-term than writing code manually, or at least not in the foreseeable future.

The bottom line is that the more you can limit the impact of change, the more easily you can mold and sculpt your software. The idea of RAD and drag-and-drop tools are only smoke and mirrors that mask the real difficulties that go into creating good software.

About these ads

From → miscellaneous

  1. Nicely put, Nate. I’ll be pointing people here rather than getting bogged down in and old debate next time the topic comes up.


  2. And as Greg Young, Bill Simser and friends put it: “Friends don’t let friends Do drag and drop…”:

  3. Rob Conery permalink

    Nate, I’m with you. Really. I CAN’T STAND the drag and drop demos and was recently bitten hard because I was trying to demo Windows Workflow and the designer made things look sooo silly simple that many (including Ayende) asked “why do you need this!”

    I won’t argue WF here – but I do like the graphical designer a lot because it conveys FAR BETTER than any code/comment combination, what the overall process and system goal is. That’s important – especially when you consider the nature of an ecommerce order.

    Could I write it in code? Well yah – I did just that initially. But I find that the world isn’t made up of “command-line guys” – it just isn’t. While I agree that the extreme to which you’ve taken this argument is valid (if I see a SQLDataSource again I’ll pull the rest of Jon Galloway’s hair out) – at the same time the power of visual tooling just can’t be parked like this.

    Consider that over half the real estate on Ayende’s blog is usually some form of visual to convey his point. Visio’s are used predominantly to convey process diagrams. If you do it right (as in all things) – you’re not going to hurt anyone. In fact you’ll have a better project as the code you have prepared will be better understood yes?

    Finally – I can’t tell you how ironic I continue to find it that the people who rip apart visual tooling cannot, I repeat cannot function PERIOD without Resharper. I wanted Ayende absolute fumble when we coded together, and Jeremy Miller was just about… no he was completely… USELESS without it.

    Tooling is as tooling does – you must agree that the issues in all cases are sitting in the chair. Tools don’t make people right bad code my friend… (but they do make people give horrible demos – we agree on this point).

  4. Rob:

    True, visual representations are helpful to convey information — it’s when the tools try to generate real code behind the scenes that things get funky.

    Consider UML, for example. It works great as a tool for diagramming, but then people said, “Hey! I know! Let’s generate our source from this diagram!”… and Rational Rose was born, making both IBM and the makers of Excedrin a bajillion dollars.

    My core argument is that visual designers hide the real complexities from the developer, making it that much more difficult to understand and manage them. I’m not arguing against tools on the whole; I love Visual Studio, and I’m worthless without ReSharper. I’m just saying that we should be spending more time developing tools that help us where it really hurts — managing change.

  5. Rob Conery permalink

    I dunno Nate – I do agree with many of your points but I think this post was a little too strongly-written to be honest. I fully agree with you that hiding complexity in terms of tooling can be bad… but “hiding complexity” is at the core of what your code is doing in the most cases … yes?

    I’m not here to bang the gong of WF – but I find that this is one case where I’m happy I’m not writing process code. I can think in terms of the process itself – NOT in terms of the code that enables it. This, to me, is golden.

    The ASP Calendar display comes to mind as well. This is a very visual tool and often I don’t want to get into the sausage and figure out all the styling for the dang thing – I just want to flip to the designer and (in proto cases) just use a canned style.

    Resharper writes code for you btw :). I agree it’s good code – the kind you need based on the interface you write and so on. But it still writes you code and speeds your process along.

    I can also write all the CREATE TABLE SQL commands, with all the FK constraints etc but I use the designer cause I’m lazy. And I don’t care what kind of SQL it creates.

    You and I agree about managing change – but there is a Refactor command that does some really cool stuff for you (like generating/implementing interfaces, creating method stubs, moving code around, etc).

    I don’t mean to come off as negative – what I think would be great is to know a bit more about what you’re saying. I don’t think ALL visual designers cause people to write bad code – I do think SOME do. I’d like to hear more about the one’s you don’t like and why and I really mean this cause I have this discussion a lot RE MVC internally and the degree of tooling that’s needed. I’m like you – I like to write the stuff and get close to the metal so I can feel the hum of the engine to see if the valves need to be realigned :).

    To the point – I’d love some concretes here, with specific reasoning. This would really help me when I get in these discussions and moreover – maybe there’s a way to make some good improvements to the existing tools. You game?

  6. Rob:

    Alright, I give. I’m making blanket statements, which isn’t really fair. There are *some* good visual tools out there. For example, I’m actually a big fan of the WinForms designers, even though it isn’t without its share of pain points. The key to working with every graphical tool is having at least a cursory understanding of what’s going on when you interact with it. Also, for the record, I love code generation when it works! I’d much rather generate code than write it. :)

    My beef isn’t really with any specific designer, or visual tools at all, it’s with the mindset that goes along with them. I think RAD is dangerous because it makes people ignore what I consider to be a very important (if not the *most* important) aspect of software development: designing for maintainability. Visual drag-and-drop designers just happen to be the most obvious spot where RAD appears in the .NET world.

    In my opinion, RAD tends to gloss over maintainability, favoring speed-to-release not by cutting features, but by cutting quality. I’d rather have an application with a solid foundation and less features, because in the end my stakeholders will be happier that they don’t have to deal with an inordinate amount of bugs caused by a mad dash for v1.

  7. Rob Conery permalink

    Wow! Epic failure with Captcha! Lost my comment!

  8. Interesting post Nate!

    Have you worked with Expression Blend? I think XAML is one good example of visual designers done right… There is no way I would want to write my gradient brushes or animation time lines by hand. One of the early arguments for using XAML for your UI in WPF was that it was “toolable”. I think that is a valid point to make when designing software, specially a UI framework. It also makes it easier to use good practices, and really separate the visuals from the behavior. I’ve used with other frameworks (like Java) where this was not a key concern, and the visual designers have been all crap (compared to Visual Studio Windows Forms, which I used at that time). The lack of properties, and a “design for designability” (as in visual tool) is probably some of the reason.

    I think @Adam’s picture really sums up some of the problem nicely. I think Microsoft presentations easily becomes 6-bullet-point power point slide decks with some pre-canned drag and drop demo in the middle. I do allot of speaking, and really try to break away from this pattern. For my Silverlight 2 talks at TechEd in September I’m move the focus onto more “real” problems, like which separated presentation patterns that work in a Silverlight context, dependency injection and the added benefit of mock providers to get a better Blend design time experience etc (hey, even I write code to make it work nice in the visual designer ;).

    Anyway, I think this is an important debate – and another sign of .NET developers starting to care more. I’ve definitely been in the position where managers have questioned my estimates after seeing draggy-droppy demos.

  9. Nice article. Couldn’t agree with you more. Not sure if this has been said (I didn’t read all the comments), but the D&D becomes a lot more danagerous from from a semi-technical/non-technical manager. “I just saw a tool that can do everything we want”. How many times has anyone heard that? :)

    D&D does have some uses in software development. There are some nice Web 2.0 prototyping tools out there that allow you to drag and drop and have a semi-functional app. In cases like those I think D&D is useful.

  10. Nate – While the general sentiment may ring true, the underlying assumptions and the resulting conclusions are far from accurate. Yes. A lot of people use D&D to perform demos. However, the key word here is DEMO. This is not production code. The people giving the presentation never claim that it is production ready, in fact 90% of the time the speaker says that up front. A demo, by it’s very nature necesitates the use of shortcuts. I know of a ton of D&D features that produce perfectly useable and maintainable code. In fact, if I ever saw you trying to manually create the code in a demo for implementing a web service proxy, I would probably question your competency. Every time I have seen this topic discussed, people miss the real issue. Many D&D tools do not generate great code. The key here is the code that is generated. If that code was 1) made visible and 2) followed good coding practices there would be nothing to argue about. So instead of arguing against D&D, maybe we should all focus on identifying the types of D&D which would speed up our development process while still leaving a nice maintenance path. The two are not incompatible goals.

  11. Very good points my friend

  12. This week I’ve been working in an awesome RAD D&D tool – The SQL Server 2005 Report Designer. It’s amazing how productive, accurate and awesome that tool is… :) Been using it before, but had kinda forgot about it – but I’m sure glad I’m not typing that Report Definition Language Code by hand ;)

  13. Jonas:

    I’m glad I don’t have to write RDL by hand also — but that’s a failure of the language, not necessarily a success of the tool. :P

    That being said, the Report Designer is one of the better RAD tools, but it’s not without its share of problems. The designer also gives you some pretty low-level control over things like the data sources and the queries that you use to develop the report, so I would argue that they’ve struck a decent balance between low-level and high-level.

    I’m admittedly making blanket statements, and there are definitely some RAD tools that are better than other. For example, I use the WinForms designer myself all the time, and you’d be nuts not to. What I *am* against is the RAD mindset — if you use the RAD tools simply because it gets the job done quickly, and you don’t consider maintenance a year or five years down the road, that’s where you run into trouble.

  14. Stijn Van Bael permalink

    Nicely put Nate.

    Still, I believe it is possible to have a tool that both allows for visual RAD and leaves options open for a clean design. The only reason there are so few of them is that they require significantly more effort to develop while not selling better than the quick & dirty tools.

  15. Nate:

    Great post. Also, along with convincing non-technical people that software is easier than it is, this also convinces up-an-coming developers that they can become software developers without knowing anything about good design. I can’t count the number of times I’ve had a client ask me to make changes to an existing site written in Dreamweaver and as soon as I saw it was a DW site, I knew there would be problems with the change.

    My $0.02

Trackbacks & Pingbacks

  1. james mckay dot net » Tourists and residents, Visual Studio and vim

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

%d bloggers like this: