Prediction #9: Majority of developers demand access to Agile/ALM tools from IDE, look elsewhere for pretty colours and oversized fonts
Back when we worked on systems that were tens of thousands of lines of code, Integrated Development Environments (IDEs) were a nice option, but often ignored by the alpha geeks living in Emacs and vi. Now that even mid-sized enterprise applications are close to a million lines of code when both the application and its dependent libraries are considered, the majority of professional developers see the structured editing and navigation facilities of an IDE as a fundamental requirement.
The initial evolution of the IDE and of Application Lifecycle Management (ALM) tools was independent. A decade ago, the OTI folks at IBM, master tool builders with their roots in the Smalltalk era, created an Eclipse integration layer that made CVS feel like a modern SCM system. That seemingly impossible feat taught tool builders an important lesson. Even if you had a grossly antiquated service, you could provide a modern and high fidelity experience in the client. A few years later, the initial Mylyn release signalled the next step of the convergence, by providing a modern task and issue tracking experience in Eclipse for Bugzilla. The migration from disparate web and command line UIs into an integrated coding-centric IDE was well underway.
Since that time, countless developers have recognized the time wasted by switching to a web browser in order to update an issue or to start investigating the latest must-fix defect. Application switching itself is relatively small time sink, adding up to an extra coffee break or two in the workday (i.e., 4% of the pie in the figure below). A far greater problem is that browser-based applications are ignorant of the system’s structure. This means that the burden of mapping between the code and the tasks driving our programming activity is placed on our already over-taxed brains. If a stack trace appears in a defect, we have to copy the stack frame, paste it into a search box, and iterate this process until we’ve found and fixed the issue. If this turns out to be something which must be handed off to someone else, then all of the research, analysis and other task-related state which has been built up during the exploration gets tossed out when we reassign the task, and the wasteful process is repeated. It all feels very 1990s. In my PhD research I measured the impact of this repeated searching, task-related context switching and redundant code navigation. These numbers were similar to the more recent ones visible in the figure below. Around half of a developer’s day is going to waste. That’s before accounting for meetings.
Time-based breakdown of a developer’s day, gray is waste
On the SCM side, we still have command line clients. If you’ve got time to burn, switching between the command line or shell extension to work with your SCM system may not pose a problem. If you’re a top-notch developer, you may even have the spare brain cycles available to work effectively in this way. But that doesn’t mean that it makes sense to do so. Many of the early pioneers of Smalltalk showed us the path towards integrated tooling long ago: everything should be explicitly present and directly manageable from within the developer’s workbench. Today, that workbench is the modern IDE, and the benefits of the IDE to the Agile and ALM workflow go far beyond having an embedded rich client. The deeper benefits come from the rich linking and data sharing that’s possible once the developer’s entire toolset is built on the same integration platform. Tasks, contexts, commits, builds and reviews can now all get automatically linked as we work, and all collaboration activity takes place alongside the code, where it belongs.
Similar benefits arise in moving developer-specific workflow from browser-based Agile project tracking tools into the IDE. The web browser has been a great vehicle for helping Agile tools take shape and for introducing them to the masses. The Web 2.0 trend helped issue trackers get more colourful with slick stylesheets and a visual refresh with the large and simple styling popularized by 37signals. However, there is a reason that desktop-based applications still dominate the productivity tools landscape. The modern IDE is capable of putting all but your desktop’s hardware, except the graphics card, to full good use. It is now common to access Twitter, email, and instant messaging have gone back to the future by providing a growing number of native desktop and mobile clients. Given the complexity of the way we collaborate on the application lifecycle front, the benefits of a native client are even more pronounced. . Over the course of the year, as Agile ALM tools continue to mature, IDE-based access will cease to be an afterthought and minor check-box on the ISV’s feature matrix, and high fidelity IDE tools will become the client of choice for developers accessing the Agile ALM stack.
Innovation on the browser-based application front will continue, and in the following predictions I’ll discuss the state of web-based IDEs. For 2011, we can safely consider the desktop-based IDE to be the place where most coding gets done. Web UIs for Agile and ALM will continue to serve an important role, for example, as the primary interface for management-level stakeholders and product owners. What’s exciting is that that we will also see additional convergence between Agile tools and the IDE. Minutes before the daily Scrum the developer will be able to instantly pop up an embedded task board showing all things assigned to them for the current sprint, and with a click activate a user story they were collaborating on with a colleague, automatically share progress and update time remaining, and come out looking like a rock star in the Scrum. Sadly it may take longer before we’re updating task boards with Xbox Kinect based Minority Report type gestures, but this is progress.
Mik Kersten, a good friend of DZone, gave us permission to post this series.