Interview with Sun/NetBeans' Tim Boudreau

By Matt Stephens
October 31, 2004

Tim Boudreau has alternate roles as senior developer, product manager and head of marketing for NetBeans and is co-author of NetBeans: The Definitive Guide. He's been instrumental in improving NetBeans' usability in recent years, and in turning the product around so that it's better positioned to compete with the likes of Eclipse and IDEA. With NetBeans 4.0 nearly out the door and 4.1 looming, this seemed like a very good time to ask Tim some questions...

[Matt] So when did you first join the NetBeans project?

[Tim] In the spring of 1999, I'd been consulting for a bunch of years, including doing some tools work, and decided it was time to do something different. In looking around, I found an ad from a small Czech startup company called NetBeans. On a whim, I sent them a resume - I'd visited Prague the summer before and liked it. I figured I'd never actually get a response... Five and a half years later, I'm still living in Prague and working on NetBeans! It's funny where life takes you.

… so you've seen it grow from quite an early stage then. From a personal perspective, what do you think has been the single biggest improvement to the IDE over the last few years?

I'd narrow it down between the 3.6 window system and 4.0 projects - they're both huge improvements, but in such orthogonal areas that it's comparing apples and oranges to say which is more important. Both are highly visible.

Less visible, but also very important are the metadata repository and the new 4.0 java source model APIs. This is more under-the-hood stuff which creates all sorts of possibilities for new modules that simply weren't feasible before.

 

Fierce Competition

NetBeans seems to have woken up to the spectre of fierce competition in the IDE space - need I say Eclipse, IDEA, JBuilder and so on… Was there a "defining moment" when this happened?

Personally, the defining moment for me was when Eclipse was launched - here was a project that was (less the non-standard "standard" gui library) a carbon copy of what we were doing to the point that you could have swapped the words "NetBeans" and "Eclipse" throughout either web site, and except for the SWT stuff, either site could have been about the other. And IBM was clearly spending vast amounts of cash to promote it, which Sun at the time was not doing for NetBeans. I was the product manager for NetBeans at that time - more or less, all the marketing there was for it.

It was a bit like waking up to discover you've got the lead role in Bambi vs. Godzilla - here's your deer suit. There were some real issues in NetBeans UI, and I decided to put my money where my mouth was and move into development. For the last couple of years I've been working with a great bunch of folks on fixing those things.

That was the defining moment - it's what happens after that counts. Turning a battleship is slow, but over the next year we got started making the needed changes. We put together small team of very good engineers to design the new projects, including one of our usability gurus. The 3.6 winsys work was happening in parallel. With 4.0 we are in a much stronger position than we have ever been, with all sorts of improvements - at the same time that Eclipse is starting to show some growing pains. So it's a very good time for NetBeans and I'm very happy with the way things are going.

NetBeans also seems to have suffered in terms of its perception amongst potential users. It generally isn't seen as the "cool" IDE of choice, despite its huge feature set and ever-improving usability. Is this primarily a marketing thing, or are there other factors at play?

The big reason for that perception is simply, IBM spends a huge amount marketing Eclipse. Buzz and quality are two different things. The fact is, we earned a lousy reputation for usability and UI in the NetBeans 3.0 through 3.5 era. Anybody who tried NetBeans back then is in for some very pleasant surprises with 4.0 - the job now is getting the word out, and that's happening.

Eclipse is starting to place a greater emphasis on its abilities as a generic application platform. Of course, NetBeans was the original "extensible platform/IDE" - in fact my own project at work uses the NetBeans platform as its base. Do you think this aspect of NetBeans will be emphasized more in the future?

"IBM has done this pretty amazing reality-distortion thing around Eclipse"

Yes.

IBM has done this pretty amazing reality-distortion thing around Eclipse - there are some people now who actually believe that Eclipse was the first open source Java IDE, or the first modular one, or the first rich client platform, when NetBeans was doing all those things years before. The marketing effort around Eclipse is a work of art, and my hat is off to the marketing and PR folks who achieved it. It certainly proves that throwing lots of money at a tools marketing problem is one way to solve it. We're not about to let them get away with that twice.

Thunderclouds on the Horizon

