Does our addiction on visual tooling harm the rate of innovation in the .Net world?

Here’s a peripheral argument to the current EF ruckus:  Is the focus on visual tooling hindering the rate of innovation in the .Net world?  At the ALT.NET event in Seattle, we started with a fishbowl session on polyglot programming (basically, using different languages and even writing little languages for the particular tasks that they’re best suited for).  One of the attendees thought polyglot programming was a bad idea because of all the tooling that each new language was going to require.  True, but hopefully false.  High ceremony languages like C# and Java require more tooling like ReSharper and IntelliJ to be efficient than lower ceremony languages or terser languages.  What if the alternative languages were usable for some specialized task without a lot of new tooling?  Think about scripting languages or external DSL’s that are tuned for specific purposes and really don’t require Intellisense and wizardry to be useful.

Think about it, visual tools and user interfaces are expensive to build, but yet we automatically assume that a tool is “better” if it comes with Visual Studio integration and other visual goodies.  Part of the cost of anything new Microsoft builds is a wizard tool or a VS plugin.  That cost inevitably detracts from the development of whatever framework or technology that the wizard is meant to help.  It’s an idle thought, but what if the Entity Framework team had focused on a textual DSL tool for configuration and modeling that was easy to use instead of relying on the more mechanically expensive designers?  Or made the Xml mapping simple enough that you didn’t feel like the designer was necessary?  Is it possible that they would have had more than enough time to make the structural changes in EF to allow for a Persistence Ignorance option in the first rollout?  Instead of the wasteful arguments about the design of EF, I might be a happy, card carrying member of the “Entity Framework Mafia.”

All I’m really trying to say is that I think we could gain some benefits by downgrading our reliance on visual tooling and software factories and Visual Studio plugins in favor of API’s that are terser, easier to read, and easier to consume.   My thesis is mostly based on my belief that language oriented programming techniques will often provide a greater return on investment than the comparable effort to develop visual tooling.  Or we could just concentrate on making better API’s I suppose.

As an aside, a couple years ago I spent quite a bit of time trying to write a user interface tool to help users write the StructureMap Xml configuration.  It was a mountain of work, and I gave up after becoming discouraged by the number of edge cases I needed to handle in the UI.  A couple releases later I focused on DRY’ing up the Xml configuration to streamline it, bulked up the diagnostics, and added the Fluent Interface style of configuration.  I’d argue that the Fluent Interface and Xml configuration improvements did enough to make the configuration easier that the UI tool is completely unnecessary.  I certainly haven’t felt like I’ve needed it in my daily work.  Now, I’d really like to get that very nice, early September day I wasted trying to write my StructureMap wizard instead of site seeing on the “Miracle Mile” in Chicago and going to the Field Museum.  Priorities.

That last paragraph is partially meant as a warning for the Unity
team because they’ve got a visual editor on their CodePlex release plan.  Trust me guys, there’s better ways to add value to Unity than
spending the necessary resources to write a visual wizard to write configuration.

A year or so ago (I couldn’t find the link), Ayende made the statement that any framework that required a wizard must have a terrible API.  Assuming that he really did say that, and I’m not making that up, ditto from me.  Don’t believe me?  Pick any of the bigger 3rd party WinForms control libraries and try to configure their grid control without a designer. 

One of my beefs about WPF (I do actually like WPF overall) is that the Xaml markup and object structure is clearly optimized for tooling rather than programmatic usage.  It’s certainly possible to do dynamic layouts and DSL things with WPF, but it’s clearly not the way WPF is meant to be used and it showed.  That’s really too bad because the actual technology behind the scenes seemed to be rock solid (once we wrote our Fluent Interface for dynamic forms it worked very well).

Just think, if we weren’t spending so much time as a community trying to build visual tools to make up for bad API design, how much more time we could have for “is the var keyword the work of the devil, or merely an occasional way to make code more readable?”


