Audio Interview: Devver Co-Founder Ben Brinckerhoff
Code metrics help web developers maintain large codes bases, minimize errors, and avoid code duplication. While powerful code metrics tools exist for many programming languages, Ruby and Ruby on Rails developers must work with a hodgepodge of effective but disparate open source tools.
Software start up, Devver, seeks to solve this problem by offering Caliper, an easy to use metrics solution that still relies on a diverse set of underlying open sources tools, but collects them into a single interface, giving developers a one location from which to monitor their code base.
In this audio interview, Ecommerce Developer's Armando Roggio seeks with Devver Co-Founder and Customer Advocate, Ben Brinckerhoff.
Transcription
Armando Roggio: Hello and welcome to another audio interview with Ecommerce Developer. My name is Armando Roggio. I'm the site director for Ecommerce Developer and it's my privilege today to be talking to Ben Brinckerhoff of Devver, pronounced like dev in developer, dev like in Devver. He is a customer advocate at Devver and Ben developed a fashion for software testing and verification while writing automated testing systems for IDEs and compilers at Microsoft. He spends most of his time at Devver talking to customers, providing technical support and whenever possible, writing code and snowboarding I understand. Ben, thank you very much for being with me today.
Ben Brinckerhoff: Thanks a lot for having me.
Armando Roggio: You know, I started off by mentioning how the name of the company is pronounced and I did that because we had a little discussion about it as we were preparing for today's call and I noticed on your website that you have a little discussion about how to pronounce it. Is it mispronounced often?
Ben Brinckerhoff: It is. Often, we not only get pronounced Divver a lot, we also have a lot of people -- we're based in Colorado, and a lot of people assume we're from Denver because it sounds so similar, but we're actually in Boulder, Colorado. So, two pieces of confusion that the name creates.
Armando Roggio: Well, it's always good though to give something to talk about.
Ben Brinckerhoff: Yeah.
Armando Roggio: So, you tell them it's Devver and it gives you something to talk about. I sort of want to start at the beginning. How did Devver get started? Could you tell me a little bit about the company, how you get started, how you ended up with Devver?
Ben Brinckerhoff: Sure. A good friend of mine, Dan Mayer, who's another co-founder, have been talking about starting a business for years and I was in [unintelligible] working on automated test systems and he was actually living in Denver at the time. So, I ended up moving to Denver and we started work on one product, which was more of a consumer-facing product over use and during that time really found that our Ruby on Rails experience was amazing, the tools are amazing, but we felt like the cloud could really offer developers, Ruby on Rails developers in particular, a lot of benefits. So, we ended up shifting and moving towards providing some cloud tools around Ruby programming and that's the way how we got started.
Armando Roggio: And we're talking about providing cloud tools. Caliper is probably the key project for you guys. Is that right?
Ben Brinckerhoff: Right. That's absolutely right. So, right now, we're focused on a tool called Caliper and it provides metrics for Ruby developers, specifically around programming metrics. So, things that programmers from other languages may be familiar with but don't have as advanced a tool set in the Ruby world, so things like cyclomatic complexity, for methods in classes, things to automatically identify potential code smells, or even duplicated code. The idea with Caliper is although those tools exist, in fact we're built on some great open source tools, we can use the cloud to make it very easy to set up, very easy to consume that data in a powerful way, which allows programmers to both reduce risks by identifying some of these metrics and also lower future maintenance cost by making sure their development practices are the best they can be.
Armando Roggio: You know, I often see things like code metrics and you think, "Wow, that's great," but how do code metrics really help me with my projects, really help me to improve what I'm doing?
Ben Brinckerhoff: That's a great question. It depends all on the team. I think that code metrics really depend on the developer and the team and how they want to integrate it because it depends on what your process looks like. So, on some metrics such as code complexity, research has shown that tends to correspond very closely to defect rates. Both complexity and the other one you see is churn, the amount of times that a file or a class or method changes very often. Those are places to create bugs. So, the simple answer is it's a way to help identify areas of code that are likely to have bugs in it and of course identifying early bugs is better than identifying them late when they get to the customer. The second one is I would say a little more controversial and it's around tools that automatically identify best practices and I think you really have to take that, identify the type of code you're writing and how long you expect to live with it. If you're the one who's coming back to it in a month or two months, you're going to really I think benefit from some of these practices that let help you write simpler code, code that's easier to understand, and of course those effects [unintelligible] more if someone else has to maintain your code. So, it keeps those future development costs and maintenance costs down because a lot of any project, even [unintelligible] is going back and reading and modifying the codes as opposed to just writing all new code.
Armando Roggio: Sure. So, I'm putting you on the spot a little bit here, but can you give a specific example or do you know of a specific example where, you know, by identifying some of the best practices a Caliper user has been able to save some time or money?
Ben Brinckerhoff: We don't have a specific example. We're pretty early. A lot of open source projects are primarily using us right now. We're just now rolling out of private beta for private projects to use us, but I can give you an example internally.
Armando Roggio: Sure.
Ben Brinckerhoff: One of the best practices is simply duplication. That's a pretty non-controversial metric. Generally speaking, as you'll agree, just duplicated code is going to cause bugs in the future because you're likely to change one instance of code and forgot to change the other and because of the discrepancy, a bug is caused most likely. We are pretty adamant about that and so we consider our code to be pretty dry. We don't repeat ourselves, but Caliper has helped us find places where even with the pairing that we do and even with our focus on that, we miss places where I'll write some code and perhaps someone else on another piece of the code base is writing a piece of code and we're just not completely aware. It's just too big of a code base to be aware of every single piece at all times and Caliper can help us identify those parts, refactor, simplify our code base, and identify places that would have caused bugs because we had no awareness that we were basically repeating a lot of the same logic into completely different systems, but you can find those commonalities quite quickly.
Armando Roggio: Now, obviously, the goal here is to find those kinds of common codes, best practices, other things, and do it from an interface that's very effective, very easy to use. Now, I have to tell you, I've heard a little bit that Caliper's dashboard is not the most intuitive interface out there. Would you comment on that and could you tell me if and how Devver is addressing it?
Ben Brinckerhoff: You're absolutely right. One thing we pride ourselves in Devver is just our openness and I will say for the record that our interface today is not good. We historically started Caliper from the perspective of there were some open source tools, it provided some information and could we first and foremost bring it on to the web in a way that would make it very easy to configure and set up so people who may not have invested the time to set these tools up on their own machines would be able to experience some of the benefits of metrics [unintelligible] I would say and what got lost in that initial transition from something that you would [unintelligible] yourself to a hosted service was the presentation of data. So, right now, we are working with an outside consulting company and we are working on identifying these user interface issues that are most pressing and one of the first three things that we identified was the dashboard was not helpful enough, that it's not giving enough information about the overall help of the project and of context of what the numbers it is presenting. So, that's one of the first things that we're working on this week and we'd love to get feedback from people who have used the dashboard and what information would be more useful. That's one, the second one we heard just commenting on some of the UI improvements that we've heard and we are working on is that often programmers come to the site and aren't as familiar specifically with the names of the tools. So, they may know that they want to look for duplication, but aren't familiar with flay which is the tool used for that and that's completely valid. So, we're working on identifying tools by function more than necessarily named.
Armando Roggio: So, I don't have to know what metric foo is, for example, to know what [unintelligible].
Ben Brinckerhoff: Exactly. You shouldn't have to know. Now, what we'd like to do is if you know those tools, we like you to be able to find the information based on your knowledge of that name, but not make it a prerequisite and of course we want to be clear that we are using those tools. Those are very, very excellent open source projects and we want to recognize the developers who put their time into that. So, it's not about hiding it or not being clear about where we're getting the data from; just saying that as you come in, you should be able to navigate without needing to know that it's prerequisite. The third thing is that users who come in don't always know that Devver does, or Caliper I should say, have a function to generate graphs based on the history of the project to show your progress over time, but the UI just wasn't clear enough. So, I think one of the number one priorities right now, there are two priorities I should say, is one, working to build Caliper in a way that anyone with a private repository on GitHub can use it and can start using it for their private code, not just open source code. Simultaneously, we're working on dramatically improving the flow of the site as well as presenting that information in a much more easy to use and understandable fashion.
Armando Roggio: Now, those are some big things. How are those coming and when might we see those changes in Caliper?
Ben Brinckerhoff: So, the private beta support is actually -- oh, sorry, the private project support is in beta right now. If you go to the site, you can sign up to get a… If you got getcaliper.com/beta, you can sign up to be on our list as part of beta testers and we expect to roll that up more widely within the end of this month. We'll be inviting more testers and then probably open it up somewhere in February, either early February. As far as the UI changes, you should start seeing those within a week or two. We're not waiting to make everything perfect for release. So, the first batch of changes should go live in probably two weeks and then you'll be continuing to see incremental improvement. I would really encourage anyone to either go to our site and submit feedback on things that they like to see because we're very, very passionate about being able to get user feedback. In fact, our most recent blog post on devver.net/blog is just talking about some of the UI improvements that we're going to be doing and requesting feedback and making sure that we're addressing the top priorities that are users are really caring about.
Armando Roggio: What form do you want that feedback in? If we went to the blog, can we post comments there? Do you want drop it on Twitter?
Ben Brinckerhoff: Yeah, you can comment on the blog. You can always start a discussion at www.supports.getcaliper.com. You can email us and we're on Twitter at devver so if you ever have any quick comments, feel free to just reply to us on Twitter.
Armando Roggio: But you would encourage a lot of folks to, or not a lot of folks, but you encourage folks with something to say or a thought to send those your way.
Ben Brinckerhoff: Absolutely. Any and all feedback is great. We love getting both happy things and things that are not working and we're always quick to get back to you on that.
Armando Roggio: So, those are your top two priorities. Are there some other things, other features that are on the list, but are maybe a little bit further out that you could tell us about?
Ben Brinckerhoff: Sure. So, we have a lot of places we want to go. Obviously, we're focusing on the most painful things that you can fix right away, but moving forward, there are a couple of big buckets of things that we like to do. One is notification and so right now, when you go to Devver, you can get metrics into Devver, but you need to be in Devver. We don't alert you on changes. So, one thing that we're looking at is providing a configurable system to allow people to say at certain thresholds for metrics they want to be emailed or perhaps on every commit I do, I would like to see the results from my commit or other notifications that might help you know about what the status of your metrics are. The other one is we'd really ideally like to move metrics closer to the development process and by that, I mean right now you only get information after you've committed and after you pushed to your public repository. We're thinking about ways that would allow people to get some or all the information right on their command line before they have to commit. So, they can actually see before they push that code to other developers what impact their changes are going to make and to direct any problems that they see right then as opposed to having a more delayed feedback.
Armando Roggio: That's great and how soon might we see something like that?
Ben Brinckerhoff: It will depend. Honestly, we're looking for feedback from users talking to a lot of our releasers now about really what direction they want us to go. If [unintelligible] to get the faster feedback or if they see it more as a post commit tool. It's hard to speculate on features further out I would guess, but then two months or so we'd see one of those and which one really depends on what our users say as far as what their priorities are on how they envision using Caliper as a tool. Do they see it as something that they want to get more passively, maybe check on after a commit or once a week, or do they see something that they would like to use more actively as part of the development process?
Armando Roggio: Sure. Well, when that does come, if it comes, make sure you let us know at Ecommerce Developer. We'd love to talk about that.
Ben Brinckerhoff: Will do.
Armando Roggio: You know, you mentioned a little bit earlier that you're working with outside consultancy. Is that Viget by any chance? Viget Labs?
Ben Brinckerhoff: That is. Yeah, Viget Labs, yeah [unintelligible]. We've worked with them in the past and are continuing to work with them on helping us improve because a lot of our expertise lies around the backend development and they are just really experts about the usability and some of the design issues. So, we're really happy to be working with them.
Armando Roggio: Uh-hmm. Their reputation is very, very solid so I'm sure that that's going to reflect well on Caliper. Do you mind if I switch topics a little bit here and ask you what's happening with Test Accelerator?
Ben Brinckerhoff: Oh, yeah, it's fine. So, I skimmed over there a little bit when I was talking about our history just for the sake of simplicity, but the original product that we came out with at Devver was a product to do Ruby testing in the clouds. The idea was that using many machines at once, we could parallelize tests and run them more quickly and give feedback to users on their tests very quickly. We worked on that for a quite a while and we're really passionate about that project. Unfortunately, after working on it for some time, we had to face some realities around that, simply that what we were doing wasn't working from both the perspective of the technology. There has been a difficulty of running sort of arbitrary Ruby code in the cloud in a way that required very little setup. We found that almost all projects even with the work we did to do automatic detection of things still required a lot of setup and really didn't give any benefit until that setup was complete. So, put yourself in the shoes of the developer and although we were, you know, the changes they got sort of great feedbacks, but in the shoes of a developer, you're working and you're configuring your project perhaps to declare some gems and make sure the versions are right and do some extra stuff for Devver and you don't know how much it's going to speed up your test suite until you've done all that and so we were struggling with getting people to understandably invest time for an unknown benefit on that project. Ultimately, because of that and some other difficulties, we have decided to permanently, or at least for now I should say, shove that project. It's going to be stopping run on the 22nd of this month and we just felt that the market demand did not unfortunately justify additional work in that space. We may eventually bring that back in some form, but one of the reasons we want to work on Caliper was we wanted to give people something that would give them immediate value with very little setup, so in the case of Caliper just putting it and get repository and you'll start getting valuable information about your project is our goal.
Armando Roggio: It makes sense. Is there anything else that you want to tell us about Devver or about Caliper before we end our call?
Ben Brinckerhoff: I would just say that we're very excited to work on it. As I mentioned to you before, we are very passionate about talking to users and so whether you're using it for open source or you're interested in using a private repository support, any of that, we'd love to talk to users about how they are using it, how they would like to use it, scenarios that they like to see supported, etc., and that we have some exciting things coming up as far as future work and we'll continue to work hard on that.
Armando Roggio: You know, Ben, I'm sure you're going to be successful from talking to you.
Ben Brinckerhoff: Thank you very much. We hope so and we owe it very much because of the great review community. It's really supported us so it's a pleasure to be working on it.
Armando Roggio: All right. Well, thank you very much for joining us here at Ecommerce Developer today, Ben. We really appreciate it.
Ben Brinckerhoff: Thank you.
Armando Roggio: Bye.
0 Comments