Of course it's not all sunshine and joy. In any major product overhaul there are bound to be at least one or two questionable decisions - in particular, the decision to remove certain features in order to compete better. I'll cover a couple of those here:

1. The Filesystems UI was great because it was simple and very easy to understand and get to grips with. Got a directory with a bunch of java files? Just mount it as a filesystem. Although the new Projects system has some nice features, it can also get in the way - particularly its insistence on creating a subdirectory beneath the directory you're setting as the project directory. It means that you have to tailor the project directory structure to NetBeans, which previously wasn't the case. This can be problematic if some programmers on the team are using their own preferred IDEs, e.g. IDEA.

Wow, I need to turn this into a question, don't I? So - Why the decision to remove filesystems in NB4.0? (I'm presuming that it's still there hidden beneath the surface, but just replaced in the UI with the new projects system).

"[The Filesystems approach] was great once you got it, but terribly enigmatic for new users"

There is a module, contrib/mount, which replicates 3.x mounting, so anyone who prefers that style of working can still have it. There were a bunch of problems with the assumption that Filesystems == Classpath: Remember the slightly bizarre properties of mount points, Use in Compiler, Use in Debugger, Use as Documentation? Not only did these bewilder users - they were evidence that this was a round peg vs. square hole kind of issue.

There were plenty of usability studies that showed that the concept of "mounting" your classpath was where new users just gave up. I mean, really, I've watched people flailing around trying to figure out what to do with it. It's great once you "get it", but terribly enigmatic for new users, especially those without UNIX experience, who just don't have a metaphor for what "mount" means. You're right that Filesystems do still exist under the hood, but the assumption that Filesystems == Classpath does not. Beyond that, for almost any non-trivial project, a compiler is fundamentally the wrong tool for handling dependency management. But the mounting UI encouraged mounting sources for different projects (not to mention overlapping mount points), which meant you never really knew what you were compiling against. For a small project with one source tree, that's fine, but for anything larger, it creates all sorts of troubles.

Finally, the entire system of different compiler types for different types of projects, all of which were working with the same model for the classpath, but could do radically different things, made the 3.x system for compiling, debugging and executing inherently fragile. For example, the web apps modules had to jump through some really bizarre hoops to shoehorn the runtime classpath of a web app into Filesystems, so the right things would be on the classpath when the app ran. This put constraints on what kind of UI they could expose to make developing web apps easier (remember the strange popup window that told you there was a "logical view" of your web app on the projects tab?).

In 4.0, a project has a lot more ability to present itself in a way that makes sense for it, rather than the one-size-(mis)fits-all approach of 3.x. The decision to make this change was controversial, and by definition that makes it not a decision everyone likes and agrees with. But one must be willing to make hard decisions sometimes, or be permanently paralyzed. It was the decision needed to make to make the new projects work viable. I regret that it upset some folks - but note that if you read the archives of nbusers, a lot of people changed their minds about disliking it as the new projects support matured. Most of the objections came fairly early in the development cycle.

2. Why was JSP compilation replaced with "validation", which does a far less effective job? I know of several highly disgruntled web developers who've either switched IDEs or stuck with NB3.5 because to them, this was NetBeans' single most useful feature. (I know there's a "JSP compilation" module which can be added to 3.6/4.0, but it still doesn't do as good a job). Any plans to reintegrate "proper" JSP compilation into the IDE?

It's back in 4.0. Here's the answer straight from the web team lead:

"In NB 4.0, we implemented JSP compilation on the new buildsystem, so JSP compilation is now a target in the Ant script. A JSP is always compiled if you run it using Shift+F6, or you can trigger compilation by F9.

"You can also specify in project options whether you want to compile all JSPs as a part of the web application build (turned off by default).

"One problem is that JSP compilation does not work in freeform projects yet, only in normal web projects."

One problem with the NetBeans OpenAPIs is that there's one hell of a learning curve to become proficient with them. It's daunting for newbies, and I'm sure that a lot of people look at the APIs, then decide to just create their own Swing apps from the ground up, pulling in third-party APIs as they need them. Are there plans to simplify the APIs, or at least improve the tools support to make creation of plugin modules (and standalone apps based on the NB platform) easier to create - more of a drag & drop process?