Now discuss. 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Jon Kruger

    I would agree that for most people that are involved in the discussion, a fluent interface is probably something that feels better to you than a designer. That’s because you’re probably experienced enough (and smart enough) to know how they work. You don’t really need a designer.

    I will say this though — I’ve worked on 3 projects with Nhibernate and one with LINQ to SQL. The LINQ to SQL project went much smoother than the Nhibernate projects and I had much much fewer questions from devs on how to use it. Now I think the main problem was that we didn’t generate the Nhibernate mapping files and tried to write them by hand, which is pretty hard to do (and time consuming). Most people that would agree that Nhibernate is a more mature ORM than LINQ to SQL, so it’s not like our problems were due to Nhibernate being crappy (because it’s not crappy).

    You could argue that our problems with Nhibernate were due to the fact that we didn’t really take advantage of the tools that were out there (namely, code gen tools), and you would probably be right. But the fact of the matter is that it happened, and it happened for me on 3 projects, all with different developers. I don’t think that I was a bad developer back then and I don’t think that the people running those projects were out of touch. We just weren’t aware of the code generation tools.

    I think this is the big advantage of MS including designers. It probably doesn’t matter much to any of you, because you already know what you’re doing. But for someone who isn’t quite as informed, it makes development a heck of a lot easier. In the end, more people are able to accomplish more in less time.

  • Adelle Hartley

    It has been my experience that the visual-tool-using masses deal with lots of code.

    Complex code that’s hard to get my head around sometimes.

    I spend a lot of time *reducing* the amount of code in other people’s projects.

    Yet, somehow, those of us who “live to code” give the impression to others that we

    must be writing a lot of code (because that’s what we spend our time doing), but I

    think we are typically writing less code per feature.

    I think visual designers and code generation are both symptoms of immature

    languages/libraries/environments, but are a good stop-gap measure for actually getting

    stuff done while those other things are being worked on.

    Take generic types, or their C++ precursor, templates. Before either of those things

    existed, similar results could have been achieved using code generation, and probably

    were – using macros.

    I for one would not want to have designed a programming language without the

    experience I’ve gained from writing code templates.

    I think that in the future, a lot of the things for which we’re now using code

    generation will become part of the programming language.

    BrianE: I find that the Visual Tools can be useful learning tools too, but much more

    so when they produce code that I can (or am expected) to edit and refine further, such

    as the ATL and MFC wizards.

    That said, I prefer the “cookbook” approach used by python, ruby, and linux generally.

    I usually follow the steps blindly at first, only understanding enough to fix my

    mistakes as I make them, but with each iteration more understanding is hard to avoid

    whereas “not learning anything” is much easier with a visual tool.

  • surf

    Nice Post. Posted this link in .Its a social bookmarking site.

  • BrianE

    I’d say visual tooling helps inovation far more than it harms it. A large part of the population are visual thinkers/learners. Without the visual tools would they be around?

    For me the visual tool is a learning aid. If I’m looking at using nhibernate, I don’t want to waste time learning how to map everything by hand if I’m not going to end up using it. If I decide to use it, then it might be worth my time to learn the mapping syntax. Same for Linq to SQL, EF mapping, or any other xml configuration file out there. And, no, it isn’t that difficult to learn the syntax, but a visual tool is even easier. And as a potential user of whatever product, one of the features that carries some weight with me is how quickly I can become productive with it from the start.

    I think it is easy to forget that at one point we’ve all probably used a visual designer as we learned a new tool. We quickly outgrew it and decided that anyone who used it doesn’t know anything about the tool. Just because we don’t need it now doesn’t mean someone else doesn’t. And just because they need it now doesn’t mean they will tomorrow.

  • Jeremy D. Miller


    It’s not the size of the language that’s the issue, it’s the amount of ceremony that C# requires in the code.

    I think there’s two extremes that languages evolve to. I think that any static typed language is going to need ReSharper/Refactor Pro/IntelliJ stuff to be efficient for coding. Maybe getting much stronger type inference like Scala or some of the functional languages would help.

    On the other extreme, I think duck typing will help just by condensing the code down. Intellisense isn’t quite as important when there’s so many fewer symbols and declarations in the code.

    We’ll have to see what C# 4 is really bringing (some of the rumors sound interesting).

  • Scott

    Re ReSharper being necessary. Do you think that’s because the language has gotten too big? Or the framework is too unwieldy?

    Would a slimmer, “pocket” .NET language be a better choice or is C# running about as lean as it can get?

  • Catherine Devlin

    I’m an outsider – a Python-lover. I keep trying to dabble in .NET, because of IronPython and because there’s a neat .NET community where I live. I think the visual tools are why I never get very far. it’s a whole different way of looking at a problem; I feel lost if I can’t look at a concise screenful of code and think, “OK, *this* is what’s going on here.” I can be walking through a tutorial in Visual Studio, and things are happening the way the tutorial says they should, but I feel like it’s sorcery and I’m not learning or understanding a thing.

    I’d really rather be an omniglot programmer, but the visual vs. text tools split is a barrier I haven’t gotten over yet.

  • Jeremy D. Miller


    I’d put ReSharper just a couple notches below “Oxygen.”

    I think the features of ReSharper or a Refactor Pro — Live Templates, better statement completion, refactoring, and so on, combined with Fluent Interfaces make C# faster in scenarios where I would have turned to Xml metadata or just used a designer in times pass. Extension methods and Lambdas also help shrink down the codebase here and there.

  • Mike Hadlow

    The real problem with visual tools is that they don’t scale. Sure, they make for great demos, but if you’ve ever seen an even moderately complex BizTalk orchestration or SSIS ETL diagram you’ll know that visual representations can be much harder to understand and manipulate than textual ones.

    I blogged about this a while back:

    Visual Tools: Marketing Dream Programmer’s Nightmare…

  • Scott

    Jeremy right on brother. This is yet another indication of the pathos that surrounds the .net development culture (I can’t speak to Java since I haven’t been in that space for almost 8 years). The focus coming from redmond and being copied elsewhere is on the demo-able experience at the expense of the real developer experience.

    A question to consider: when was the last time you worked with a product that had a significant investment in the visual tooling that you didn’t end up having to fight the programmatbility flaws of the API (such as you mentioned with WPF) due to sacrifices made for the “sweet visual stuff”? When was the last time you used one of these products in a non-trivial way and found the visual tooling so comprehensive and perfect that you didn’t need the programmability part of the API?

    From WinForms to BizTalk to reporting suites to control suites and all points in between, the answer for me to both of those questions is “never that I can recall”. But I’ve used plenty of nonvisual APIs that were far more tolerable.

  • Rob Conery

    So where do you put ReSharper in this thought?

  • Jeremy D. Miller


    Good lord no, I wasn’t implying notepad and a compiler. I’m trying to say that I think language oriented programming, lots of ReSharper-fu, and even the new language workbench stuff coming from JetBrains and (romoured) Microsoft will make us more productive than wizards can.


    Dude, this isn’t masochism here. I’m actually questioning whether or not visual programming is more efficient than other options.

    “Stop coding stuff which you could design and drag as well.”

    You’re making an assumption that design, drag n’ drop are more productive than coding can be. I’m refuting that assertion. I think better coding techniques are already changing the equation.

  • Heinrich

    Call me a Code Monkey : no way Im gonna write programs with only notepad and the compiler. I love my sanity to much

  • JV

    Visual Studio tooling is meant for the masses. The masses don’t read and react on blogs, so you will never get a clear view. The problem with all the people here (including me) is that they have a more advanced view on how to build things and that normally doesn’t fit with the designers.

    If you add up, that indeed most stuff is designed for usage with design tools instead of coding, then you indeed get strange feelings about it, adding stuff like fluent interfaces to your code (in addition ot the designer) it would definatly be better.

    one big BUT: Most people here are loving coding too much. They want do too much in code. Designers are not bad ok, they just don’t fit the needs in all cases for us. Stop coding stuff which you could design and drag as well.

  • Jeremy D. Miller


    It’s in the StoryTeller subversion repository in the ShadeTree.Binding project. There’s some simple examples in the StoryTeller.UserInterface project.

    UID: guest
    password is blank

  • Morten Lyhr

    “once we wrote our Fluent Interface for dynamic forms it worked very well”

    Can we get a taste of that some where?

  • Cy Huckaba

    I agree with Steve B.

    Microsoft cares about adoption numbers and the lowering the barriers to entry.

    I heard a Regional director say it best when asked about pricing on visual studio at one of the launch events. They spend an enormous amout of money developing visual studio to basically sell it at a loss (or give it away), because developers _sell the stack_ (Server and PC OS, Server Software, etc).

    We write the programs that keep people on windows. The majority of their community sites and and MSDN is largely based on getting more developers using their technologies. If that means making some things so simple that the guy who knows how to write a macro in excel can now bridge the gap to do visual basic or work within Visual Web Developer, then so be it.

    Some of non-MS based tools are getting more adoption now because of the Eclipse initiative and visual designers. Some component companies are so successful because the visually help someone setup the parent-child datarelations in a master details view. Can you do it yourself? Of course. Are they making a ton of money? Absolutely.

    The fact that the adoption rates on the visual tools are so high is just more evidence that the people that read blogs like yours and follow the ALT.Net movements are the minority. Try getting the excel macro guy to write a build script when he knows F5 (or a click of the mouse) will handle all of his needs. There are a ton of developers out there that just don’t care or don’t have to care.

    We have to cut our profession some slack. This is no different from any other profession. Think of how many mediocre people in other depts and companies in your career.

    In the end, that excel guy may get the rest of his office to upgrade to the PRO version because he created an Infopath form in the designer. $$$ for MS. He doesn’t care that he doesn’t have a domain model or unit tests.

    I was following a thread on the altdotnet group the other day about how to get principles out there and teach some of the group the principles. The answer might be to get some visual tools (even if only for configuration) for some of the products to help with adoption.

    MS will gladly listen and make changes but I’m guessing that any changes they do make with things like EF are motivated by the fact that this group can be vocal in the community and persuade people to stay away from technologies or go anti-MS…which will affect sales. You can bet they are looking at the $$$ impact rather than trying to decide what’s best for the dev community.

  • Steve

    I think you should distinguish between ‘tooling’ vs. ‘code generation’.

    Some tooling is great to have – ie. Resharper, intellisense, etc…

    I certainly don’t want to spend all day coding UI’s such as HTML/XAML in notepad all day.

  • Simone

    I think that .NET is lacking from the innovation stand point, and that specific DSL are good and don’t need a visual UI to build on them (see processing, which a DSL based on java for building visualization and animations), but I think this is the usual debat between alpha-geeks and the other 90% of the development world.
    The typical developer will use the software factory inside WCSF to build an app with the MVP pattern, while you and I will probably build it from scratch or even write our own mini lang to configure it.

    Speaking about WPF, I guess that it’s main focus was to be designed by a tool, because it’s a designer (as in someone into graphic design) that is supposed to draw the UI, and he needs a visual designer.

    We can apply the same thing to any other tool: what is the biggest percentage of user more likely to do? Write a configuration on file, or use a designer? if the answer is “a designer” than people will build one.

    The Class Diagram designer is cool, but none uses it… probably because everyone is confident with the “language”

  • Mike

    Visual tools are great when they project against raw code, class designer is the only one I really like, which is by the way, ridiculously complex and difficult to build.

  • David Mohundro

    Completely agree. This is one of the things that drives me batty regarding EntLib (plus its configuration). I don’t want to have to pull up a DESIGNER to configure this thing. I don’t want to pay the XML tax to configure it either. Just give me something that will diff/merge well in source control and that is easy to type and read.

  • Aaron Erickson

    Generally, my personal preference is to let the language evolve to where the really good people can be fluent using it as a language, and then, and only then, start building designers and other higher level abstractions on top.

    The problem isn’t a visual designer in general. Especially for concepts that require it (i.e. describing visual things, demonstrating big picture concepts, etc.). It is, on the other hand, an anti-pattern for designs that need to be fluid, as once the visual design is perfect (i.e. all the boxes in the diagram moved around to make it visually appealing) – you introduce friction to the change process – i.e. a heavy refactoring of the code base can mean you have to re-arrange all the pretty boxes for the printout that you are giving to management of your design, which is yet another thing that a developer has to do that isn’t really contributing to the design itself.

    On a more abstract level though, I have a distaste for the designers because of the message they send – now that it is visual, it takes less effort to make a good design – so now we can cut the design budget. We can just hire any idiot to write the design, since heck, I can train a monkey do put boxes on a screen and call it an architecture.

  • LukeB

    Excellent post.

    IMHO, one quick way to separate “real” software engineers vs. code monkeys is to have them write a program using only a compiler and text editor.

  • Chris Cyvas

    Come to think of it, you could take as a measure of effectiveness, how much time you spend answering questions and helping people use the product. If it is not a lot, then you probably have a good API / application. If you spend a lot of time helping people, then chances are your API / application needs work. If the EF / Unity folks want to drive value into the product, then put them all on the forums to answer questions. There will always be those that need a little more help, but if by and large you can walk away from your forums for a week or two and not feel like you are abandoning your users, then you are probably in good shape.

  • Chris Cyvas

    This is a very good post and I would argue that the same goes for application development. In the early days of the CSK, there was a heavy empahasis on “bling” – meanwhile, much of the core bits never worked well. With the latest dashCommerce 3.0, the focus was on making the application work first. Now that there is a stable foundation, we can start rolling in some of the programming and application enhancements that drive value to the users. Not to mention, I spend A LOT less time on the forums. :)

  • David Fauber

    I agree with the sentiment and Ayende’s lost quote. Anecdotally, I’ve found the developers that I’ve worked with who abhor designers are vastly more skilled than those who rely on them.

  • Jeremy D. Miller


    Now see, if I’d just put down the stinking VS editor and gone outside that day, I’d know that.

  • Brian Donahue

    Hi Jeremy,

    I think your point is very valid. I think it really boils down to the prioritization of effort. Design of the new feature/language/tool should be priority number 1, and supporting tooling should only be considered after a stable, useful product is ready – and only then if it is going to provide a real benefit in terms of maintainability and/or reducing the initial learning curve or startup cost.

    I think the problem you are discussing is that tooling is getting equal or greater priority to the actual solution of the problem at hand.

  • Ryan Gray

    Unrelated to topic:

    It’s called the “Magnificent Mile”.

  • Steven Harman

    @Steve B,
    I see where you’re coming from with the argument that visual designers are of utmost importance if widespread adoption is your goal. But I’d ask/argue, is that really OK?

    Meaning, are we, as a community, really OK with supporting a company that puts its bottom line ahead of what’s best for us, the customers?

    I believe a company is most likely to succeed when it does whats best for its customer, first and foremost. When that happens the customers will ultimately be happier with the company, resulting in wider adoption and a better bottom line.

    Though perhaps that’s just my naive thinking – having only taken a handful of business classes in my day. :)

    But you know what, even if that is just my naive perception of the situation – I still think that doing anything other than what is best for your customer is a sign of corruption and irresponsibility.

    And perception is reality.

  • Ayende Rahien

    Yes, I said it. Can’t find it either.

    I actually think that WPF and WCF coming up as out of band releases, without designers and many tooling support was a good thing.
    It made sure that they were usable without them. Maybe not as nice as it could be, but usable.

  • Jeremy D. Miller

    @ ninj,

    Sure, if it really is a visualization vs 1,000 words of error prone code, give me the visualizer.

    I don’t think it’s often that stark of a comparison. I really do think that Language Oriented Programming stuff, Fluent Interfaces, and little languages can reduce our actual need for visual tools. I’m making the assumption that the DSL stuff will be cheaper in terms of effort for the same benefits.

  • Corey

    There is already a designer, it’s called the Class Diagram. In addition, for those that have delved into the Entity Framwork at all. Whose bright idea was the “Update Model from Database” “feature”.

    I agree with your points about textual dsl. A month ago I would have disagreed, until we used the SimpleStateMachine in one of our projects. It was completely painless and more readable than anything ever put together with WF.

  • Neil Mosafi

    Agree with your comments almost entirely. As a developer, I’ve never understood why I would need to use a design tool to write code for me, it just makes no sense. Hence I never have.

    However there is one task where a visual designer is pretty key, and that is designing! As a developer (of e.g a wpf/silverlight app) I do not want to have to worry about the visual aspects of my UI when I have a graphical designer working on the project. He can work on them in the design tool of his choice without getting in my way. I think this was a good choice by Microsoft

  • Steve Bohlen

    I think we have to distinguish between ‘better for the technology to progress’ vs. ‘making it easy for widespread adoption of a technology’ here.

    Your points are well-taken re: the resources needed to develop VS plugins, etc. (the visual-designer-overhead problem), but given that the dev platform of choice for .NET (tho not for EVERYTHING to be sure) is Visual Studio, then developing a VS designer for your technology is the single best thing you can do to spur its widest adoption among .NET developers.

    You just have to decide if that (largest-adoption-possible) is your goal or not. For something like StructureMap, since you don’t sell it for money, wider adoption may make you feel better about yourself, but you have (not at all incorrectly, I might add) decided that its more important to you for a (relaitvely) smaller group of users to say “nice work” than for your adoption numbers to skyrocket.

    As you point out, it is definitely about priorities. As Microsoft is in the BUSINESS of selling software, they (correctly) view a visual designer as the ‘cost of playing’ in their .NET universe since widest adoption is DEFINITELY their goal for their own stuff.

    This is the same challenge faced in re: eclipse plugins in the JAVA space; a lot of really great Java technologies suffer lower adoption if they lack an effective Eclipse integration story. For OSS stuff, who cares (except in an abstract sense) but for commercial vendors, widest adoption is sort of the goal of their whole business of course.

    FWIW, I’m not arguing for a StructureMap VS designer :) but pointing out that if widest adoption is your goal, then that would actually be a good place to expend effort (even though it lends comparably little value to the actual ‘capabilities’ of StructureMap itself).

  • Björn Rochel

    It always boils down to the VB legacy, doesn’t it?

    Microsofts idea of the easy entry to visual programming and their conclusions towards beeing productive as a software developer are one thing I particularly don’t like about the .NET Framework (especially the “You need a specialist for everything”-advice).

    All this designer stuff seems to free you from the need to really understand the underlying API, but does it succeed or is that really an improvement in any way? I’ve been working inside a large development team (> 20 devs, very different skill levels) for quite a while now and believe me, I’m tired of seeing stuff like the typical DRAG-BUTTON-DOUBLECLICK-WRITE-CODE-BEHIND-WINFORM, which imho almost everytime results in a maintanance nightmare or untested code. Besides that when trouble starts (for instance the crash of the designer) you’ll have to know what happens behind the scenes or you’re lost. The designers won’t get you anywhere near that knowlege.

    So, does our addiction on visual tooling harm the rate of innovation in the .Net world? I’m not quite sure about that, but I often feel like that it keeps a lot of us from becoming better developers or advancing as a developer, because the whole designer idea somehow suggests using theam is kind of “best practice”. In my opinion using designers results very often (not always) in quite the opposite.

  • ninj

    Visual designers? Sometimes a picture is worth a thousand words.

    So, are those thousand words useful maintainable code, or just fragile, error-prone nonsense?

  • Ian Cooper

    The designer that ships with LINQ to SQL is a great example of waste. It pushes people away from the simpler model of marking up their domain toward generated partial classes. That has just sown confusion. It is also less fully featured than, for example, SQLMetal, the command line tool. It would have been better to spend the effort exhausted on that designer on mapping Value types (i.e. support for fine grained object models).

    When the EF team reached the point that their model was so complex that it needed a designer, and could not be realistically approached by hand, they should have stepped back and asked themselves if they were heading in the right direction.

  • Joshua Flanagan

    Oh man, I just spent the night writing TWO posts regarding the var keyword, and now I have to read you holding it up as a example of frivolity. Maybe my blog should go back into hibernation for a few more months ๐Ÿ˜‰

    Other than that, right on ๐Ÿ˜‰