I’ve updated the JUnit AntiPatterns article with a new anti-pattern: Multiple Assertions.
I’ve written a new article on managing Project Dependencies using Ant. From the overview:
This article discusses a technique for managing the build order of separate sub-projects in a large software system purely using task dependencies within Ant scripts. Unlike other solutions, this technique for managing dependencies does not need any external tasks to those already distributed with Apache Ant, as it leverages Ant’s inbuilt target dependency behaviour.
JUnit AntiPatterns is an article on JUnit worst practices that I have written, in response to some scary examples of software “engineering” that I encountered during code reviews. Feedback is always welcome!
It’s been a while since I left, but they’re trying to pull me back to school. Not quite kicking and screaming, though, as it’s the 15 year reunion of the Class of 1990 in May.
I really would like to go, but unfortunately I’m currently on the wrong side of the world to be able to drop in. Without being able to make an appearance, I thought that I could still contribute to the organisation of the event, so I created JoeysWiki. Wikis are a great way to allow many people distributed around the world to collaborate; this should will be a useful forum where everyone can keep in contact and publish details of the event.
Lately, I have been pondering the politics of process improvement in a large software organisation. This relates directly to me being invited to join my employers’ Software Engineering Process Group (SPEG). This committee is also known as the Software Process Improvement Group (SPIG) in other circles.
I attended my first SEPG meeting yesterday. After seeing the characters that inhabit the forum, I’m a little daunted by the prospect of raising items to the agenda, mainly due to the political nature of the group. The SEPG is made up of about fifteen or so middle managers from various corners of the operational and IT divisions. And me – the sole representative from the development community.
I would regard myself as fully qualified to work in such a group, having extensively studied various papers on CMM and SPI, as well as chairing a similar committee five years ago in another (much smaller) company. I have a keen interest in making use of the best methodologies for software development, as I believe this is the best way to write software that will create business benefit and delight its users (and so make me happy).
My committee co-members are qualified in the sense that they control staff resources and budget to accomplish process change. However, they are also unqualified in that they not necessarily interested in enacting change. Rather, they are representing various factions in the the company, and have incentive to try and protect their turf by ensuring that any change that does occur will not subtract from their slice of the pie.
The realities of working in any large enough organisation is that political influences play a primary role in determining how work is organised and allocated. Change of any sort is usually viewed with suspicion and hostility. When a group whose main purpose is to enact change (such as the SEPG) is populated by people who resist change, it doesn’t bode well for the effectiveness of the group.
In the end, I still think that there is a lot that can be achieved. There is a large amount of pain being felt in the business because of problems in the current processes (or lack thereof). This means that there is a certain amount of desire to fix the problems. It just may require a certain amount of delicacy and tact to prise people away from the status quo.
I found a couple of interesting resources from Rational with some interesting points on the problem:
(The following announcement is taken from the release notes)
The AFP Renderer development team (that’s Pete and I) is pleased to announce the release of AFP Renderer 1.1.0.
This latest release can be downloaded from http://afp-renderer.sourceforge.net/download.html.
The important changes since the last release (1.0.2) are:
- added support for outline fonts
- added sample fonts with distribution
- added XML2AFP command-line utility
- added examples
- fixed rendering of tables removing double lines
- fixed rendering of tables in landscape
- fixed shading table cell problem in landscape
- expanded and updated documentation
Existing users should read the notes on upgrading the configuration in http://afp-renderer.sourceforge.net/configuring.html, as the structure of afp-fonts.xml has changed slightly.
For more information about the AFP Renderer, see http://afp-renderer.sourceforge.net/.
I am a very enthusiastic champion of life-cycle processes and development techniques that can produce better software products. My view is that improving process methodology in key process areas can give enormous benefits in terms of quality and time to market for software development. However, too much process change in the short term can have detrimental effects; pragmatism must always be applied, especially when commercial realities mean that corners must be cut sometimes in order to meet deadlines.
As can possibly be surmised from my last post, I have recently been involved in a job interview. I found it to be a very interesting and educational exercise in the relative importance of process versus product. You’ll have to read on to determine the winner in this case.
I was called up out of the blue by an agent with a fantastic job description that sounded like it had been written using my career goals as a template, located two miles down the road from home, and a much better pay to boot. Of course I took an interest, and sent in my CV. What followed was one of the most thorough and challenging interview processes that I have ever been through. There were three contact points with the company:
- A seventy minute telephone interview. This went very well, as I thought that there was a fair amount of mutual agreement on development methodologies and technologies. I though I had a good rapport with the interviewer.
- I spent about three hours working on a program to solve a coding problem set by the company (obviously, my code was excellent!).
- I was called into an interview on site that lasted over three hours, as my work history was queried in excruciating detail, along with my opinions on development strategies and methodologies.
The end result? Although I had an excellent background, there was concern with my emphasis on process rather than the end product, and hence they did not want to progress things. Although I feel the slight sting of rejection in this decision, I can’t really take this as a setback, as I was not even looking to change jobs anyway.
I think the lesson to learn from the experience is that you need to choose your moments carefully when advocating process improvement. In the end, the people with the money what to know that you can deliver saleable product within budget and before the competition does. Although I firmly believe that attention to development process will actually help the business goals, the correlation is not always obvious.