1. So, first can you just introduce yourself to the InfoQ audience?
Yes, I am one of the creators and continuity lead of the Eclipse Mylyn project, I am close involved, on the community side as a member of the Eclipse board of directors and I am also the CEO of Tasktop Technologies, driving the innovation on Mylyn and the products and ecosystem, the commercial ecosystem around the open source project.
2. So you did your work on Mylyn as a PhD candidate, right?
That’s right. I’ve been always working, much like yourself, on development tools, so better languages, better abstractions, just better ways to scale our software delivery, with languages and frameworks that do that. We still see a lot of that happening, but after working on the AspectJ team at Xerox PARC with annotation software, with Charles Simonyi, I was just getting the feeling that the steps that we were taking, things were getting very incremental. There is not going to be an object, within aspects, they added 10% benefits over objects. Objects were transformation. We realized that there is a bit of that diminishing returns, all that innovation has to continue, the things that happen in C# is really cool stuff, like getting more direct access to data models.
All of this stuff happens with Big Data, things like Neo4J, on the Java side those are very valuable, but I actually did a study when I stepped out of the industry and started doing research, of where developers were wasting their time. And I noticed that most of the time was being wasted on this disconnect that had to do more with the conversation around software, the way that projects were managed, the way that defects were managed, the way that we manage tasks as developers and not so much on how we struggle to make a better abstraction. So in that PhD I noticed that if we just took out that friction of the disconnect between these huge systems that we work on and the fact that, for any change that we make we only care about this tiny subset of the system related to that bug, we can easily double developer productivity. And that was the whole root of the research; Mylyn was the validation for that research.
3. How did that affect your work on other development tools?
I just noticed that, you know, our whole sort of legacy on tooling was based on files, right? Files are just this really useful unit of abstraction, we stick our source code in them, we stick documentation in them and the compiler stocks them. Every time we try to rip them out, like the OTI people did with the Envy tools, the Smalltalk environment, Smalltalk itself, you’ve got some familiarity with it. It did not have files, there was just these images. If you were a tool builder, you actually filed an implementation detail and you’ve got this database of objects that you care about, and the cool thing with Smalltalk, that was the editing and running that was all very nicely integrated.
But files turned out to be these very useful units of abstraction for packaging our software, for shipping it, for collaborating on it, for checking it into a system. What I learned through all that research is that tasks actually define what we work on and all the tooling and all the IDEs was all based on these files, showing the structure of the file, helping navigate files. Whereas as a developer, in a large system in my work space, there’s seven million lines of code across hundreds of thousands of those files. At this stage, even though the new laptops have no trouble navigating and indexing all of that, there is no way I will fit that into the screen or into my brain at any time. I can only fit the stuff that’s read into a task. A task may be adding a cool new widget to my web UI or fixing some defect. So the big lesson was to reorient the whole development experience and now what we are doing more of the actual entire lifecycle around this notion of what the task is, that task being defect or requirement, a user story or those sorts of things.
And Mylyn was this experiment that took off faster than I expected and proving that out in in this very extensible Eclipse IDE. And now we’ve actually seen that experiment stick, the version of Visual Studio that ships I think in September 2012 that we see on the floor here, it’s actually got that Mylyn on task and context management like a subset of the Mylyn feature set in it. It’s happening with NetBeans as well. So that shift has been, just the original Juno, it’s got this notion of task but you have a per task branch which is why Mylyn and Git work so nicely together, why we’re contributing to the Eclipse- the EGit project because the tasks have kind of taken over to help us just manage complexity.
I don’t know, sometimes I think when you go to talks there is not at all in the lifecycle, there is a lot of project management and stuff going on, which is important, with my roots I think developers have a core role in the application lifecycle and what is happening, what we are seeing with the popularity, the way the ALM landscape is shifting is validating just how primary developers are and how the rest of the lifecycle has to be integrated with that. We’ve gone away from this world where you could top down implement a lifecycle and iterative development would drop and everyone would use ClearQuest and the Rational Unified Process because all developers hated that, that is done, it’s just completely done. These two pieces of rebellion happened and two segments of rebellion at the project manager side, the people who would do these projects, the consultants, they came up with Agile. They realized they were not delivering value, there had to be a better way, we have to make it more iterative, more Lean.
At the same time though, everything was happening with open source, Bugzilla taking over and that the very developer centric feature set that, open source version control tools and that later spun into the continuous integration tools; that’s an even more fundamental shift. All these organizations that think they are standardized on these enterprise-scale ALM tools, they have JIRA in-house, whether they let it in or not, that workflow that open source and Bugzilla created, that JIRA productized nicely, that’s what has transformed things, same with this version control, all that stuff is taking over. We’ve now got into this place where we have to marry those two worlds; the fact that a tool that’s good at being a project manager’s view on software delivery is not the same tool that’s good at making developers productive. Developers are very productive with these very lightweight, very cloudy, very social tools. Project managers like to see hierarchies and all these people look at tasks instead of statuses and it’s those two worlds that we now have to marry. They are part of the same reaction against this top down command and control style of development. And I don’t think we hear enough about that in this conference. And the fact that it’s those developer tools that are really transforming the way that software is built; just the same way as Agile is transforming the way that software delivery is managed.
I look at it as you’ve got, the biggest and key part of it, developers and then attached to developers you’ve got to have some way of managing delivery and there’s Agile that layers on top of it. We’re just talking about that, there’s been a ton of change in that. But the other parts of the organization, this is where you really get out of Agile and dev tools into the bigger application lifecycle; they’re cadences are slower. They don’t want to move into express, you’ve got business analysts and in the end that’s what’s funding these projects, they’re signing on the requirements, they’re going to transform your company strategy, let’s say. That relates to the whole strategy of software delivery, which is really important and that’s part of the lifecycle, you’ve got the testers, so in small organizations, yes, you embed your testing into your teams, we do that on all our open source projects, for some kinds of software you will have separate testing division and all organizations with thousands of developers have that. That’s a separate function, that’s part of the lifecycle.
The ops people and the helpdesk, that’s part of the lifecycle, so really we have Agile just happening on development, the application lifecycle management tools, the same Lean principles have to apply. The people are working on that same task, same requirement that comes from the business analyst, the developers should not have to log in to one of those requirements management tools, they never want to see that, they just need to see that in JIRA or open source issue tracker or whatever they are working. But that task has to flow across the lifecycle, so I think we just need to shift from thinking only as Agile and development into thinking “how do we integrate the same principles into the parts of the application lifecycle and the people who just don’t care to have everything churn so fast”, like the DevOps people, they are kind of counter incented to have big consuming releases every two weeks. But we need that continuous delivery cycle, we know how well it works, we see that from the large ISVs, Google, Facebook, it all came from Flickr. The application lifecycle is those other stake holders that need to collaborate with the developers. We can’t be throwing stuff over the fence, if we’re getting an excel spreadsheet of the defects from production that we got from testing every two weeks or every four weeks, half of them will be irrelevant, that information needs to flow. And that’s why I think we need to move from thinking just Agile development into Lean ALM.
6. And where does DevOps kind of fit into that?
It’s one of those end points. With the DevOps people who are standing up the application and managing it, they are using systems, at large scales they’re using tools, like the helpdesk tools, tools like BMC Remedy, those tools need to be connected, or the lightweight SaaS now, those tools need to be connected into the lifecycle, as soon as an instance gets raised, an incidence should be propagated to development, it should be created in your issue tracker so you can schedule it on your backlog. It might be more important than the new feature you are adding right now, that fact that half your application just fell down. With our role, both with what Mylyn does, what we’re doing in the commercial ecosystem I think the interesting parts are the boundaries, it’s between the developer systems and process model that they use and then the Ops.
And all those cultural changes that need to happen with people understanding each other and so on, that’s got to happen. What I really care is that they can collaborate on a system so they are not emailing each other. If they are emailing spreadsheets or lists everything is falling down, it’s not automated, your application lifecycle is only going to be as good as its weakest link, if your link between dev and production is that weak and there is that much friction, communicating what’s working what’s not, getting contacts back to developers on what failed and so on, then you’re not getting those benefits from Agile, you’re churning very fast on the Agile side and you’ve got that bottleneck on the DevOps side, on the production side.
7. Are you doing hands on development these days or what are you up to these days?
I was not for a long time, I miss it like crazy doing it day to day but I am very much focused on product management division aspects of what we do. But, like Atlassian, they have this thing called FedEx Days, we’ve put those in place at Tasktop so I now have a time that I can write code and not feel bad about it. We have these FedEx days where product management steps aside and we’ve got all the developers implement all the features that they think need, they’ve got 24 hours to do it and I get to do it. I got to implement some cool Mylyn stuff last FedEx day we did, it was fun.
Yes, it’s been interesting because we’ve been trying to connect different stakeholders and software delivery and requirements, even though they are not that cool to talk about, with developers usually, they have this really interesting role, because just like defects, an executive knows what a defect is, someone who cares about an application knows what a requirement is, we can express them as user stories or issues or whatever we call them on the development end, but there are these things that span the whole lifecycle, so they span from the idea of “Let’s release a phone with capacitive touch” or whatever to that thing that’s running and deployed and in the market and “is this thing taking off” and so on. That requirement can be used to trace from end to end. And even if you are just working on an open source project you’re actually thinking this way already. The interesting issues that get raised by your community, those become your requirements.
We’re not calling them as much, we don’t call them that anymore, but in large scale software delivery that’s what they are called. They come from another stakeholder there, it’s basically the business analyst, and they have just the same way in the open source Mylyn project where there’re just Bugzilla bugs with the word plan on them, just this one key word plan, tracing them through the lifecycle and making sure that the different people who touch them are connected, is a really important thing, it does happen in open source, it does not happen enough in large scale software delivery, the commercial software delivery. So, the way we do it on Mylyn is as soon as there is 30 votes for “I want this feature”, chances are the plan key word will be added and gets scheduled into our next milestone basically our sprint and get into the next Eclipse coordinated release.
And it’s that kind of dynamic that we need to have for large scale software as well, where there’s been all this interest in this feature, because it’s relevant, it’s going to make a product way better, developers need to understand that, they need to have that context it came just like we get it from our community, developers need to have the context of the requirement where they break it down into user stories. Not have this again, stuff queued up by the business analyst and then dumped to them and then the business analyst not even having visibility to what’s happening. Lean is a bug having small batch sizes, if you batch up all these requirements, dump them into development and then forget about it, you might not realize that some of those requirements will have impossible scale performance profiles. Developers realize that, the ops people realize that sometimes, that has to be a collaboration loop, if the requirement was that you use SOAP for your API, the business analyst may think that’s fine, because whatever, they use SOAP for something else, developers will know that’s a completely dumb idea, you should be using REST, but we need to get that loop and I think of these things as conversation pieces, requirements are a good place for that conversation.
Michael : Great, well Mik, thank you for coming by today, we appreciate you taking your time.
My pleasure, Michael, thank you.