Hi, this is Rob Bazinet. I'm here with Matt Todd, at RubyFringe. Matt, can you tell us about yourself?

My name is Matt Todd, I'm from Atlanta, Georgia. I'm a 23 years old developer with HighGroove Studios, which is based partly in Atlanta, partly in San Francisco, in Oklahoma and various places of the United States and also with the university in South Atlanta, called Clayton State University. I do web application development in both.

You were a speaker here - interesting talk. What was the title of your talk and what was it about?

The title of the talk was "Being dumb and using it to your advantage" and essentially I probably could have called it "You should be more like Ezra Zygmuntovic" - I always mess up his name - "or Chris Wansrath or anybody like that. Just be more adventurous with your experimentation and try new things; do anything like that and expect to fail a little bit, but learn from those failures.

You mentioned you had some projects you'd worked on - Halcyon was one of those projects. What's Halcyon?

Halcyon is a web application framework, very similar to Rails or Merb, except for that it has no HTML views, which is very common for those kind of frameworks, so it's very niched. It is actually suitable for building web applications services where your interface is completely Jason-based; some other in fact, too - the Twitter API or something like that. You would just build an application slice and maybe have another framework build the HTML interface on top of it.

Have you used this framework in any of your products, your job you work at HighGroove?

I work at HighGroove part time and I work at Clayton State University, which is in South Atlanta, part time as well. I've been working at the Clayton State University for the past 4 years. I've developed most of Halcyon while I was working there and we use it, in fact, in production to centralize authentication systems for numerous different legacy applications and current applications. We have a mixture of PHP applications, ASP .NET applications, Java applications and Rails applications that all need to authenticate with the same server, so this was just a way to centralize all that and JSON over HTTP was a great choice. In fact, I was inspired by Damian Katz's Couch DB to use that particular blend of technologies - and that, simplified, all of these applications being able to authenticate with the same server, just completely avoiding a lot of the hassle and all that with updating each of these applications if the authentication changes and what not, which it does.

Is this an active open source project? Do you have people contributing?

Yes, several contributors, but not very regular. It's a very small project. I mean, it's a web framework without views; it's very niche. You are not going to get a lot of people really interested in it and that's OK. I did the most contributions to it, I've written it from the ground up several times, actually, and that was one of the things that I talked about in my talk here about messing up and having to rewrite it, but we were able to deploy it in production and get it running really well.

Let's talk a little bit about failure and attempting things. Your talk went into some detail, but what do you recommend? Looking back at projects you've done, can you give us some examples of both sides - failures and not, the successes you had?

One of the interesting ways to approach anything that you do is to do it very ballsy, but also if you do mess up, don't take it as a failure. I mean, it technically is a failure, but it's really a success because you are able to learn from your mistakes, you are able to build on those experiences and just prepare yourself for the future. You are building a lot of experience with how to solve these problems, how to make sure that what you are doing is going to succeed next time and it's just a great overall experience.

You do this with your personal projects; do you do the same thing with what you do for your job?

It bleeds over. I'm much more experimental and I definitely try a lot more ambitious projects - personally - and those experiences come in to my professional work. Sometimes I'm able to actually try those more experimental things in the production work, like Halcyon. That was completely experimental and I didn't even know it would work. I didn't know I could finish working on the framework, but I tried and I was able to succeed and it worked really well for what we were doing. I counted it as a complete success, even though it is very niched, not a lot of contributions to it, just yet.

Do you have examples of projects that you started out with and they were just total failures and you learned a tone from?

I'm going to start Halcyon again - I failed twice before the third time I got to do it right. Halcyon originally started off as just this authentication server, but also it was basically the server, the Framework and the application - all combined into one. That was a really big failure because it was just kind of unwieldy. The first time I rewrote it, I decided to split the framework, which became Halcyon and then the application, which was Aurora. That ultimately failed because I tried to do way to much server work with Halcyon. We kind of missed the point of using Rack, which is a really great framework for separating the frameworks from the servers. I tried to do too much server functionality, which I should have left to Rack and to whatever server it was running - Thin usually or Mongrel or such one. So, I rewrote it again and I had in my mind "I know what I'm doing now. I haven't been designing this as an application, the domain I had completely wrong." I had to rewrite it as an application framework and not a server framework or a complete bundle.

The failures that you've seen - you had such issues with Rack in your Halcyon project. How would that not have been so much of a failure if you had known everything about Rack?

It was a more failure of my understanding of the domain really - I'm young, I'm 23 years old, I've only been developing professionally in this kind of context for just a number of years, maybe 4-5. I came from PHP, so not exactly a lot of strong educational experiences in PHP. Ruby has stepped that up, allowed me to experience and learn a lot more about being a really professional developer - just increasing my knowledge substantially, just from the projects that I've come in contact with and I've experienced.

Like I said, it was a problem with my understanding of the domain: I didn't really have a grasp of the concept of what Aurora or Halcyon should be - Halcyon specifically. I saw a framework in my mind, I did not know how to do it exactly and so I went with it and I played with it and I got it working. That was my goal: to get it working, and I was able to do that, but in the long run I realized it wasn't working like it should, so I rewrote it. It wasn't that it wasn't working, it was just that it lacked a great architecture and a great design and everything. As I realized that from developing with it and using it and figuring out what was wrong with it, I've realized I need to rewrite this, it's not working right.

