I work on a few projects outside of my day job (which also uses FogBugz) and one of the things I’d like to add to the products for my day job and side projects is the ability to send Windows minidump files to FogBugz automatically.  One way to do that is through email.  Unfortunately that did not work so well for us.  Using the C++ bugzscout wrapper does not allow file attachments.  The good news is that one can use the FogBugz XML API to access a FogBugz account – including file attachments.  The not so good new is that while the API has some neat wrappers for .NET, there is nothing like that for unmanaged C++ code.

The solution?  A codeplex open source project.  Then I found the StackOverflow open source ads! I threw up a really bad logo and entered the “contest”.  The FogCreek and SO staff pitched in to help me out and came up with not one, but two great logos to use.

Come join us, or just wait for the functionality to be released.

And thanks again Michael, Aviral and Yi for the help.

I recently found yet one more reason to love it.  I can trigger builds remotely via instant messaging.  This is not really necessary for normal projects since commits to our version control system trigger builds.  I wanted the IM trigger functionality so that I (or any other developer) could ‘promote’ a development/candidate build to ‘stable’ or public status.

All our builds are FTPed to a server, however the directory they are in is not public.  We also have a public-facing directory for builds we have tested and are confident in.  Prior to using hudson for this process I had to manually log in to the server and copy the file(s).  This usually had to take place after working hours since I have a day-job, thus the copy was not immediate.  Also, my partner has no interest in figuring out how to log in and copy the files on the ftp server, but he interacts with customers and does a lot of the testing that determines if/when builds are approved for release.  It makes sense that he should be able to trigger the process.

So, after some poking around and not being able to get an email trigger to work, I tried the Jabber plugin for hudson.  It was pretty easy to configure and after a few simple tests I found that it fit the bill perfectly.

So now when my partner or I need to publish a build to the world, instead of logging in to an ftp site, finding the right file, copying files, waiting for them to transfer and then logging out, all I have to do is go to my google chat window, start an IM with the build machine account I created, and type:

!build Promote 1234

and it is done.  In the example above, ‘Promote’ is the name of the parameterized build/project that does the copy/promotion and ’1234′ is the svn revision number of the build I want to publish.

So, once again, to the folks at hudson and to the plugin developers: Thank you for a wonderful tool.

While we were quite happy with the product, partners and customers, we felt that we were too busy on other projects to support the software and make the upgrades that the customers and hardware manufacturer deserved.

An old nitpick of mine just resurfaced with a vengeance, and since the most compelling things for me to write about seem to be annoyances and complaints, this will fit right in.

I am working on a start up with a partner. We’re going to be supporting some hardware cards with our software application. Well, we thought we were going to support hardware cards. It now turns out we’re going to support only one card manufacturer.  Unfortunately the other manufacturer thinks it’s better to restrict access to its API than to give it away for free. You can’t get their API unless you buy the card, and we have not yet bought their card.

We’re software developers. We’re a startup. We’re staying clear of investors for now. Our startup is bootstrapping itself and exotic hardware is an expenditure we’re going to live without for now. We don’t want to spend $10,000 right now on a piece of hardware just to get access to an API.
We’re not losing sleep over this – the more reasonable manufacturer’s cards are a fraction of the cost, and deliver the same, if not more functionality. In fact, if the unreasonable company let us use their API we wouldn’t have found the competitor with a better value, so we are happy this has happened.  However, that doesn’t change the fact that the policy is dumb.

I have seen this kind of idiotic thinking in the past – for some reason some companies selling a service or data or hardware think that they should keep their APIs/interface a secret to protect something. Protect what, exactly? From people trying to use their products?  I would have imagined that you’d WANT to give people access to it – even offer to help them with writing applications for you API and hardware or service.  After all, the more developers that write software for your products the more access you have to end users. (read $$)

APIs shouldn’t be revenue generators – the services or data they provide are the revenue generators. Provide easy access to the APIs and help developers.

We weren’t trying to get something for free. We were hoping to provide value to our customers who already own the hardware cards and wished to use our software as well.  Most likely now they will see our solution, look at the vendors we support, notice the price difference, perhaps ask why we don’t support the other vendor (yet) and likely switch to the cheaper hardware we selected.  So, in not allowing us access to an API, the intransigent manufacturer has cost themselves many sales.

