Developer Tools

  • Diagramming Tools – A (Biased) Survey

    Diagramming tools can help you to quickly understand a new project, debug code, visualize and enforce usage patterns, and quickly generate high quality documentation.  All good.  However, not all tools are created equal and there are lots of legacy tools (UML has been around for a while).  I wanted to take a look at what is out there to get a sense for how these tools are evolving.

    Below is a slice if you will through what are some next generation offerings in software development, tools that are trying to do something different, and some well established old-guard tools that everyone has heard of and compares all comers too.

    Code Canvas Example

    Debugger Canvas  Debugger Canvas by Microsoft (see video) is based on Code Canvas which was developed at Microsoft Research in  collaboration with the Code Bubbles folks from Brown.  Debugger Canvas is available to premium Microsoft Visual Studio license holders.  I love how you can view a GUI widget, its documentation, and implementation side by side in one clean view.  The development metaphor is very different from a traditional IDE.


  • I’ve Just Inherited an Application – Now What?

    Lucene Overview Diagram

    What if I had a diagram like this?

    I have previously written about how lack of decent software documentation can cause problems in doing what we developers love to do, deliver functioning software. Documentation, code comments and good variable naming are all key to understanding code.  This applies to both code that we write and applications that we use through their API’s.  We could just as easily be looking at C/C++/C#, Python, PHP or any language but for now let’s stay with Java (read more about advantages of Java over other languages at .

    I want to illustrate how useful diagrams are in understanding an existing complex Java code base. Understanding code quickly is particularly important when inheriting a new project or trying to figure out how to use a third party package or open source project. As we all know we are typically faced with tight deadlines, limited resources, and herculean objectives. Sound familiar?

  • Docs- Who needs them?

    Software documentation is one of those things that is sorely missed when it isn’t there.  Why is it the last thing that any of us developers wants to do?  It seems that it is easy for us to ignore documenting in the heat of the situation, but we always get burned in one of many ways.

    Literate Programming Style Code View

  • Code Visibility: one factor of code quality that you shouldn’t forget

    Every developer cares about code quality. But how do you maintain code quality throughout the software development cycle? Readability, modularity, and efficiency all are important factors of writing good code but there isn’t much agreement on the best way to maintain a high level of code quality.

    One factor which is often missed in discussions is code visibility, or making sure your code has a clear structure so that others can easily understand it. (Take a look at the diagram above for some of the difficulties encountered when there is a lack of code visibility).

  • Uh oh, not another Large Code Base!

    I came across two blog posts which agree that large code bases are a hassle to programmers. The first post, “Code’s worst enemy” written by Steve Yegge, basically loathes large code bases and Jeff Atwok shares the same opinion in “Size is the enemy” . The problem with large code bases is that their physical size is indication for the large amount of effort, cost and time to be invested for that project, as stated in Steve McConnell books.
  • Understanding What Others Are Upto!

    One of the challenges when working in teams is in keeping up with your fellow developers. Spending a lot of time reading others' code not only means less time getting your own work done but also the gradual deterioration of the code architecture. This is a problem that we have heard over and over again from developers and managers alike. We have just released additional code and architectural review tools that will help developers easily understand new features that are being built. We are pleased to announce that we will be demoing this functionality at EclipseCon 2011 as part of the Hot New Products Showcase. With this release we not only have a full fledged code review client and server, but also are making it really easy for developers to document the main parts of what is being worked on. Our new features will help developers create and maintain more comprehensive architectural documentation, solving a number of common development issues. It's important to make sure the quality of your project's code and documentation don't degrade over time. Reviewing the architecture as well as the code itself will ensure a better documented codebase, resulting in easier to understand code and decreased development overhead. On the other hand, we all know that poorly documented code can increase overhead. Developers are often biased to think that their own code is well documented. Another set of eyes checking the documentation as well as the code can make sure confusing code is documented before it is committed. Code duplication is one of the main sources of bugs and headaches for developers. Code review can help minimize duplication in new code but finding redundancies in legacy code may be difficult without quality architectural documentation. Projects with limited or outdated architectural documentation are more susceptible to code erosion since developers may not be clear on what boundaries they are constrained by. Easy access to viewing and creating documentation helps developers be more aware of the effects their code has on other components.
  • From Java to Spring and Beyond – Making Diagrams (and UML) work for developers

    One of the strengths of working with Java is the large number of frameworks that are available. These frameworks are great for taking care of the basic tasks involved in building Java based apps. But they often bring about challenges in understanding - whether it is xml files or annotation based configurations, developers needing to work with these frameworks have to see how different parts of the code are connected. With this in mind we have extended Architexa to not just show code relationships but have also built special support for popular frameworks like Spring and Struts. We are happy to announce that we will be demoing this functionality at EclipseCon 2011 as part of the Hot New Products Showcase. We are pushing the edge here - so we are making this capability available as an 'early access' version. You can find it by default in all versions of the Architexa Suite. We would really like to hear what you think about it, and invite you to extend your trial of the product as we refine the implementation based on your feedback In this release we are including early access to a number of frameworks. With Spring we have added support for Dependency Injection and Web Flow. We have also added support for Struts (1 and 2) and Tiles. Spring Bean classes can be shown in both class and sequence diagrams along with any Property fields they contain. This allows for easy exploration of the hierarchy of beans along with a clearer view of dependency injection. Struts support enables you to explore the actions defined in xml configurations files; specifically, the dependencies to other actions, jsp pages, and classes all within an easy to understand class diagram. Tiles support allows you to easily see where different JSPs plug into various web components and how they relate to other java elements in a class diagram.
  • Making Cool Ideas Happen: Studying Our Users and Software Immigrants

    One of the nice things about being Software Developers, is that it’s really nice to spend our time working on cool ideas:  building out systems that help in situations where no solution currently exists. The problem is that often these cool ideas fail. Yes, using an Agile approach helps significantly, especially when customers/users request features. But often customers don’t realize what problems they need solved or what developers are capable of. Skilled engineers have the opportunity to really push the envelope with new and innovative ideas. The challenge then becomes making sure that these new ideas actually meet a need.

  • Eclipse Cheat Sheets: A Hands on Tutorial

    Based on the great response we have had to our previous cheat sheets articles, (why they rock and tips and tricks), I have decided to post a more in depth tutorial. One of the many benefits of Cheat sheets is that they provide an immediate improvement to your product’s usability and are simple to implement. This article will allow you to quickly create multiple cheat sheets.

    To help get you started we have created a cheat sheet on cheat sheets: This cheat sheet can be opened from within eclipse and will guide you through the simple steps for setting up a cheat sheet for your own project.

  • Eclipse Cheat Sheets: Tips and Tricks

    We talked about in a previous post why Cheat Sheets Rock. Our users have found them useful in the Architexa plugin and we are in the process of adding a great deal more cheat sheets to it. We have also had requests from our readers for more details on creating and utilizing cheat sheets effectively. Some of the most important tips that we found helpful while adding cheat sheets to our product are below to help you get started.

  • Eclipse Cheat Sheets Rock

    The hardest part in creating a user interface or complex feature is explaining to the user how it should be used. No matter how useful a feature is, if users can not figure out how to use it, it won’t provide them any benefit.

    Tutorials and wizards can both help in getting users easily using features for the first time. Tutorials can be good at describing the steps necessary to perform a task where users may want to modify the steps in order to accommodate their specific needs. But tutorials do not typically live within your plugin/product and force users to switch between a tutorial on a website and your product. Wizards are great for taking a user through an ordered series of configuration actions but they also have their weaknesses. Wizards live entirely in a dialog box, which not only has to be designed by the development team, but also does not provide nearly enough flexibility. This is where a little known feature of Eclipse comes to the rescue.

  • Dealing with Complex Code: Where to Start?

    When coding we often spend a significant amount of their time understanding new or unfamiliar code. Attempting to use a new library or fix a bug in a poorly organized component without first fully understanding the code we are working with can cause  headaches. Complex code can often be better understood through the use of diagramming tools (discussed here). However diagrams and other documentation cannot exist in a vacuum and there are tricks to better understand your code before attempting to diagram it.

  • Understanding Code Visually: Three Ways that Work

    In trying to help developers understand code we have made sure to listen to what they have to say. We’ve noticed that many developers utilize UML style diagrams to try to understand code. However many problems exist with existing tools. I have tried using a number of UML tools and found that the reverse-engineering capabilities in the majority of them were not helpful for understanding tasks. They focus on designing tasks; reverse-engineering capabilities often just end up showing convoluted pictures and lots of useless information. Even developers that commonly use these tools ask us how to best understand code. Of course there are many solutions to this problem and the solution varies depending on the situation.

    It is important to think about which specific perspectives you need to understand. Is the structure of the codebase in a state of disrepair and needs attention? Or are underlying code concepts, features, and logic the most important? There seem to be three main types of diagrams people use to help visually understand code.

  • Focusing on Developer Needs: Architectural Design, Understanding, and Documentation

    One of the nice things about launching a tool is the opportunity it allows in talking to our users. Over the last 3+ months we have spent a great deal of time talking to development teams about Architexa, and have gotten a great deal of insight not only into what they like and don’t like about Architexa, but more importantly, what pains they have felt. The consensus is clear: while developers do need to focus on coding on a day-to-day basis, to be successful on a long term they need to worry about the parts of the system that are shared between team members. These worries where what we focused on for the most recent release (v2) or Architexa.

  • Eclipse (Helios) rocks and a few critiques

    Helios has been out for over a month – and we have been using it. Yes, we are a little biased, but when you are working with and leading teams of 10+ developers you need to be practical. There are a number of things that Eclipse does really well, but there are a few things that we would like to see better.

  • Navigate through Large Projects with Ease using Eclipse

    When working with large code bases, finding your way around can sometime get quite challenging. In such cases, Eclipse makes a developer’s life a lot easier with its shortcuts and quick navigation features. Below is a compilation of a few shortcuts that I have found really useful.

    Quick Navigation in the Workspace

    While working with a large projects one of the challenges we face is to quickly find resources in the workspace. A very useful resource is or shortcut to find any kind of Java resource is Ctrl+Shift+T. It opens a dialog box to search for the needed resource and wildcards can be used in cases where you are not sure about the name of the class. Similarly Ctrl+Shift+R can be used to find any type of resource (even non Java) present in the workspace like jsp’s, xml’s etc.

  • 7 steps to working effectively on large projects with Eclipse

    Large projects often come with an independent (usually ant based) build system – so that the project can be built effectively in different situations. For programmers working on these projects, this often means setting up the IDE to work with these build systems. While working with development teams, I have seen way too many examples of the IDE not setup to take advantage of some of their features. Especially these days, IDE’s absolutely rock, so if you are not taking advantage of them then you are likely putting yourself at a disadvantage.

    Below are a set of steps that you can follow to configure Eclipse to effectively work on your project: