IT must be nice to be Google. When the company decides it wants something, it can buy it, borrow it, or rent it. Case in point: IntelliJ IDEA. JetBrains has long offered the best Java IDE in existence. Despite competing offerings from the Eclipse Foundation, Oracle, and Red Hat, this much smaller tools company has been completely dominant in the Java IDE space simply because its software is now and has always been better.
IntelliJ offers oodles of time savers for developers, from advanced refactorings, to better syntax completion, to easier debugging. Every little feature saves you 5 seconds here, 10 seconds there. It’s about optimizing the actual workflows. An example: Eclipse requires you to exactly highlight a piece of code and press a hotkey to evaluate it and see its value. IntelliJ IDEA just figures out which piece of code you’re asking about when you mouse over it and press a smaller set of hot keys.
IntelliJ IDEA is just smarter about Java overall. It can be because it’s a dedicated platform, not a generic one being tweaked to cover specific languages. It’s also the type of software that is obviously being used by its creators. Ever get into a car and wonder if the original designers ever actually used the damn cup holders? IntelliJ IDEA’s developers have tried every cup size in every cup holder. The IDE knows Java top to bottom, and uses this knowledge to help developers understand their code faster and more efficiently.
You may never have heard of IntelliJ IDEA, but that’s OK because in the niche it fills, it is well respected and well known. Well known enough that when Google decided to build a better IDE for Android, the first thing it did was scoot over to JetBrains and find a way to base its own Android Studio on IntelliJ IDEA. This was, perhaps, the smartest move in development tools of 2013, even if it took years for the final 1.0 to arrive.
What Google understood about software development tools is that time savings is the name of the game. While most companies that make development tools run around touting new features, new plug-ins, and online marketplaces for purchasing expanded capabilities, Google has almost continuously taken the time to identify market leaders, and then find ways to distributing those tools for free to its developer community.
They did this in 2010, when they acquired Instantiations, bringing with it a set of Google Web Toolkit plug-ins for Eclipse, and some neat UI development tools. Motorola/Google bought 280 North in 2010 as well, in an acqui-hire that brought Web framework Capuccino and some ObjectiveC-to-JavaScript tools to the company. Those last bits basically fizzled, however.
Still, when Google wants to make better developer tools for its communities, it has the power and knowledge to do so. Just because you’re not Google does not mean you can’t copy their tactics, however. Your company should already have firm developer tools knowledge, if only in the engineering department. Utilize that knoweledge when making any roadmap changes or product decisions.
When you’re building tools to sell to developers, or even to simply hand to developers, you need to get into that developer mindset. That’s a mindset where a 27 second savings from build and compile to running time is just about the greatest innovation one could ask for. This is no exaggeration, either. The biggest applause I ever saw at a developer conference was when Google told the Android Developer Conference that they’d shaved 27 seconds off of every build-to-emulated process in the IDE. The room went insane. People were screaming. I think I saw one guy cry.
Why is that so exciting for a developer? Because a good developer is compiling and testing code dozens of times a day, if time allows. If not, they’re piling changes into larger builds and likely to miss bugs as the changes boil together. Faster feedback loops mean more confident developers, and better code overall.
Are your developer product offerings pretty, sleak, and covered with material design ideas, or fancy Web-based SVG animations? Then you’re doing it wrong. In the developer tools market, you can sell a command line if it’s fantastic. Indeed, some developers prefer those command line interfaces. They can be off-putting at first, but like most Linux tools, using them for any amount of time shows off the fine tuning underneath, and the surprising ease text-based interfaces can have.
Another example here is Amazon’s original customer service tool. It was said that it resembled a computer screen at the IDE: it was like Emacs: press specific buttons on the keyboard to trigger specific actions: no mouse, no images. And yet, this tool lasted for years inside the company because an experienced user could navigate decision screens in a matter of milliseconds. Response times were minuscule, as a worker could quickly learn that a returned package required them to press three keys to get to the right screen in under a second. When the system was replaced, workers almost revolted, despite the shiny new mouse-driven UI.
Another example comes from a large ticket reseller. This company processed millions of tickets-for-credit card charges every year, and its systems were originally designed in the 1980’s. At the core of this system was a perfectly constructed program written in VAX assembly language. This has since been replaced, but for a long time, and well into the 2000’s, this company’s core business was running in VAX assembly in an emulator.
Why? Because the engineers that had written this application had optimized it down to the bit. There was absolutely no way to make this operation any faster on a single CPU, even if the CPU was a modern Intel CPU running a VMS emulator.
The point I am making here is that software development requires many tools, but just because the tools are new does not mean they are any better than the old tools. Sometimes, they are worse.
When building a software development product, it can be very tempting to hit all the buzzwords and focus on making a flashy, newfangled system that ties into every cloud, every PaaS, and speaks every language. But always remember that you are likely competing with a 30 year old Linux tool and a stack of shell scripts. If those scripts and tools are better than your product, maybe your product should just be a better overlay for those existing things.
Sometimes, the best product is just an old but popular Java IDE with all the handlers for a mobile platform added in. There’s nothing sexy about a Java IDE, but using it can still make people orgasm.