Over the last few months, I've been looking at a number of development tools that purport to improve developer productivity. I'll eventually review them all in one massive roundup -- at least that's the plan.
Meanwhile, I'd like to report on a conversation I had a few days ago with Alan Fisher, chairman and co-founder of Iron Speed.
[ Martin Heller also offers a preview of Visual Studio 2010 Beta 1, as well as further highlights of Microsoft's IDE | Keep up with app dev issues and trends with InfoWorld's Fatal Exception and Strategic Developer blogs. ]
IW: Alan, why did you create Iron Speed Designer?
AF: The basic idea is that data-driven applications are similar, but different. By looking at the database schema, we can automate the generation of the parts that are similar.
If you look at the way we do application development, it hasn't changed much since the 1980s; we're still writing one line of code at a time. We may write that line faster and better since our tools have improved a great deal, but we're still plodding along one line at a time.
After the experience of building Onsale, my partners and I realized that we had a code base of a million lines of code, but that only 20,000 lines of code (2 percent of the code base) were special in any way. The bulk of the application was moving data in and out of forms and databases and into and out of other systems. So if we could automate the generation of the bulk of the code, the 90-plus percent that's essentially the same from application to application, we'd realize a huge jump in programmer productivity and leave time for the programmers to work on the code that's actually unique.
We focused on Web applications, basically departmental applications that were being moved from Access or Excel to the Web. These have a lot of commonality, because they're structurally similar. They all have the same CRUD operations, and reporting, and maintenance, and workflow. What we did with Designer was to automate the common bits, the data entry and import and so on.
An additional benefit of this comes when companies use the tool for all their custom business processes. Suddenly, all the applications have the same look and feel, not just the same colors but also the same controls and placements. That helps the users to learn and use the applications.
Another unexpected benefit is that it's easier to maintain generated applications because they all have the same code model; they all get customized in the same places. And because of this, IT departments can be more flexible in assigning personnel to maintain their applications -- they gain increased fungibility of developers. And that's important because business processes evolve all the time, and the applications have to evolve to accommodate the changed processes, even if the original developer moved to another project or left the company.
IW: Who uses Iron Speed Designer?
AF: Mostly it is used to build custom in-house applications, either by the IT department or by consultants. We do have a few ISVs who build applications for sale, primarily in health care. Also, companies often expand from in-house Web applications to custom partner-facing and customer-facing applications, for instance to do billing and invoice tracking.
IW: I have heard from some Iron Speed users that they find Developer limiting. Could you comment on that perception?
AF: First of all, Designer is not intended to replace Visual Studio. Some of the people who complain about Designer being limiting expect Designer to generate 100 percent of their application, because they don't really know how to write custom ASP.Net code. You have to use the right tool for the job.
In addition, developers do need to spend the time to learn Designer's code model so that they can apply customizations. That takes a day or two. We only try to generate 80 to 90 percent of an application; the rest is up to you. On average, we see people adding about 1,000 lines of custom code.
IW: When I played with Designer, I was surprised to discover that I had to edit the underlying HTML file rather than editing the generated ASPX and CS files. Why is it set up that way? Are you trying to avoid the round-trip design issue?
AF: In earlier versions of Designer, we had an HTML editor built in. We discovered that led to problems, because as you do more with your code generation, it gets harder to maintain user customization across a regeneration. So instead of trying to do that, yes to maintain fidelity on a design round-trip, in Version 6 we switched to a system that stores changes at the page layout level in a way that the application generator can understand, basically as a quick layout spreadsheet editor.
What we found was that customers don't want to make wholesale changes to pages. They don't want to deal with 1,000 lines of code at a time; they want to deal with just the 5 lines of code that will affect the feature they want to modify.
We have enhancements coming to this. Going forward, we want to make code customization easier, to minimize the code model that needs to be learned, and to reduce the learning curve for new users.
IW: Thank you!