3 mantras of modern day software development

Ok, I have been an avid reader of 43 folders for a while now. This week, however, they published a 3-part article on 'getting things done - software development' - and I thought that I would reiterate these mantras, how to apply with modern-day tools and discuss what happens if they are not applied.

So what are the 3 mantras: test, refactor, document! Ok, a caveat to these mantras, this should only be followed if you want to maintain (and improve) an application for more than a year, but if you don't want to do this, what sort of business case do you have?!

1. TEST: despite overwhelming industry material over the last few years about the advantages of unit testing, there still seem to be a significant number of projects that do not enforce unit testing. The advantages are clear, unit testing enhances design (e.g. that there should be only one public API per class), enhances quality (e.g. combined with a coverage tool, all branches of logic are run, and verified in terms of expected behaviour), and most importantly this provides a baseline for the application's operation and maintenance. So, with a complete set of unit tests (i.e. coverage greater than 90%), any change to the underlying code base can be made by anyone because if the existing functionality is compromised a unit test will break. Therefore, immediately new developers are able to confidently make changes to the application, regardless of the size or complexity. In Java, one needs to look no further than JUnit, TestNG, etc..
   
2. REFACTOR: refactoring is the ability for developers to change, rework, and enhance any exisiting code from an application that is required. Why? well this enables applications to be modernised and for existing, or more importantly future flaws to be corrected and countered. Not every line of code is written at the same quality as every other line of code (due to poor requirements, inexperience, poor implementation, etc.), with refactoring (as long as it is controlled) then the application's code base is continually being refined and in conjunction with unit tests, provides a robust, modifiable approach to maintaining application longetivity. A prerequisite for refactoring a featured IDE - and IntelliJ 6.0 cannot be beaten in this regard.
   
3. DOCUMENTATION: probaly the most controversial; I used to think that unit tests alone could document an application, but in order to capture the brainstorming, design sessions, implementation decisions made in developing an application than some form of documentation is needed. I am a firm believer that all documentation related to an application: namely arhcitecture, requirements, design sessions, implementation, and maintenance should be held in a wiki with the condition that it has Google-like search features. To this end, Confluence must be the only option, and I see it as almost standard to any software development.

Without these approaches, I would foresee significant difficulty in maintaining any application.

Design and development

Just recently read an article in Wired as to how the iPod was developed; one byline in particular caught my attention:

"Apple's designers spend 10 percent of their time doing traditional industrial design: coming up with ideas, drawing, making models, brainstorming, and they spend 90 percent of their time working with manufacturing, figuring out how to implement their ideas."

No argument could have been described more aptly as to relationship between solution architecture and development. That is, design is important, it is critical that it is conducted at the beginning, but in the end, it is in the implementation that real issues arise. It is the 'figuring' out how to deal with these issues and implement the design where the focus of architects and team leads should be.

Software development is easy

Ok, I have decided to create a presentation (and indeed a white paper, if I truly become inspired) describing why enterprise software development is easy, and what companies should be expecting from software vendors in terms of quality. Expect draft - beta soon!

Crucible - code reviewing tool

I was recently reading an excellent article on the development of a 'coding factory'; in this article it referenced Crucible as a code review tool. I registered for EAP and downloaded version 0.7.

I was very impressed with this tool (despite its inability to support IBM Clearcase as a SCM). Crucible is a code-reviewing servelt / web tool which hooks into the project's SCM. Once hooked in, all code can be reviewed and comments inlined. The main advantage of this is that it allows code reviews to be done continuously. Much like pairing and the obvious advantages in quality with which this provides, Crucible allows for other developer's to touch and review the code leave comments that relate to particular lines / patterns. A workflow is automatically generated allowing the comments on the code to be looked at, and if necessary refactored into the code. I can see that the main advantage of this would be onshore / offshore development as it would allow online review and feedback loops to be aligned to the project / iteration lifecycle. Secondary to this, it is a great way for more senior developers to break new starters / graduates out of poor coding styles , or even as a means to stage gate code going to test / production.

Now if only I could work on a project that used subversion or cvs to test this out!

IntelliJ 6.0 released and a tip!

Yes, having used IntelliJ for the past 5 years now, I was pleased to see IntelliJ 6.0 released, although since I am not on Java 5 project - I can't test many of its juicier features. Nonetheless, it appears the best version ever.

And if you are getting some performance issues for IntelliJ on Windows when into IntelliJ:

1. go to Settings -> General -> toggle Synchronize files on frame activation;
2. set JDK (for running IntelliJ) to version 6 Mustang; by setting IDEA_HOME and overriding 'idea.no.jdk.check=true' in the idea.properties file