We have every intention of supporting the one who rejected us – eventually.  They are a big name in the field – the name everyone seems to know.  But they are going to lag in sales for our solution and market because of this stupid, screwed up posture.

There is no business justification for putting up roadblocks to your APIs. None.

If you are selling services, products or anything else and you have an API to access them: please, think about your policies. If you don’t allow third party vendors or anyone else access to the API for free, you are putting up barriers and likely costing yourselves business.

When my new hires were scheduled to start I did all that I could to make sure they felt welcomed. I had limited powers of course, but small gestures like finding an unstained chair for them to use and a computer that had more than 128MB of RAM were appreciated.

My views were not shared by all my peers. Apparently some took the terms “working manager” and “hands-on-manager” to heart. They liked to spend lots of time looking at code and they dreaded talking to their reports except to “call them into their office” to tell them what to do and how to do it. Of course, I never worked as a manager. Work is for suckers. I avoided work. So I had to make sure the people who reported to me made up for my laziness. And boy, did they ever!

Chris was a new hire. He showed up on time. I discovered him wandering around the reception area on his first day. I welcomed him and showed him to his new home/cube and left him there then went to inform his manager that his fresh young hire right out of college had arrived. Peter (we’ll call him Peter for now) hardly looked up from his buggy code and mumbled something about being too busy – lots of (bad) code to write that day apparently. I thought he was kidding. Nope, he wasn’t. Apparently this golden boy was too important to waste time greeting, introducing and getting his new report started. Of course, I was not that special or important, so I had plenty of time to waste on a new employee. I introduced Chris around to everyone (including his very busy manager), got him a company t-shirt, and showed him where the bathroom was – all very, very important things. (At least to me and my bladder and I think to Chris’s)

I never could figure out why we didn’t do more to knock the socks off new hires on their first day. I am sure that during their first personal calls of the day (either while at work or when they got home) they were asked how the new job was or how they liked the new company. Here’s where we stop the film and pause it and the narrator steps in front to pose a dilemma and present a choice to the viewers. What do you want that new hire to say?

“Man, this place is fantastic – they had free Snapple and bagels for me and dancing girls popped out of the cake and there was a valet in the bathroom to dry my hands for me…” (well, maybe no cake or girls)

or

“My boss was too busy to greet me and introduce me to the team, but that’s ok, he scheduled a time for us to meet next week when he has time. I found the bathroom myself and I should have a phone at my desk by the end of the week, but I don’t really need it yet because they haven’t found me a permanent office. The temporary computer they gave me to use doesn’t have a development environment on it, but at least it has the internets so I can check monster.com again for other jobs.”

Chances are that this new hire knows other competent people and those people might be looking for good companies to work for. One scenario above makes it easy to get candidates lined up at your interview room – the other one predisposes new hires to line up at the HR office for exit interviews or just never show up to work again. Some people are too busy fighting fires and fixing all the bad code they wrote to consider the consequences.

You never get a second chance at a first impression. (I hate clichés like that, but it happens to agree with my sentiments, so there it is.)

This “must have feature” was the greatly hyped Intel® Pentium® Processor serial number. After getting the secret orders I ran back to my office to plan my whiz-bang implementation. But. There. Was. One. Minor. Problem. There was no context for this information. It was meaningless. It helped no one. So I made an ass of myself and raised the question, “Why are we doing this? It isn’t used anywhere in the product.” (I didn’t even get to the part where I asked what we should do for multi-processor machines)

I needn’t have worried. A careful, well-thought-out argument came back my way: “Just do it.” Apparently having the Intel® logo on our box in the stores would make the product boxes fly off the shelves even faster. At least that is what the marketing and product geniuses claimed. So I “just did it.” It was as useful as an ice cube in Antarctica. And I had a hand in it. What a proud day that was for me.

But wait. It gets even better. The objections started slowly and imperceptibly, but as momentum gained the apparently super-duper-useless feature became a liability. People were afraid of the serial number. It could identify them. Products that touted being able to take advantage of the serial number were seen as Big Brotherly, and not in a Philadelphia loving kind of way.

I don’t recall what became of the code I put into the product, but hopefully it was removed or quietly optimized out of the product by a compiler that was smarter than my managers and knew the code wasn’t getting called.

Just Do It. But first, make sure it is useful.