What makes a high quality piece of software? Kind of a tough question to answer; everyone has their own idea of quality. I like to look at quality from a team perspective; I believe that quality software has the following signature traits:
- Shared vision, documented design
- Code that is easy to change and supports refactoring
- Ability to prove that the code executes correctly
- Code consistency
None of these traits are original and they all have their roots in traditional software development methodologies. I believe that their relevancy was renewed by the Extreme Programming and Agile development movements and actually made possible by tools which have emerged over the last few years. There are definitely other traits that convey software quality, such as efficiency, usability, and applicability. However, I believe that these are more dependent on individual efforts, rather than a product of team cohesiveness.
I know there are many alternative views and even skeptics who claim we don’t need coding standards or unit test suites. They believe their systems represent high quality software; but how do they really know? What proof do they really have? To their defense, the applications have been running, performing real business function, requiring very little maintenance, and apparently very few bugs. But, do those criteria actually imply quality? The stability of a system is definitely an important quality trait, but I would consider it a secondary trait; one that is actually a side effect of a signature trait, proof that the code actually executes properly.
While writing, I also realized there was another dimension that supersedes all other traits, the team’s cohesiveness. I believe it is very much related to having a ‘vision’, for a team to effectively produce quality software, there needs to be complete synergy. This sounds a lot like ‘assimilation’, maybe it is, but I really don’t like that word. I don’t think I have ever seen a team without a vision, but rather too many incompatible visions; they never have the opportunity to form the unified vision. This encompasses how things are designed, how they are constructed, and even how they are tested. If the team does not have synergy, achieving quality will cost a lot more. This cost will not be a corporate cost, but more of a individual cost, the additional effort required by each member of the team to ensure the project gets finished.
There is another, more personal trait that I like to apply to my projects, the desire to do things better the next time around. I’m not sure about you, but I have never built the perfect piece of software. I always think about how I could have done a better design or a better job coding. We don’t always get the chance to redo our work. But without seriously evaluating our own work, how can we ever learn from our mistakes. It is very important that the team wants to evolve, if the team is wed to their current coding patterns and practices, then achieving higher levels of quality is going to be much harder, maybe even impossible. I think quality is evolutionary; you just don’t “make” quality happen. The team has to be interested and excited about creating the best possible software, within their current environment.
Within their current environment; it is a very interesting qualifier to the above statement. I believe many teams use their environment as an excuse to keep the status quo. I think it is very important and my personal responsibility to do things better, every day, every iteration, every assignment. I have never worked on a project that did not have some amount of built-in cushion, for all of those unplanned requirements. Moreover, if it was something that the team really believed in and wanted to do, then we made it happen; if that meant some long hours, then that is what we did. Teams need to use the slow times to their advantage, adding new tool and techniques to their toolbox, improving the development process, and going after those nagging problems that never get addressed.
I have worked with and observed teams where the software development environment was like a game, developers were challenged and excited to create clean builds, remove warnings, and even create unit test. I have seen teams actually compete to generate better code coverage numbers than a rival team. <Disclaimer>High code coverage does not imply high quality code; more on that later!</Disclaimer>. The bottom line is, these teams wanted to make their code better and doing these activities was considered fun rather than a burden or something that provided no value. To further illustrate my point, I found a plug-in for the Hudson Continuous Integration tool that I would love to try, it is call the “Continuous Integration Game”. Developers actually earn (or lose) points depending on the code they check in. Break the build, lose 10 points, add a unit test and earn a point. It may seem silly, but if inexpensive, little metrics can help energize a team, then I am all for it.
I really don’t think I addressed any of my signature traits in this post, but it was important to establish a philosophical baseline for future posts on quality software development. In future posts, I hope to address how we have used tools and techniques to continuously improve our software development process and ultimately, build better software.
Sometime back, using the Spring Framework and jUnit 4.x was not very elegant. Spring only supported dependency injection by sub-classing their AbstractDependencyInjectionSpringContextTests class. The coolest thing about jUnit 4.x was the implementation of annotations and the elimination of the requirement to extend the jUnit TestCase class. Obviously, this was considered an issue by many people, as several projects created their own solutions for jUnit 4.x integration. One such implemenation was 
Everyone knows that I’m always preaching about code quality and testing, and yesterday I was reading something on the web that I just thought was just too funny. There is actually an Eclipse plug-in called 