Jason Ayers

Why is the first design that you choose to implement a user story with the best one? There are always alternatives but all too often we do not investigate them, often leaving significant design decisions made early on in an implementation to stand the test of time and only reworking them when they come under severe pressure, either from further development work or in production. We have been investigating a process that always looks at multiple spikes on any design of a user story. This originally occurred because the agile process used the analogy of how a wolf pack hunts to shape the steps of the process. Wolves try many spikes in trying to find the weakest prey and so we emulated this process. Teams are forced to look at alternatives and evaluate their merits before choosing the best solution and then this process is repeated for every user story. What we are now trying to understand it how this impacts the overall quality of the solutions built in this way. Are the gains in quality from continuously spiking worth the extra effort? We explore the issues and give some of our thoughts based on what we have observed.

Using a few example IDEs we are going to look at what makes an IDE valuable.

Building software is a complex business, software that works and stays in production for years. It is a craft that involves engineering, insight and skill. The tools that we use to build that software are vital enablers to our success. Between 1997-2004 the dominance of Java and the main vendors’ tools strategies led to something of a stagnation for IDEs. But since then with the return to language diversity and the broadening of platforms there has been a real opportunity to experiment with what an IDE is and means and to look at how it could evolve.

We will look at a range of IDEs including WebVelocity, Cloud9 and Codea and contrast them with more traditional IDEs such as VisualWorks, IntelliJ’s IDEA and Eclipse.