Many teams are moving to test driven development and very often this a good thing. In a drive towards increased code stability and maintainability, good test cases can be very helpful. But this is not always the case; while working with development teams, most teams seem to have one or more critical problems. It seems that it is easy to do Test Driven Development (TDD) badly – below are five situations that I have seen multiple times.
read more »

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.

read more »

We know that programmers do spend a lot of time understanding code. But what is not discussed as much are the implications of this limited understanding.

The reality of implementing new features or just fixing bugs is that the architecture of our underlying system continues to change. With time pressures to deliver such code updates, code changes often need to be made without thorough understanding and as development continues the code quality deteriorates. As such development continues, the system grows into a state where the “Cost of Change” rises rapidly over time, and the inability to meet user needs leads to the failure of many projects. read more »

One fact that is agreed upon – is that it takes a lot of time to understand code. Poorly commented code just makes this harder. The challenge that we face, is that developers’ often don’t want to take time away from coding to document, but working with code that is not commented takes more time in the long run.

It is always nice to work on a project that has excellent commenting. However, there have been many projects that I have worked on that have frustrated me with the effort needed in understanding them. When code that I have been writing needs to build on badly documented components, I have sometimes added my own comments. Tragically, I have often not been responsible for maintaining such components and my effort in commenting has gone to waste – as I have not checked them in. Such code often has had three traits.

read more »

After years of hard-work, we are extremely happy to be opening the doors to let everyone in to see our work.

We have been working hard so that programmers can easily work with large codebases – whether it is in making sense of the code that you have, documenting it, or just discussing it with team mates. You will notice that we have built a set of powerful but easy to use diagramming tools. We believe these tools will help you and your team work more effectively.

We are confident that you will find Architexa helpful in your coding tasks. We also want to make sure you are happy with using the Architexa Suite – so we do have a free 30-day trial that you can use. Additionally, as part of the launch we are offering an really big 50% discount for those who purchase a license in the next month.

Come on in!! Try the software, and most importantly, let us know what you think.

We’ve had a great response so far! Here are a few of the things people are saying…

A Better View of Code

“Dr. Dobb’s: Vineet, tell us about the product you’re launching.

Sinha: Architexa, which is the name of the company we’ve launched, was created to help members of development teams have a better view of the important aspects of the code — this includes not just seeing how the high-level components depend on one another, but also in understanding the core of a system (how the main classes interact with one another), and even the most important use cases.“

Architexa aims to make UML quick and easy

“Architexa is a new Eclipse-based UML modeling tool that allows developers to quickly gain insight into code relationships through UML diagrams, and share what they find with others.  The key to fast exploration of the code base is to provide 3 farmiliar diagram types to developers (layered, class and sequence diagram) and allow developers to build up the relationships and granularity as they explore and understanc the code base.“

Architexa: Get To Know Your Code Better

“As a startup letting people into the site has been useful. It has been great to hear from users as to what they have found to be challenging while working on their own codebases, and we have been really happy that what we are building aligns with their needs.“

Architexa builds modeling tools for developers

“Interactive and diagrammatic exploration tools were what people needed. The diagrams generated in existing UML tools show too much information, and there is little support for developers to explore and find the right information that they care about, he explained.
Traditional Unified Modeling Language (UML) tools focus heavily on design and code generation, but Sinha said UML can also be used to focus on communicating, verifying and understanding code, which was missing during his days at Microsoft.
“

Over the last two weeks, we here at Architexa have been overwhelmed by the positive response to our vision (see video on our homepage). At JavaHispano Abraham talked in spanish about (translated)

… always liking to use UML to understand and navigate source code that is not mine and that I have to change. Or even my old code that I can not remember exactly how it is organized. However, I have never been able to create a lot of UML diagrams and use them to generate the skeleton code. So my pattern of use of these tools fits well with the philosophy of Architexa.

He went on to say that

The difference with all the [Architexa] tools is that they are designed to “surf” the source code through UML diagrams, so that one may be viewing more or less detail as you need. It is not an all or nothing, which is usually the case with\ traditional UML tools.

A poll trying to find if developers let their UML/design diagrams go stale, recognized that “sometimes it can be too much work to go back and update diagrams once the coding process is underway, especially when under a tight deadline”. It found that over 2/3rd developers noticed that with today’s tools their diagrams go stale with them falling back to their code.

One of the editors at JavaLobby, James Sugrue, did an an interview and talked about how Architexa makes life easy for developers. He talks about seeing a huge potential in our tool “for helping out with code reviews, or for getting into a new code base”.

In the Social Media world, it was nice to be referred to as the next generation of UML tools:

Since exiting the beta, we have been encouraged by the response and are letting people in to use the suite as fast as we can. We want to make sure developers have a great experience with our suite and we want to provide a great level of support while doing that.

We will be releasing additional videos and information on the product soon in addition to the (hopefully) informative content you’ve come to expect.

We have been extremely frustrated with UML tooling in the past, and for the last 2+ years we have been building something very cool. See the video below:

Can’t see the video? Click here
Most UML Tools focus on creating diagrams before coding, but we believe in having diagrams made from code. Where other tools require months of work to get something useful, we want to get you useful results in minutes if not seconds. Some tools require reading lots of documentation to use, but we have wanted a tool that you can get up to speed in 5 minutes.

What do you think of it?
(interested? sign up and use on our homepage)

While working on a codebase, developers spend a lot of time understanding code. We might be unwilling to admit it for fear of sounding dumb but the huge amount of time spent on making sense of code is staggering. In fact a conference is held every year just to tackle this problem. The good news is that with the emergence of online communities more and more people are discussing the challenges of working with large codebases openly.

read more »

The Waterfall model has become a joke and is pointed to as an way of doing software development poorly. While the approach has a number of limitations, it is helpful in some situations. Understanding these situations can be useful when trying to use an agile development methodolgy to make sure that you do not make critical mistakes.

During a conversation last week, a team lead told me that he considered Agile and Watefall as being two different approaches with the same result. As a proponent of Agile approaches, I tried to understand his situation and convince him of the benefit of an agile approach. After some discussion, I came to the conclusion that his situation was unique in that it actually benefit from a more rigid approach.

read more »

As the hype around Agile Development has been reducing – it has moved from just being a buzz word to a set of principles with teams benefiting from adopting it. However, many teams trying to transition to Agile are still not able to do it successfully.

Part of the challenge is that a large focus of agile has been about teams being able to respond to change and thus working with multiple iterations while having working code. But the focus on iterations and working code is not enough to do agile successfully. Agile teams need to make sure that the teams collaborate and work together effectively to produce results.

read more »