« August 2006 | Main | October 2006 »

September 30, 2006

New Things to Read

I've added a few links to the list of things to read. I'll just mention a few of the articles I found worth noting...

Making Developers Cry Since 1995, which gave me the link to The Braidy Tester, mentions a number of things that testers and, therefore, application developers should be testing. There were a number of things I had not considered and did not know ... for instance, the fact that Windows has filesystem reserved words allowing access to, for instance, com ports. And the picture is particularly disturbing. The prior entry's reference to James Shore's Change Diary, a nineteen week effort to introduce aspects of Agile development in to a waterfall environment, is also an illuminating read. My own efforts toward this end have been more subtle and even more indirect, so it's reassuring to see some success documented.

CIO Magazine also has quite a number of good articles, and should be read if for no other reason than that it's reasonable to assume your CIO is reading it. Some of the items I found useful were How to Hook the Talent You Need, which describes both a shift in skill preferences for IT staff (a little overly optimistic, I think), as well as some of the things companies can be doing to acquire and retain good staff, and Tracks in the Snow describes other interpretations of failure and success with regard to software projects (although I'm not sure why we needed an article for this ... if you're in a waterfall shop, look at each step and figure out what failure in any one step looks like at the end.)

In other news, as a round-the-clock coffee drinker who has recently been introduced to the possibility that most commercial coffee is stale, and who enjoys the lack of effort necessary, during my somnambulant mornings, to use espresso pods, I am considering an automatic espresso machine. Any recommendations?

September 14, 2006

The Enticement of Vacation

My managers at the company I'm currently contracting with are quite interested in getting me to come on full time. To this end, they keep dangling the opportunity to have paid vacation in front of me.

Vacations for software developers are interesting things. The better and more essential they are, and therefore the more justified they are in being rewarded with some vacation, the less likely it is that they will have the opportunity to do so.

The difficulty is that they're probably on a project. If they take two (or more!) weeks off in the middle of the project, they've just impacted the project plan. They could plan for after the project release, but you rarely release on time, and a late project trying to wrap up is even more hectic and personnel-critical than before, so planning for that isn't safe, either. They could plan for a reasonable period after the anticipated release, to compensate for late release, but then you're in the critical, "oh my god we've got a bug so obscure that it didn't come out in QA or UAT and no-one else can figure it out can you help, please" phase. And the reason they're having to beg is that the company has already committed them to both support for the released project and preliminary design on at least one other project.

You might say, "just take the vacation, and be damned with the company." But software developers have the most ridiculous work ethic you are ever likely to encounter. What other industry do you know in which the production team regularly works 200-250% of their paid hours in order to compensate for management ineptitude?

It's not just commitment to the work, however, but also an aversion to forcing their colleagues to work harder in order to compensate for their lack of working. Unscrupulous management (and there are many, for a number of reasons) will use this to their advantage, blackmailing programmers by their own ethics. One of the managers at my last company (after several iterations of "put in extra effort, just for the next two weeks") actually pulled the "well, if you can't work on Saturday, your colleagues will just have to work harder to make up the slack" tactic.

And that's just the developers' personal drive. Let's not even go into the whole perception of not being a "team player" thing for actually taking a vacation in the middle of a project (or not working long hours and weekends, which is why they need the vacations in the first place.)

What it comes down to is that, if paid vacation time is your biggest enticement and the means by which you distinguish yourself from other companies, you might want to have some process in place (as a joint effort between HR and project management, perhaps ... or, better yet, project management and a travel agent) that actually makes the enticement worthwhile to your team. Otherwise, your programmers are going to do the math, discover that their hourly wage is more in line with the income for delivering pizzas, and that their most significant reward is useless.

September 12, 2006

Absence Makes the Heart ...

Yes, I haven't been writing much recently. I still have things to write about, but most of them will take quite a bit of research to finish and, in addition to the release the company I'm currently contracted with just finished, I am in the process of getting two companies going. Hopefully, things will be a bit more accommodating in the near future.

September 06, 2006

Like a Bowl Full of Jelly