You know, it often seems strange to me that there isn't a discipline of "API Usability" akin to the UI usability. We are actively looking at how to make common uses of the APIs simpler, and provide better tools support. Look for more on this in the coming months. One of our most senior developers is specifically tasked with fixing this, and API Usability is now much more a part of the API review process. I really think 'Writing Usable APIs', if well done, would be a real winner of a book title for a tech publisher. I've never seen it addressed well, if at all.

The declarative style of designing windows and so forth can also be quite tricky to work with. Are there plans to either document this area more fully or add better tools support?

Yes to both.

Although the new 'super-integrated' Ant project/build system will please a lot of people (particularly those people who already use Ant for their projects), I've spoken to a few programmers who expressed their displeasure (to put it mildly) at this development. I know you can't please everyone all the time, but... will these people still be able to use NetBeans without being exposed to the "Antness" of it, i.e. simply do a "Build-all", or compile a single Java class, as in previous versions?

A point that can't be stressed too strongly is that you don't need to know Ant to use NetBeans 4.0. The full power of Ant is available to people who want it, but people who don't know or want to deal with it, it's pretty well concealed. You do see an ant script on the Files tab, and the build output includes some messages from Ant, but that's it. Want to do a build? Press F11. Run the project? Press F6. Unit tests? Alt-F6. Debug? F5.

