Early adopters and IDEs (integrated development experiences)

Tim Bray: “[H]ere it is nearly thirty years into my programming career and I’m still debugging with print statements.”

Heh. Same here, though it’s only been 25 years for me (wow, “only” 25 years?).

The lesson here is that old habits die hard—and that different segments of the developer community have vastly different expectations and preferences when it comes to tools. Case in point: Despite all the advancements in tools over the past decade (and despite the fact that I ran marketing for NetBeans at Sun for one of those years, and that I’m a big proponent of an IDE centric “connected developer” approach for Sun), my “IDE” of choice is still a combination of command line tools and Emacs.

Indeed, as I’ve learned over the years, this presents an interesting challenge for platform vendors. While grassroots momentum in the early adopter community is key to building a successful platform these days (think Linux, MySQL, and Amazon Web Services, among others), and early adopters will put up with a remarkable amount of pain to target these platforms (Linux, MySQL, and Amazon Web Services developers have largely relied, at least in the beginning and in many cases still today, on command line tools), what I call “integrated development experience” is key to taking these platforms to the mass market—and indeed can be an immensely powerful competitive weapon.

Think about how Microsoft was able to successfully leverage its Windows/Visual Studio/MSDN triumvirate to bootstrap .NET in the early 2000s, and how it’s leveraging .NET/Visual Studio/MSDN to bootstrap Silverlight today using largely the same techniques. Or think about how Apple is entrenching itself in the mobile developer community by providing dead simple drag and drop tooling for the iPhone, along with a (mostly) seamless publication and monetization vehicle via the App Store. What would the iPhone platform look like without this dead simple tooling? Let’s just say there’s not a whole lot of demand in the early adopter community for digital flatulence applications.

Of course, the real question for the 21st century platform vendor—one that understands that massive adoption in the early adopter community is key to success—is when to transition from a wild west, bubble gum and bailing wire platform strategy to a more neatly packaged integrated development experience. I’ve long argued that making this transition is key to taking your platform to the next level. When to do it is the real question. Too early, and you damage the limitless possibilities that make your platform so appealing to early adopters. Too late, and you expose yourself to competition from vendors that do a better job at capitalizing on the broader opportunity (and that’s best case—worst case, your platform fades away because it is never able to grow beyond the early adopters).

No one ever said this business was simple..

10 comments on “Early adopters and IDEs (integrated development experiences)

  1. Ooga Chaka

    Practically at the point of using java for systems programming so here goes

    pfexec pkg install netbeans-desktop … done … yay!!

    now .. can I use dtrace with java/netbeans and build an app with jython/jrbuy scriptable goodness and a xplatform UI (gtk? qt? gecko?, webkit, android?) for osol, linux, bsd, osx, iphone, openmoko, android vista? :-D Then … hookup via a few groovy javascript extensions to cool services from Yahooo (Sun please buy Yahoo if share price falls further) and badda boom!

    At least android’s vm likes java and netbeans eclipse etc makes java as easy-ish as .NET so …

  2. Pingback: Luddites or weenies? « niq’s soapbox

  3. scaryreasoner

    I tend to debug with print statements as well… it’s just, a lot of times, easier than firing up the debugger, setting breakpoints, stepping through, etc, to sprinkle a few printf’s around and see what’s going on. If you ever worked on the linux kernel (until recently) getting a debugger for it was enough of a PITA that printk’s were, and still are, the debugging tool of first resort.

    I tend to use gdb mostly when I’m getting a segfault… get a backtrace from gdb, then sprinkle a few printfs around.

    Gdb of course comes in very handy when printfs don’t seem to be getting you anywhere.

    Tom Tromey’s blog is one place to see some of what’s going on with gdb. He’s posted a few things recently about python extensions to gdb, mainly, I think, related to debugging C++ programs. I’m too much of a luddite myself to have much truck with C++.

    As for your gripe about “No way to use a window without raising it,” NO FREAKIN’ KIDDING! That is something that has bugged me for decades. The linux distro’s seem to default to similar behavior in their desktops, and it is literally the first preference I change on a new install.

    As for the mouse cut-n-paste thing, JWZ has an essay explaining X Selections, Cut Buffers, and Kill Rings which might explain things to any confused windows user who don’t know what you’re talking about.

    This comment was originally posted on niq’s soapbox

  4. Tim

    Correction: with enough poking, Mac OS X allows Terminal (and possibly other apps, but admittedly not OS-wide) to have focus-follows-mouse. It also allows move-without-raise using Cmd-click on background windows.

    Apart from that, I do generally agree. I tried, for various perverse reasons, to get into .NET late last year; while I was mostly impressed with MonoDevelop, the GUI scene left me cold. I used Visual Basic 3 and 4 in a summer job many years ago, and for getting from window to widgets to code they actually worked bloody well. This seems to have been forgotten, with MonoDevelop and Glade going after all the surrounding frutz in later versions of Visual Studio and none of the usability of the underlying paradigm. I gave up.

    Back to emacs for me, vi for you. They actually work. We know them and they do a handful of things well that is all we ask.

    And I still have choice-paralysis over the underlying languages (Q, scheme, lush, anyone?).

    This comment was originally posted on niq’s soapbox

  5. Lally Singh

    Oh, I meant the other way around. Will netbeans automate the creation of IPS packages for our software?

  6. Ian Murdock

    While I can’t speak to product plans, I can say that automating the creation of IPS repositories from within the IDE is a great example of the “connection developer” notion I mentioned in my post. Imagine you are building a native application in NetBeans or Sun Studio (or, heck, Eclipse). You not only want the traditional edit/compile/debug an IDE gives you, you want publish as well, whether that’s publication of your source code to an online community (for developers) or publication of your binary code in a form that can be easily consumed within the target platform (for users). So the “connected developer” notion should allow you to easily do that, publishing not only to IPS repositories (for OpenSolaris) but also APT, yum, etc. repositories for Linux etc. Tie that in to the package management system in the OS (or the plugin center, extension repositories, etc. for other products), and you have the makings of an “App Store” that spans multiple products, making the platform more attractive (because more software is available for it in an easily consumed format) and providing a go to market vehicle for developers that want to deliver applications directly to the users of that platform.. Win win..

Comments are closed.