Whereas previous articles warned of an obesity epidemic in the US, recent articles assert that the issue is a world-wide concern. So I started wondering if the increase in obesity (requiring larger clothes) and the tendency to dramatically fluctuate in weight during efforts to reduce weight (causing greater turnover in clothes) have influenced the textile market. And, if so, have any textile consortia figured this out to the extent that they might be promoting companies that either facilitate weight change through whatever mechanism?

I can't find anything online to suggest an answer to these questions.

September 02, 2006

Oblivious Incompetence

There's a small coffee shop in Denver called Paris on the Platte. It's one of the old-style, youngster hangouts, heavy on the pretension and patronized by whatever subculture is currently exhibiting the most angst, or the adults such creatures evolve into. You know the place ... "art" for sale on the walls by artists who claim the right to the title because their paintings are both aesthetically displeasing and only understandable by people who have the "right" intuition, blasting music designated as "cool" by virtue of being loud and having spurned the quaint notion of melody, and, of course, the heavy taint of cigars and clove cigarettes (obviously, I'm not the intended culture they're trying to entice.)

But they have huge pots of chai, chicory coffee, free wireless, and at one point had a view of downtown (although it now has a view of the condos across the street.) So not entirely without redeeming qualities.

On the gripping hand, they only seem to hire from the same population that is their target market. This is unfortunate, because one facet of the culture is the fact that oblivious incompetence is also considered "cool". Since returning to Denver, I have been here twice. Once, I left after 30 minutes because not one of the wait staff was kind enough to see if I actually wanted to give them any money. Today, the morning shift ... the entire shift ... didn't bother showing up. So they unapologetically (I mean that literally) opened up 3 hours late (to give a baseline, the parking meters in front of the place are only good for a max of 2 hours.) Given that 100% of my visits here since returning have been unsatisfactory, I'm going to have to give serious thought to wasting my time by coming here again.

A moral and a question ... be aware of the deficiencies of your target market, and weigh the benefit of hiring from that same pool in order to enhance the attractive culture vs. the number of customer you'll lose as a consequence of those deficiencies. (And, eventually, you're going to want to start estimating how many of those annoyed customers have blogs.)

The question ... where else in Denver can I get wireless and chicory coffee?

Update:
after sitting here for an hour, I can make the following statements.

  1. The chicory coffee is not as good as it used to be
  2. The wireless network is flaky ... don't do anything that requires a constant connection
  3. There is a fly problem
  4. They've just played the same song for the sixth time
  5. There is significant irony in the fact of a "right of way" policing truck parked in the middle of the road

September 01, 2006

Notes on MSMQ

I've used MSMQ many times in the past. However, it's always been on my own systems, so I always exhibited the programmer's virtue of laziness and assume that I have correctly created the message queue and set its transactional state to what I expect it to be, and write my program accordingly.

However, this time I'm writing code that will set the standard for other programmers' work, and I don't maintain the infrastructure myself, so I thought I'd be thorough and do things like check for the existence of the queue and check to see if it was created to be transactional and behave accordingly. This all worked perfectly in my local development environment with its local queues.

But when I went to test the installation in the QA environment, I ran into all kinds of trouble. Specifically, all the properties and methods I was trying to use, with the exception of Send(), were throwing exceptions. 6 hours, lots of Googling, and 5 bodies later, I discovered the problem.

The functionality available in the MessageQueue object changes based on whether the queue being specified is local or remote, and which of the many queue path syntax you use. If you can't code for a specific environment (e.g., if the queue path is a configurable value) there is no way of knowing what functionality is available at run time other than trying to use a method or property and trapping the resulting exceptions.

This behavior is so incredibly bad in an infrastructure mechanism that it never occured to me that it would be coded this way, so I didn't even think of hitting the documentation of each failing method and property to see if it was actually available in any given context until I had exhausted every other possibility and scenario. And there were no googled pages that led me to conclude that that would be a good thing to do, despite other people obviously having the same problem.

So I'm putting this out there to prevent others from going through the same thing.

As an aside...
index -> indices
syntax -> syntices?