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.
It’s taken two years, but I’ve finally updated my Curriculum Vitae. After dusting it off and reading over it again, I’m surprised by how many different technologies I’ve managed to play with so far in my career. I still have the sneaking suspicion that I won’t be stopping learning new things yet, and the holes in my knowledge leave plenty of room for improvement.
I’ve been preparing a slide show to present to the “Best Practice” group at work. I was looking for a simple way to do the presentation, when I came across Eric Meyer’s Simple Standards-Based Slide Show System (S5 for short). I’m really impressed with how simple and easy it was to create a new slide show, and adapt the look and feel for the company style. Kudos to Eric!
My Introduction to CruiseControl presentation is now available on-line. If anyone has any feedback, or feels that they can use the presentation themselves, please let me know.
I’m a big believer in the benefits of Continuous Integration, and so I have become a user and then contributor of CruiseControl.
I find the continually increasing awareness of CruiseControl in the development community quite exciting. Mike Clark’s new book has been receiving a lot of attention , which has been translating directly into a lot of new users. I find the CruiseControl project statistics graph at SourceForge very interesting indeed. I expect that this month will break page view and download records again, especially if version 2.2 gets released on time.
Why am I excited about this? Besides the fact that Continuous Integration is a fantastic development process, I also have a personal stake in CruiseControl. I have been making contributions to the website and documentation, an area that is traditionally quite weak in open source projects. In helping out and assuming ownership in a relatively unmaintained area, I’ve become quite connected with the success of the project. Marking out my home in the noosphere, I guess.