This version of the site is now archived. See the next iteration at v4.chriskrycho.com.

Dear Avid: Please Sell Sibelius

Dear Avid,1

Monday, after noting that my copy of Sibelius 5 would not install on my new MacBook Pro – no surprise, it is after all 5-year-old software – I looked for some solutions online. It became clear that I wouldn’t be able to get it going, so I started looking at upgrading to Sibelius 7, about which I’ve heard many good things. Upgrading was an easy decision: I’ve had nothing but good experiences with Sibelius since I bought a copy of Sibelius 3 back in 2004.

Along the way, I stumbled on this blog post by Daniel Spreadbury. Curious what he meant by “the recent news about Avid’s corporate restructuring”, I followed the link.

By now, I’m sure you can see where this is going: like many other long-time Sibelius users, I’m more than a bit disgruntled by the news. Read on, intrepid explorer →

Don’t Sell (Out)

Today, it came to my attention that Avid, maker of various audio and video processing tools – tools you’ve heard of if you’re in those industries, high profile names like Pro Tools – has closed down the main office responsible for developing Sibelius and sourced the development to a team in the Ukraine.

Nothing against the Ukrainians, but shutting down the London development office responsible for nearly two decades and replacing it with a team a third its size does not bode well for future development.

Box art for Sibelius 7

This came out in as underhanded a way as possible, with the sorts of PR doublespeak and carefully prepared press releases I’ve come to expect from large corporations. Avid’s statements indicated that they were consolidating their engineering efforts in order to save money. Since Sibelius seems to be quite profitable, it’s clear that Avid is choosing to bleed the product to support its other goals. This move, in other words, reeks of bean-counting trumping any love of product or any real concern for the customers that have invested in Sibelius over the last several decades – invested more than money. Read on, intrepid explorer →

We live in the future

I am composing this message on a laptop via my Verizon 4G data connection in an airport over 800 miles away from my home less than two hours after we left that home.

We live in the future. Imagine trying to explain that sentence to someone 150 years ago – or, parts of it, even 50 years ago – and you’ll see what I mean. Read on, intrepid explorer →

Just a quick note to the world: beware of leftover makefiles if you restructure a project in Eclipse CDT. Eclipse will happily create new makefiles with the appropriate information in them when you restructure you code – if, for example, you move source and header files into their own directories instead of being in one big blob at the root – but it won’t delete the old ones. As a result, you’re likely to see that ever-so-informative make: *** No rule to make target `calcVCE.o', needed by `cplus2.exe'. Stop. message that make generates when it’s looking for a file it can’t find. The old makefile is still hanging around, and Eclipse happily tries to run make against it. The easy solution is just to delete all your old makefiles when restructuring code and let Eclipse CDT rebuild them for you from scratch.

Good Programming in 3 Simple Rules

In the last few years, I have seen a little great code, some good code, a lot of mediocre code, and overwhelming amounts of bad code. (A shocking amount of my own code from previous years – especially when I was just starting – goes in the last two categories, alas.) The longer I have been at it and the more I have read (whether random articles on the web or the excellent Code Complete), the more I have concluded that good programming is simple. Incredibly hard, but simple. In fact, it is so simple, that you can sum it up in three short, easy to remember rules:

  1. Write code for people, not for computers.
  2. Don’t repeat yourself.
  3. Only do one thing at a time.

Read on, intrepid explorer →

Introducing: JIRA Commit Acceptance Plugin Tweaks (Python, Batch)

One of the tasks I set for myself with JIRA at Quest was to configure it and Subversion so that people can't check in with referencing a JIRA Issue. This is a little thing, but it helps ensure people will actually use the issue tracker, instead of letting it languish. Add good version and source control policies - the kind you implement on the server, not just the kind you tell people to use (because we all know how well that works out) - and you have a solution that helps people use both version control and the issue tracker sensibly. Read on, intrepid explorer →

Eclipse Indigo, Subversive, and Connectors

This is apparently a pretty common issue, so I thought I’d write up the solution to it. When using the suggested method of installing Subversive – one of two standard SVN client plugins for Eclipse, the other being Subclipse – the installation may fail (as it did for me). The Eclipse error messages for the failure aren’t incredibly informative, but I managed to figure out the issue, so here it is: Read on, intrepid explorer →