The things that make this system very powerful are: Unlike any other IDE out there, your project metadata is your Ant script and associated property files - and it's all versionable, sharable and human readable - Building/running a NetBeans 4.0 project from the command line is the same as running it from the IDE - so there's no lock in if your colleagues want to use Emacs or whatever, headless builds work, and teams aren't married to using NetBeans if they don't want to (of course we'd like them to :-)

NetBeans and Usability

Despite some of these problems, NetBeans' usability has improved a lot in recent versions, e.g. the new windowing system & properties panel in 3.6 and further improved UI in 4.0. Do you have usability/product design experts on board to help with this stuff, or is it still (to put it politely) a product "for programmers by programmers"?

The original NetBeans, circa 1999, was definitely "for programmers by programmers" and suffered because of that. For a number of years now, we have had a team of user interface designers who work closely with development to improve UI. These were the guys who did the UI specs for the 3.6 window system, and the customizers and UI design in 4.0 projects.

It's a collaborative process - sometimes producing a full design up front, sometimes work initiated by a developer which gets reviewed, sometimes iterative design if the problem space needs to be explored first. It depends on the type of problem and the skills of the people involved - contrary to the assertions of some publications, there is no magic formula - just responsible, talented people, a lot of sanity checking, observing real users, and common sense.

"Nobody gives 100% if it's assumed they aren't able to learn"

In the case of NetBeans, we have a team that did indeed make some major UI mistakes five years ago - and have been kicking themselves for it ever since, and have learned a lot. Now, if we had huge turnover on the team that develops NetBeans, more draconian separation of roles might be necessary, but of the original team that created NetBeans, almost everybody who was working on it in '98-99 is still working on it. People learn from their mistakes.

There's an attitude I've encountered, that design should be completely walled off from development. The only result I've ever seen from that in practice is to put people at each other's throats - nobody gives 100% in an environment rigged with the assumption that they aren't able to learn. So the simple answer is, yes, there are designers, they do great work and they play a critical role.

All of this isn't to say there aren't places where usability can be improved - the options dialog leaps to mind. But the new stuff really doesn't have usability issues, and the what's left of the old stuff is known and will be cleaned up soon.

Two excellent books for developers who haven't had a lot of exposure to the issues of UI design are Designing From Both Sides of the Screen, and User Interface Design for Programmers [see links below]

Future Plans

What exciting features can we expect to see in the near future to keep NetBeans at the top of the heap?

J2EE and Mobility support, and the JFluid profiler are at the top of the list. If you haven't seen a demo of Mobility, you don't know what you're missing - it elegantly solves the problem of needing different code to run on different devices the most natural way I've seen in any IDE. It's great stuff.

JFluid's profiling features are quite cool: The biggest problem in profilers is too much (irrelevant) information - so there's a bunch of work to get to where you're really looking at the thing you want to profile. JFluid lets you instrument individual methods and calls (and even change what you're profiling on the fly). So it's no longer a question of having this big wad of data and trying to filter out irrelevant stuff - you never get the irrelevant stuff to begin with. That's pretty compelling. (See http://profiler.netbeans.org for more info).

NetBeans 4.0 makes creating and running unit tests a natural part of the development cycle, rather than something bolted on afterwards; the profiler project aims to do the same thing for profiling. Both of these are things that belong in the mainstream of the development cycle - they get you better software - but have had a life apart because the tools support was not terribly great.

I got a demo last week of some of the new stuff in the form editor for 4.1. It's truly a fantastic piece of work. It owes equal inspiration from Apple's Interface Builder (pretty much the gold standard in intuitive GUI designers) and some of Karsten Lentzch's great work making good visual design easy - aligning font baselines and automatically adapting the layout to match the UI design guidelines for different platforms. And it fully hides the complexities of dealing with layout managers (the basis is SpringLayout, but none of the old layout manager support is gone, so you can still do everything you could before as well). I was truly impressed with it, and can't wait for it to show up in the builds.

And longer-term, is there a strategic direction that the team is planning to take the product in?

What we're doing is refining and improving on what we've always done - make developers more productive, support the technologies and techniques that people really use, continue to improve usability, and get the word out. Make sure the out-of-the-box experience is a good one - finding the tools you need should not be like going on an easter egg hunt!

Any plans for a 2nd edition of the NetBeans book? At the time it was written, the product was moving so fast that the book was more or less out-of-date by the time it hit the shelves. I guess this is always going to be a problem for any future NetBeans books...

There is work happening now on a new NetBeans book from another publisher - I can't say too much more than that about it right now. As for a new edition of the Definitive Guide, given the time, I'd love to do one - it's also up to O'Reilly, and how well we promote NetBeans in the near term.

Why do you think it is that this is the only book on NetBeans which has been written (at least in English!), when there are already several Eclipse books available?

Publishers generally don't do software books spontaneously, particularly developer-centric books - someone has to go out and interest them and make that happen. For the last couple years, there were not a lot of marketing resources dedicated to NetBeans, and so this sort of thing wasn't pursued as actively as it could have been. That has changed, and I will personally be involved in making sure we promote NetBeans effectively in the future.

The development space has changed a lot in recent years. Users are demanding more sophisticated features as a minimum requirement from their IDEs, e.g. refactoring, unit test support, J2EE debugging and so on. Getting out your crystal ball, where do you anticipate this trend going in the next few years?

"Tools that better understand your code and what you're trying to do"

There's no shortage of interesting potential problems to work on! Probably the thing that pops to mind first is AOP as something highly visible and different. Model driven architecture also has its fanatical supporters and detractors. But I've seen very few predictions in the IT business that came true, so I'd prefer not to add to the pile.

The most important thing may be what not to pursue. It's healthiest for tools to stay focused on making developers more productive. So you have to disbelieve the hype (including your own!), know who uses your product, what they do, and target that. That doesn't mean there isn't room for visionary stuff too - just that there are always lots of bandwagons you can jump on, and it always seems more exciting to jump on one and see where it goes. But the things that really add value are often the less glamorous things, so staying successful requires a healthy mix of vision and common sense.

The trend I see is tools that better understand your code and what you're trying to do - refactoring is all about that, and it's just the tip of the iceberg. That's an area where there are lots of possibilities to make developers more productive, and there's huge potential there which is barely tapped.

I recently rewrote the Navigator module to use the new NetBeans 4.0 Java API - the API that lets you get structural information and metadata about Java classes, find usages of things, and such. It's amazingly powerful and a vast improvement over 3.x - it makes all sorts of things possible in the area of tools that understand your code.

Look for more interesting tools in this vein as people begin to realize how much is now possible - it's very fertile ground.

Presumably Java Studio Creator has helped a lot with providing UI feedback, and feedback on the OpenAPIs. Is there a "branch" of NetBeans that those guys use, and if so will we see any of this new functionality folded back into the main release?

Due to the timing of their initial release cycle, Creator uses an alternate window system implementation that was put together in parallel with the 3.6 rewrite. Duplication is ugly, but sometimes you have business reasons to do things like that. We've implemented the things they still needed in 4.0's window system, and integrated various patches from the Creator team, and the next release of Creator will be based solely on the main NetBeans codeline.

I know a lot of people really like the windowing system, and would love to see it as a standalone Swing component. Any plans to do this - either separately from or as part of the core Swing package?

It's certainly doable, and I've talked to a few people who were interested in doing this. I know that the tab control, which is at the heart of it, is already being used in a few places. Making things standalone is generally a desirable goal - it tends to improve code quality - if you need things to tightly depend on each other, they're probably not providing the APIs they should.

I don't know that Sun will take the lead in separating the window system from the rest of the platform, but someone in the wider community could certainly do it, and as long as everything remained compatible there would be no reason not to accept such patches. A worthwhile question is whether someone who believes they need the window system wouldn't benefit more from building on the NetBeans platform as a whole - there are a lot of other problems in building a desktop app that it solves. So the standalone window system thing may be a bit of a chimera.

And for those who think building on the NetBeans platform must be a heavyweight solution, I highly recommend downloading the platform and starting it up solo, without any modules. It takes up all of 3 to 4Mb and starts like lightning.

Talking of Swing, does the NetBeans team generally have much contact with the Swing team at Sun? Can we get a scoop on their plans for new versions of Swing - and of Java on the client-side in general?

We definitely are in close contact with the Swing team, and have a very good relationship with them. As far as plans for Swing, there's definitely some interesting stuff happening, but I don't want to steal anyone's thunder :-)

One last question, again more to do with Swing than NetBeans, but… do you think there's much chance of Sun ever hosting a common UI components repository? e.g. if I create a super JTable it would be nice to be able to upload so that others can simply click on it and have it installed into the NetBeans palette.

There are quite a few interesting projects I think would qualify at JavaDesktop.

But you are right, such an integration would be a very nice enhancement - thanks for the idea!

That about wraps it up - thanks for your time.

Thanks for letting me ramble!

Related Books

Links are to Amazon.com:

Designing from Both Sides of the Screen: How Designers and Engineers Can Collaborate to Build Cooperative Technology A must-have book for anyone developing user interfaces. The authors define a seemingly simple goal, the Cooperative Principle for Technology: "Those who are designing, building, or managing the development of technology should teach their products to follow the same basic rules of cooperation that people use with each other." [amazon.com]  [amazon.co.uk]

User Interface Design for Programmers A brilliantly readable book with what programmers need to know about User Inteface Design. [amazon.com]  [amazon.co.uk]

Related Articles

Software Fashion

The Inmates are Running the Asylum

Talkback: Have Your Say

Post a new message

One thing I would like
Joe joecole@xtra.co.nz
NetBeans and Ant, why they made the right choice [personal opinion]
Iwan iwan@i-ware.net
Re: One thing I would like
Alexander Staubo softwarereality.com@purefiction.net
Re: One thing I would like
Mick mick@machina.no
[ECLIPSE] - Assimilate Strength / Reveal Weakness
Ilias Lazaridis 
NB Platform
Anonymous person 
Maven in NetBeans
rsm 
Eclipse not just marketing
dog dog@dog.com
NetBeans in denial
Ed Burnette eburnette@users.sourceforge.net
Request 4 help on NetBeans
Ameen cinestars@gmail.com

tjnaoqy ordlg
lauqrvfjs ltzm sizvgahbj@mail.com
brhtAyLqJh
vasya vasya@gmail.com
VtjfgBMjfQAe
vasya vasya@gmail.com
Couldn?t have done it better myself.
John openbsd@uevora.pt
That was first class work.
Bob liste@openbsd.de
PSTekrhaXH
djjkas97sdwq7 djjkas97sdwq7@gmail.com
IiUFxJvcpgAZS
Pochka aio@mail.ru
ED Pills
Marco lebedev@gmail.com
edit a node in tree table
Oren H oren7651@gmail.com

Post a new message

<< Back to Soapbox

<< Back to the Front Page