How would you tell somebody that is just getting started in development, how would you guide them to minimize their failures? What are your recommendations to them?

I would actually recommend to fail more. Just try more projects that you are unfamiliar with and get into that failure-rebound, failure-rebound until you start nailing it. One of the things that you get when you start developing projects, just experimentally, or you just have an idea for something, even if it does exist, just try writing it without even sourcing that code, is that you learn how to rebound from those failures.

You learn how to figure out all these things that you've never seen before, or this syntax that you are totally unfamiliar with and you found by reading some source code that you had to use to do what you are trying to do. That's really the beneficial thing - that's what helped me. I'm very tactile, so I need to do these things, like I can't read a book and just get it, I can't hear it or see it or anything, I have to be doing it. That's how I learn and that's how I recommend. I know not everybody is tactile learner, but it's a great way to experiment, figure out what's going on and do it.

Is there an approach - let's say - to learning to take on these projects to minimize failure? We don't want to fail - failing is OK, but we don't want to fail in a spectacular way, maybe.

I think a really interesting point is that we don't want to fail on a very spectacular way, so if our failures are small, then we can rebound much better, much easier and they end up just being able to recover and keep on going a lot faster. The way that you do that is you actually don't take things in such a big chunk. You don't try just to build this monolithic system all at one time even, you just build small parts at a time, just approach very small points at a time and you are able to learn as you go - one little bit at a time - that's the way to do it, that's how you do it.

You can learn from your own failures, we can all do that. How do you recommend from other people's failures?

Ask them about it, ask them what happened, why it happened, the details, like how they got to that point, or they planned to do there, to begin the discussion. We've learned a lot from other people just from discussions and figuring out exactly how they feel about it and how it got there. Learning from others is partly in discussion. You can also read through the code, if it's publically available and make critiques on it, see if you can figure out what might be lacking. Like with Halcyon - the architecture being incorrect - having to rewrite it 2 times, taught me that you won't always see what's wrong with the code, because the code can work. It's just probably it might not always be the right domain, or the right architecture, or structure, etc. You got to look big picture and small picture sometimes, too.

Do you document your failures, both for yourself and for others to look at? Do you do that?

I don't think so. I have taken this opportunity to expose a little bit of my failure with Halcyon and just like my professional career, as an open source developer, here at this conference, being able to talk about it and share my experiences with it, but I don't think I've ever written much about it personally. I would certainly not recommend against it. It's something that would be very beneficial, just to take a look at the kind of mistakes that you've made and write down what you think because that can be very beneficial for later, too, when you come back to it and see "How was I messing up? Am I repeating myself?" What you do want to do is to keep on developing and improving yourself, make new failures.

New failures are fine. I was just thinking to blogs or whatever means people can write articles and books and things on their past.

Being an open source developer, all of my code is pretty much exposed and with Halcyon I always add tickets, even if it's mainly just me working on it, I always add a ticket if I'm adding a feature or redoing something. I usually indicate "I really messed up here and it needs to be completely rewritten". I did that for both rewrites of Halcyon.

You've had a chance here to attend some other speakers' talks. What did you learn from them? Did you learn anything that you'd like to share? Some new things you didn't know, some new approaches to failure?

This whole conference has been awesome - it's been the best conference I've ever been to. Every single talk was really not anything like you would have expected from a developers' conference or that you would have expected from those people. It made me a little bit more aware that the theme of this of this conference is failure, in the best way possible. It's like people are just being open and sharing that "This is where we fail" or "This is where we have failed" or "This is where we will fail", "This is how we recover from that or just learn from that" and it's just been a great experience. Specific talks, I haven't got any particular ones out of my favorites, but they were all wonderful. What I've learned was you get up there, you have the guts to do it, you just go for it, because a lot of these talks were experimental. They were totally on the fringe - that's what we were aiming for - and they nailed it. You got to get up there and try it. You won't ever succeed if you don't try it.

Did you have the opportunity to catch Dan Grigsby's talk? He talked a lot about failure from a business standpoint - going out on a limb, from a business standpoint and you were talking from antithetical standpoint. Did you have the opportunity to think about how to parallel, how that goes together?

Sure. If you first did startup fails you just can't stop. You just got to keep on going, maybe recover a little bit. It may take a little bit more time to recover monetarily or emotionally, but definitely get back in there and do it! If that's what you really love to do, that's what you are really good at and you generally love to do what you are really good at, just go back there and do it. Keep on doing it until you succeed!

Going forward, we are going to meet you again. Are we going to see you in the Ruby Conference?

I'm definitely going to be continuing to contribute to projects the best as I can. I'm really looking forward to contribute a lot more to Merb. That's an interesting project and I'm glad that they went out on a limb there to both write it in originally to pump it up and get a lot more activity and then rewrite it when they thought "We are doing something wrong here. Let's try something new", and they succeeded. I'm glad that they did. I don't know if I am going to be speaking at another conference any time soon, it's not really something that I do very often or get a lot of kick out of, but I certainly needed to do this one. I will also be part of a lot of communities, too.

Are there any last words you want to go out with for the developers out there in the world?

Enjoy what you do! Take every moment that you get to experiment and do it. Take your personal time developing and play with new code that you've never seen before or an idea that you have seen before a dozen times, but you think you can do better.