3. Tell us a little bit about that, what is CollabNet all about?
So we started actually doing open source for the most part, we are actually the stewards of the Subversion project in the early days and over the course of the last ten years we’ve been actually working on an Application Life Cycle Management Platform, which basically takes the best practices of open source and allows enterprises to benefit from those practices and the delivering of enterprise software.
It’s a good question, so you know the way I think of it, it’s kind of three phases. So when I started in the business, I’ve been doing it about 15 years, ALM was really characterized by monolithic platforms, you would talk to big three letter firms about giving you an end-to-end platform that did everything that you could possibly think of, I call it the ALM monolith. And then what happened is in 2000, actually or so, we were a part of this with the Subversion project, what happened is is that the developers began to rebel against this idea that they were going to strapped and harnessed under this monolithic platform and so what they did is, I call it the point tool rebellion, is they started going after a sort of point tools that were going to solve their problems “du jour” if you like and what happened was that the management lost control, so whereas the monoliths were about management control, the point tool rebellion was about developer control and I think actually the answer is is that neither one is really the answer.
What you really need is you need to be able to compromise, you need to be able to give the developer team the ability to run and do what they need to do in all the best kind of Agile ways and you need to basically provide a heart beat to the management teams so that they actually can get enough of what they need to provide that freedom to the developers in the first place and so where we are today is I think it’s not about monolithic platforms, it’s not about “soup to nuts” from one vendor, it’s really about a framework or a series of tools that are coming together for a context with just enough metrics in a heart beat that the managers can actually get on with what’s actually happening. So it’s actually exciting for us, it’s exciting to be a part of an open source, in a sort of driven company, it’s exciting to be partnering with the open source guys which are a big part of this freedom, so we’re well poised basically to be in a position to provide this compromise that’s basically going to be good for both parties.
Absolutely, the idea that we have is that, there is a certain sort of type of an event, a transaction if you like, that occurs between tools and those events are more classed by the type of tools, so if I’m using Jenkins or if I’m using Hudson or if I’m using Team City it shouldn’t really matter, they’re a kind of, if you like, Continuous Integration event. If I’m using Subversion or if I’m using Git, that shouldn’t matter either, so the tools that are coming and going within classes, if you have a level of metadata, if you like, and if you can capture the transactions around it you can actually build a really great sort of data store business intelligence layer on this thing, that gives the guys freedom to choose whatever they want and actually we know very well at our company that having been behind Subversion that now we are in the era of Git and tha’'s ok, that’s just fine, in fact we encourage people to actually change their tools, but the trick is is figuring out what that commonality, if you like, is between the various things.
And by the way this is being driven by a lot of different things, you see people, it’s not just freedom for the developers sake, but it’s because the business is changing or the context is changing. I might have to develop an iPhone app one day and an Android app another day and a web app another day, and the tools that you are actually employing for those purposes are different. So if there is one constant now in ALM it’s change, a little clichéd but it really is and so I think the vendors that will emerge successful and, actually forget about vendors, just the projects that will be successful are the ones that can figure out how to sort of roll with the tools as they come and go.
Craig: You mentioned Subversion there, what is the future of Subversion, what is the usage of Subversion, I mean I think a lot of people, like a lot of tools, think that it’s something that it’s been in the past but I suspect there are still a lot of big enterprises still have a lot of heavy lifting based on it.
Might I remind you that CVS, which Subversion replaced, is actually still shockingly in the market. So here is the thing: so they employ different models, the advantage of Subversion is is that, and it’s a little bit of a manager advantage now, is that you centralize everything around a trunk-based development philosophy which means that everything is visible, there is no, if you like, you know how mushrooms when they are growing in a forest and you see just the mushrooms there is really all this other stuff going on under the ground, in fact most of the organisms are actually under the ground. That is really what Git is, so basically Subversion I believe will stay, it’s here to stay, like many things in life, what happens is that people swing a pendulum all the way over to the other side and then the actual answer lies somewhere in the middle, and so I firmly believe, and by the way frankly it could go either way and we would be just as happy because we are an open framework, but I firmly believe that what will happen is that there will be classes of developers that go after Git and they’ll love Git for what it allows them to do which is to stay off the radar until their tiered promotion gets it ultimately to visibility, but there will be other shops that want to have that visibility the entire time and their compliance or governance or whatever the management driven stuff that is required will keep it around. So what I actually kind of like is I like hybrid situations, like situations where you have some parts that are Subversion based and some parts that are Git based and actually that is a pattern that we see too, we see people using Git for a lot of the day to day but then ultimately it’s ending up in Subversion as sort of the canonical location for the stuff, for the IP.
That is a good question. My feeling is that there is metrics at different levels, so let me start with the metric that I think matters the most and I think is actually, if anything, it’s what Agile needs to be and that is the metric about customer satisfaction. Is, as a unit, not just the development team, the organization that has the Agile development team but inclusive of the management, the executives, the business guys, is that entire organism if you like successful and the only way I know how to measure that is by actually accessing the success of the customer. Is the customer enjoying the fact that they are getting shortened cycle times and have the opportunity to provide feedback and that feedback is coming back, is the customer to a point where they can allow you to misstep occasionally, fail fast if you like, knowing having confidence that you are going to turn around and deploy something tomorrow that is basically going to fix that. So it all for me starts there and as you actually start to decompose from there, you start to get into things which a lot of people talk about, like cycle times, as if that alone was a metric that actually was somehow good.
It’s not necessarily good that I can release faster, it’s good that I can release faster with the feedback that is coming from my customers, so when anybody asks me about metrics it’s always about that. The other thing I want to say about metrics is that there has been, and I’m not going to call it a debate, but I have heard different perspectives at the show this year about whether Agile has really come into its own. There are some who believe: “Hey maybe we shouldn’t even call it Agile 2013 anymore, let’s call it Software 2013 because isn’t Agile here and doesn’t everybody know what it is” and then there is a certain faction that I think believes that, that they think that the executives at most companies perhaps have actually drunk the kool-aid and it’s not just about developers anymore. But my feeling is is that we’re not quite there, it’s not good enough to have a tool in place, it’s not good enough to have your Scrum Master’s trained, in other words let’s not rest on our laurels, let’s actually continue to push out and get to that customer satisfaction metric that I’m talking about.
One thing I think as well because I still see a lot of consternation and challenge I think in getting executives to buy into the whole Agile thing, is that I think developers who know that Agile is the right way to go should be more forthright approaching the business guys and saying: “Look, we are not just saying this because we want to be seat of the pants” and people who know that Agile, really know Agile know it’s not seat of the pants in fact it is quite the opposite, “but here are the metrics that I think you should measure us on”, in other words put your money where your mouth is and say: “Look, if I’m not successful in this, then fine, we will go back to your labyrinthine 8 month release cycles if that is what you want” but let me show you bean counter how we’re actually being successful, and by combining both those internal metrics like cycle time but also making sure never to forget that customer satisfaction metric and everything that it means.
Absolutely, one of the analogies that I have always used for Agile is that it’s a tornado, it started out very much as a developer centric thing and what happened was, like it or not, the people outside of developers had to deal with the fact that it’s coming at them faster. And it started with testers, in fact we had many a therapy session with the testers trying to figure out how to deal with Agile because it was not over the wall with them anymore, they actually had to jump in and join the Scrum and be a part of it and what was interesting was was there was a little bit of a attrition kind of thing that happened, some people could do it and some people just couldn’t and so it changed things and so what’s interesting to me is this tornado has gotten bigger and bigger and bigger, I know tornadoes is not probably a great thing to talk about this year, but the point is is that it got to the business analysts who had to figure out whether they could be Product Owners or not, could they jump into the fray, could they actually get the level of detail orientation on more than just the requirements but actually living and breathing the requirements on a scrumly basis or a sprintly basis.
And so the next sort of concentric ring for the tornado for me is operations, sort of a softball DevOps answer to this, but now we’ve gotten to the point where the operations guys are getting sucked into the tornado and they’d better deal with it too. And so I don’t know where this thing ends actually, I don’t know if it becomes, what do you call it an F5 or at F4 where we are right now, but it’s clear that is changing everything, ultimately I think the F5 means that it’s got the entire organization from the CEO to the CFO to the business guys, you know all sort of turning on tighter and tighter loops and so it’s been pretty interesting. There is a lot of people who, as I say, it’s been a little Darwinian almost, there’s been aattrition based on it that frankly a lot of people haven’t survived it, they have to learn how to be more tribal, they have to learn about how: “look you are going to be interrupted, you are not going to get to chew on this for three months and then come up with this perfection anymore”. So it’s been very interesting and again Collabnet, our tooling is actually we’ve been advancing our tooling to actually support that widening concentric set of rings. As an example, you know here at this show we are actually announcing a collaboration with Opscode around Chef, we have another collaboration with a company called Automic, so it’s an example of where we are integrating increasingly wide from development types of tools into the supporting of this widening tornado as it gets bigger and bigger.
Craig: So interesting you mention the Opscode, so I’m assuming that in your environment DevOps has made a change that there is more demand now for the widening of tools to the operations people.
Absolutely, I mean what is ultimately happening is what I was alluding to earlier, they have to because the software is coming their way faster and faster and faster, so they have to change something, and so my feeling is that DevOps falls in two camps. I’m a little bit worried that people are thinking that it’s more about tools than it should be, because to me it’s starts with the culture, it’s starts with collaboration, and so you know we are finding, again I was talking about attrition, some of the Ops guys were jumping in and they are actually becoming a part of that Scrum team, they are actually coming in and they are actually making certainly configuration as code but also as far as I’m concerned, the scripts that we write, the workflow, the actual recipes if you like of pushing code somewhere should frankly be a collaboration between developers and operation guys, there should be no wall there as far as I’m concerned. I don’t know if I quite buy the DevOps thing, I think there is probably a, NoOps I should say, the NoOps idea that some day there won’t be operations anymore than I think that there will be no QA because I think both have stakes to play in the various teams, but I think the circles that they run in, if you like, are going to merge and so they become specialists on a wider team that is working much more collaboratively together.
It’s a good question, so going back to the phases I talked about so I think the monolith is dead and I’m happy to see it. This idea that I would pick a tool just because it was the particular tool that my monolith provided as opposed to a best of breed tool, so we talked about that. The point tool rebellion is great, the developers have been happier than ever probably in the last few years, but I think really the future has to do again with threading that needle, the needs of the manager are not going to go away, the financial industry today is fraught with audits that are going on, there is a lot going on right now that is leading not necessarily to more freedom but less freedom when it comes to regulatory and all that kind of stuff, and so we’ve got to find a way to thread that needle, we’ve got to find a way to give the Agile Team their head, we’ve got to find a way to give them the freedom to move between tools but again we have to be able to marry that with just enough sort of strapping on of instrumentation if you like, so they basically can get the freedom. So I have an analogy here, it’s like a runner, if I can get my little white tabs on his chest and I can find a long enough tether if you like and it should be as long as you can possibly make it, you can let that guy run as fast as he wants but you know when its heart beat goes out of tolerance and he is going to be unhealthy and keel over dead, if you know what I mean, so that is what I think the answer is, the answer is in federating tools providing a level of tool freedom and finding sort of a common dial tone if you like among those tools so that the runners can run and the managers can stay out of the way and frankly the organization can flatten and everything can be better.
Well, the first thing is that we are not a monolith, our open source roots, our experience with bringing open source tools to the enterprise which frankly had been developer driven, not management driven, our integration chassis, the way we approach integration, the enlightning way that we scrape transactional metadata and give it up in activity streams, the Big Data Splunk for ALM that we are creating so that managers can increasingly create sophisticated metrics and reports on this widening well of data. I mean we get it, we’ve worked with from very small open source groups to the largest enterprise teams on the planet and all points in between and we understand those compromises, we understand that that is what it takes to be successful, you know both as a vendor and on behalf of our customers, for them to be successful in this crazy chaotic world.
Craig: So if people want to find out more about Collabnet, what is the best place for them to go? 16.58
www.collab.net.
Craig: Excellent, thanks for very much for your time Chris!
Thanks Craig, appreciate it!