On the subject of changing jobs, here’s a few points I’ve been considering:
- I’m in a stress free but relatively low-paid job as a software engineer in an insurance company. Three miles from home to the office is very handy, especially considering I often have to pick up children from nursery. However…
- I’m generally frustrated with the heavy weight and bureaucratic, yet rather ad-hoc nature of the development processes. Although this is not a major issue for me, there are other considerations…
- I’ve been transferred to a project that could be described as “morale sapping” by applying a generous dose of optimism.
- This new project is based in Redhill, about ten miles away. This is no longer that convenient for me.
- The IT job market has been steadily improving over the last year, and agents are calling me out of the blue asking for availability.
- I’ve been meaning to try my hand at the contract market for a long time now, where I’m certain I could very easily double my income.
- My kids are now at the stage where I should be able to venture further afield without neglecting them too much
On Friday, I came to the point where I had a chance to think these issues over, came to the obvious conclusion, and handed in my resignation. It looks like I’m about to go back onto the job market. Time to update my CV.
(BTW, if anyone knows about job opportunities opening up around late September, let me know).
Mike Clark mentioned my Ant dependencies article on Pragmatic Automation last week. For a low traffic site such as Exubero, it’s easy to look in the referrer logs to see how that reference has spread to various other blogs. I was relatively surprised about the effect that social bookmarking has on propagating ideas. I haven’t paid much attention to the phenomenon before, but the multiplier effect on the incoming referrers certainly made me look a lot closer.
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: