How Architexa Makes Life Easy For Developers

I found out about Architexa last week, a really useful tool for generating UML diagrams from your existing code. I see huge potential in this tool for helping out with code reviews, or for getting into a new code base. I had the chance to speak to Vineet Sinha to find out more about the tool and how it works. 

James: Hi Vineet, could you give us some background into your motivation for creating the tool?

Vineet: I was working 10 years ago at Microsoft on the Office codebase and realized that I was spending a lot of time just understanding the code. It would take me a lot of time to figure out what I needed and then I would typically end up working with a pen and paper to draw a diagram of what was going on. It was just too time consuming to remember how all the 10+ classes interacted with one another - a paper was necessary to just draw it.

I kept wishing for better high level diagrams and even something similar to the MFC hierarchy diagrams would have been helpful. When I could not find any such documentation, I looked into some of the tools that were available. And the reality was, that they all focused on designing and generating code from diagrams - their support for diagrams from code was limited at best.

I ended up building a tool in my spare time. As I did that I hit alot of technical challenges in having something that I as a developer would find useful. So I ended up doing my PhD (at MIT CSAIL) on this problem. I built some prototypes there, and another when doing work for Accenture research labs. By about 2 years ago, I had great results - and I wanted to convert it into something that others could use (adding the undo, redo features). Two years later and after 6 months in beta - we are bringing the tool out slowly.

James: Could you introduce the team behind the tool? 

Vineet: One of the nice things about trying to really improve the lives of developers is that there most developers care about it. We have a really great, passionate team, that is all developers.

Liz joined me when the company was just starting - she was graduating from MIT and had been working with me on my PhD work. Last year we decided to get two more people to help get the product out of the door - Seth and Abhishek joined then. And they have been working on some really cool stuff.

James: What technologies are you using to make the tool?

Vineet: As a developer I am lazy - I want the functionality right in the IDE. Most developers are using Eclipse today, and it being open source allows us to add features deeply integrated into the IDE. So I started building on Eclipse, and Eclipse's GEF for the drawing features.

James: How are the collaboration features written? Are you using ECF?

Vineet: We didn't want to go overboard, but realized that developers often want to share a diagram with others on their team and that shared diagram forms a create documentation of their codebase. So the primary feature that we wanted to support was just a simple central repository. Just supporting your code repository wasn't enough because most developers know their own codebase and therefore don't document it - it is those using it that need to document it before the original developer fixes it. This was the story I kept hearing when talking with companies so we built our own simple but secure diagram repository (using Jetty, Rest/Jersey, and hosted on Google App Engine). Developers can easily use it or even have a version of it running internally in their network.

We are considering a communication framework to send messages to other users - but before we just add features we want to make sure that there is a need for it. When doing that we will likely use ECF to implement it.

James: What was the most challenging part to write?

Vineet: Our focus is in really pushing for 'usability'. This means implementing something, getting feedback from alot of people, and then often reimplementing it from scratch to behave differently - so that we can not only solve other developers needs but also build a tool that they do not need a huge amount of training to use. Interfaces can easily overwhelm users by show too much, but at the same time not showing much results in users not feeling in control of their application - getting the balance right is not easy. The reality is that not many tools have tried to give developers such power, so doing so means we have to figure out what is right ourselves. Making a complex/ugly piece of picture to look simple is not easy.

Technically speaking the main challenge is in (i) building a highly interactive UI, (ii) getting layout to be smart but not do unexpected things - especially with the interactiveness, and (iii) building an index to provide the sophisticated results quickly without taking too much time.

James: How do you find building on top of Eclipse?

Vineet: Building on top of Eclipse is great. There is a large community that we are part of, with everyone trying.

James: What is the most well received feature?

Vineet: It really is the overall usability of it. I keep hearing comments like 'the tool gives me power over my code' and the regarding our suite ''the difference with all these tools is that it is designed to "surf" the source code through UML diagrams, so that one may be watching more or less detail as you need. It is not an all or nothing, which is usually [how you] operate traditional UML tools."

Hopefully we will be able to give a more granular answer as we get more feedback.

James: How do you create the sequence diagrams?

Vineet: I think I put the best answer for it on your post comments:

The system does not depend on runtime information but can take advantage of it when given. This allows us to not have the performance limitations of the runtime tools, but allow users to view any execution possible from the code.
We have added 'scripts' to show take into account stack traces and are adding support for various xml specifications. We can also add support for Spring AOP and/or using runtime information as done by jTracert

The other comments of mine on your post also do a good job (IMO) of explaining my/our philosophy.

James: When will the tool be available, and at what cost?

Vineet: We want to make it available as soon as possible. Our initial plan was within a week - but we are a little overwhelmed by the amount of response that we have received. So we plan on just getting those people to use the software, and providing the level of support that we would like for them, before we allow the whole world in.

We are trying to build a tool that we can get it to every developer, so we want to make the tool very accessible.  We also want to make sure that developers want to use it throughout their development effort (and not just in the beginning). So we will be happy with charging $250/year (per user). We do plan on a launch discount for the first month.

James: What are your plans for the future?

Vineet: In the short term, we want to make those using the tools *really really* happy. So the first few releases will be focused on just that. Instead of rushing to add other languages, we will talk to our users and see if there are certain situations that they need more help in. Are they having problems with understanding how Struts, Spring, Swing, etc work in their project? If so, we will try to add better support for them first.

I believe that the big need out there is in helping developers work with large codebases. So we launched our blog, now this tool, and we will be focusing on just that until we are happy with it.