I’ve been with XBMC and Boxee since the beginning first on an old Xbox, then an Apple TV and it seemed like the Boxee Box finally was going to make this homebrew magic into a mainstream star.

That’s a long preamble and I’m sure you can guess my experience wasn’t a positive one.

First let me say that the D-Link hardware looks amazing. The cube is small, quirky and makes for a big visual upgrade from an Xbox.

But due to some really premature software, this is where the love affair ended. The warning signals started right at boot with wifi troubles. That really was just the beginning. From a web browser that ignores any link to a new target window (you have no idea how many sites that breaks), to apps that don’t work… this project is nowhere near ready for primetime.

Ultimately, I had to rebox the Boxee and take it back because it doesn’t even replicate the functionality of my old Xbox with XBMC. You can’t play music without using your TV. That really was the final straw as I use XBMC to stream music all day using the web interface to control it.

So why am I posting all of this here. It all centers around the idea of when to release software. It seems like a big setback to a great project to rush something to market and ultimately disappoint consumers.

One of the first thing that comes to mind broken features. I know when we have new ideas, we think about packing them into our releases as soon as possible. I think it’s important to constantly temper those thoughts by making sure that we test, test, test and make sure features are solid.

In the case of the Boxee Box, it promises the moon and leaves a patchwork of unfinished or poorly implemented features. I can’t help but think it would be better adopted with a stable, smaller feature set and a clear roadmap available from management.

I think that’s an important lesson for all of us who release software.

The Windows operating system has been running on mobile devices much longer than iOS: the PocketPC (running Windows CE) I bought 10+ years ago had a 320×200 LCD display, 24-bit colour, and allowed interaction by touch or stylus. There is also Windows POS, Microsoft Sync, Microsoft Surface, and of course PocketPC’s most recent successor: Windows Phone 7. The primary difference in all these variants is not the underlying operating system code, it’s how the user interacts with it.

The same is true for a Windows-based tablet. What’s missing isn’t a rewrite of the Windows operating system, it’s a touch-friendly interface. The Windows 7 operating system already supports multi-touch. In fact it did so in Vista, which was the foundation for the Microsoft Surface platform. The issue is that the current Windows shell, much like its Mac OS X competitor, is geared towards mouse-based interaction. The underlying OS is just fine and is already slated to run on the mobile-friendly ARM processor.

What we need to see, much like the Xbox has done with Kinect, is a new interface that is optimized for how the user is interacting with the device. Microsoft has already proven that they are well aware of this with the new Windows Phone 7 interface, which is a far cry from the Windows Mobile interface it replaced. I would have to agree that it was late to the party, but I can’t argue with the end result.

I know there’s a lot of people that love to hate Windows, but in this case I have to say your criticisms are misplaced. Operating systems are too complicated to re-write from the ground up for each and every device. It’s the reason Mac OS X is now built on Linux, as is Android. Similarly, any device that comes out of Redmond will be based on Windows in some form or another. Speculating about anything else is a waste of time, so let’s wait and see what kind of slick (or not so slick) UI they slap on top…

A Little Clarity

The problem isn’t unique to software development, it’s the constant struggle between art and business. You see it in every industry, but in ours it usually results in products being released to market before they’re ready, developers burnt out trying to meet market-driven deadlines and — drum-roll, please — little time to truly experiment and innovate. I’ve worked on various sizes of projects at various sizes of companies, and I’ve come to the conclusion that it really comes down to the development team manager. I’ve seen that role have many titles, but basically we’re talking about the person sitting between the developers and marketing/business-y types. True, the developer has to take the initiative to make the case for the new technology and why it’s worth looking in to, but it’s the person making the scheduling and resource decisions who can really make the difference in whether it happens or not. Managers need to get better at allocating time for such investigations. They also need to get better at making risk vs. benefit decisions when deciding to invest time in a new approach that could have long-term benefits vs sticking to the status quo which may require less effort now but cause more complications down the road. Finally, they need to be able to effectively communicate up the chain why the work should happen, or down the chain why not.

Sorry Ted, You’re One of Them Now

Having said that, developers today also need to become more business-minded. At the end of the day, it’s the financial success of the product that trumps everything else. We don’t like to hear that, but the financial success of the business is what ensures you can keep working, pay your mortgage, and buy those shiny new phones and gadgets. That means a couple of things:

Firstly, that developers who really want to build a quality product need to focus on one golden rule: build it right the first time. Any time I hear someone say “we can re-write that later” I want to wash their mouth out with soap, slap them, give them a wedgie, and then berate them with “Yo’ Mamma” jokes until they cry. Not gonna happen buddy. If a plumber said they want you to pay them to spend 3 months ripping apart your house to put in shiny new pipes with no real end benefit except the toilet will flush better, would you fork over the cash and delay having them put in the new jacuzzi, or tell them to piss off and put in the damn jacuzzi already? The same is true for developers expecting their companies to let them spend time re-writing a feature that already works because it will be “better” or “more stable”. There’s rarely a compelling business case for re-writing something that already works, so this is generally not going to be the answer for getting your techno-geek fix.

Secondly, the same is true for innovation: you need to make the business case. If you can’t do that then don’t expect your business to pay you to do it. If you truly believe that the new technology will help the product and business then work with your manager to make the case and schedule the time in.

Culture Shock

Let’s face it, some companies just don’t have or want leading edge innovation. It’s why many developers don’t want to work for financial institutions and other verticals where they’re as likely to be running DOS apps talking to a mainframe as anything else. Other times, it’s just lack of awareness. Either way, my own personal rule for unhappiness at work is: have a plan to make things better or have a plan to get out. It’s up to you which one you pick, but I’m a big fan of speaking up and taking initiative. From experience, a lot of other people are fans too. Don’t sit around complaining and expecting other people to make things better, be part of the solution.

There’s a fair chunk of developers who have little to no experience writing multi-threaded applications.  Scarier still are the newcomers who skipped the c++ generation and think the c# “lock” statement is the foundation for all resource synchronization in the windows operating system — yes, I interviewed someone who quite boldly threw that gem out while I did my best not to giggle… While technologies such as WPF make writing Windows programs so much easier in many ways, they also present new and interesting ways to shoot yourself in the foot with threads. I recently updated KidStarter to load Start Menu icons in a background thread to improve the user experience. It seemed pretty straightforward for someone who’s been knee-deep in multi-threading for over a decade now, but I still managed to get tripped up by WPF’s various delay-loading performance optimizations and spent a couple of days debugging the problem.

I’m the last person to discourage people from diving in, getting burnt and learning from the experience. Those are the only people I would ever hire for a job. Just make sure you either do it on your own time or have enough time in your project schedule to absorb the inevitable mistakes and extra bugs Having said that, ParallelFX is a well-designed framework that does a great job of alleviating a lot of the pain in using threads to increase your app’s performance, making better use of system resources, and ultimately providing a better user experience. I look forward to digging into it more (and possibly re-writing my Start Menu code…)

First we’ll create some XAML to show the result:

<Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
  <Image x:Name="theImage" Stretch="Uniform"/>
</Grid>

Then we’ll create the bitmap and assign it to our Image element:

TextBlock tb = new TextBlock();
tb.Text = "My TextBlock";
tb.FontSize = 12;
tb.Foreground = new SolidColorBrush(Colors.Red);
tb.Margin = new Thickness(10);

WriteableBitmap bmp = new WriteableBitmap(tb, null);

this.theImage.Source = bmp;

You should now see the rendered bitmap of the TextBlock on your page when you run your app.

It can happen in many forms: That guy who arranges 5pm meetings because he doesn’t have kids to pick up from daycare; that engineer that derails a meeting for 20 minutes with technical suppositions no one else cares about or is qualified to understand; that friend of a friend who’s been bugging you for weeks to help them on their website then reschedules five times; that client who expects you to react to every request instantaneously, then takes 3 weeks to get back to you when you need info from them; that Chuck E. Cheese cashier who shamefully stands idly by while the prize counter girl takes a 15 minute bathroom break and wide-eyed, eager children stand waiting with hard-won tickets clutched tightly in their little hands, tears slowly welling in their eyes.

Years of experience have proved over and over that these issues cause inefficiencies and erode communication. People who are treated with a lack of respect become resentful of the source, which results in less communication and often unnecessary politics. So what’s the solution?

The first part is obvious: make sure that you are not the one being the douche-bag. If you need to meet with someone, make the effort to change your schedule to accommodate them if needed. Once you’ve agreed on a time, short of a medical emergency or unexpected deportation, keep it. If someone is doing work for you, make sure you respond to their requests in a timely fashion. Remember, their delays are your delays. And for the love of all that is good in the world, if you see a bunch of kids waiting to cash in tickets for candy and fake vampire teeth, walk the 2 feet down the counter and hand out a few toys.

The second part is: speak up. Most people I’ve met avoid confrontation like the plague. I personally avoid it like a plague coupled with really bad gingivitis. We also don’t like to stick our neck out and risk looking like an idiot, even though we’d be saying what everyone else wishes they had the nerve to say themselves. Don’t back down when your manager sends you that ridiculous meeting request, propose a new time that you think would work better. If a client is repeatedly slow in responding to your requests, be honest and say “Hey, this is affecting my ability to finish your project. Can we please discuss this?” If you’re in a meeting that’s taking a side trip to the Caribbean, I find the phrase “can you please take that offline?” cliched but effective. Unfortunately teenagers are immune to reason and angry glares, so you’ll just have to suck it up and wait for your 200 ticket Tootsie Roll.

The premise is that 74% of all businesses still use Windows XP, which isn’t supported by the upcoming IE9. They see this as a prime market then for their Chrome IE Plugin to add HTML5 support.  While they’re absolutely correct that XP is still dominant in that world, the reason for that is the same reason that every web developer’s nightmare — IE6 — is still very much alive and kicking: the cost of updating core software like the OS and browser is prohibitively high. In a large organization, even deploying patches is problematic. A big part of the reason why Microsoft instituted “Patch Tuesday” was to make it easier for corporate customers to plan and schedule patch deployments to their possibly hundreds of thousands of client machines. The potential amount of downtime for end-users (and corresponding IT costs) if an existing application breaks is huge, so any major and sometimes minor changes to users’ computers need to be carefully tested and approved before they’re added to the standard environment. Tossing a browser-within-a-browser plugin into the mix doesn’t really seem like a real bang for my buck just to get a swanky new video tag.

I’m not saying it won’t get used — there’s always that uber-techie IT guy that manages to sneak a few Linux file servers into the mix — but with predictions that enterprises will be deploying Windows 7 on up to 83% of new machines by this time next year, it seems like Google’s niche is already making its way into the ether.

It should come as no surprise then that when I realized 75% of my near 700KB xap file was images, an 8-bit version of Jiminy Cricket materialized on my shoulder and started to sadly shake it’s head. The culprit? Transparent images.

Image Format Primer

There are two primary image formats that have emerged over the years as standard for web and client applications: PNG and JPEG. PNG uses a lossless run-length encoding which makes it ideal for images don’t have a lot of colour variation. JPEG uses a fuzzy algorithm that compresses complex images like photos extremely well, but it’s lossy and causes visible artifacts depending on the compression level and image content. It’s usually pretty straightforward which format you should pick based on the image content, except for one major differentiator: transparency support. PNG has it but JPEG does not.

The Conundrum

I wanted my app to be pretty (because I like apps that look good) so I picked photo-quality images. For example, one of my images was a piece of note paper. The problem arose when I needed the images to have transparency. It was absolutely essential that they have slick drop-shadows and realistic looking edges when displayed on my equally pretty background. The inescapable conclusion was that I’d have to save them as PNG images, which in the case of my note paper resulted in 250KB for the 400×400 image… nearly half of my total application size!

It was at this point that Jiminy started threatening me with nipple clamps and wires connected to car batteries, so I hid in a closet and began to think of possible solutions. It turns out there’s a way to use both image formats for the things they’re good at: JPEG for image compression and PNG for transparency. By splitting the image into a separate content and transparency (alpha) images, I could actually reduce the images in total size by as much as 90%! The key is the UIElement.OpacityMask property.

First Thing’s First

Before we can do our XAML magic we first need to create our images. I like to use Adobe Photoshop, but other drawing packages should provide similar functionality. With your transparent image open, let’s split it into two:

Since it probably doesn’t require any changes, first we’ll create our content JPEG image. The one thing that is important is that the colours in your semi-transparent areas are what you need them to be. The alpha layer image won’t contain any colour information, so you need to tweak the image for that. If you’re using a simple drop-shadow or other effect that all the same colour, the Photoshop “Save for Web and Devices” feature will let you choose a matting colour when you export it (black for a drop-shadow, etc).

Next we need to create a layer that we’ll use to export our PNG transparency image. Right-click on the content layer and choose “Select Pixels”. This will create a selection area that exactly matches the alpha channel for that layer. Remember that PNG compresses best with less colours, so let’s go nuts and create a layer that’s all white. Exciting, huh? Choose “New Layer > Solid Color” and then choose white (or any colour you want) when the picker pops up. Since you had a selection, Photoshop will automatically add a layer mask for you which matches the content layer transparency. Make sure none of the content layers are showing and export the new layer to a PNG file.

You should now have two files which are hopefully smaller than the original PNG you started with. For my note paper graphic, the resulting JPEG image was a mere 20kb and the PNG mask a puny 10kb. That’s a total 220kb size reduction from the single PNG image… an 88% improvement!

XAML Me, Baby

Now on to Silverlight… Now somewhere in your code you should have a brush defined with your old image file:

<ImageBrush x:Key="MyBrush" Stretch="Fill"
    ImageSource="images/original.png"/>

Which we’re going to update and add a new brush to:

<ImageBrush x:Key="MyBrush" Stretch="Fill"
    ImageSource="images/new.jpg"/>

<ImageBrush x:Key="MyOpacityBrush" Stretch="Fill"
    ImageSource="images/new_alpha.png"/>

Now with our brushes added, we can update our UI elements. Here’s simple example using a Grid to simply display the masked image:

<Grid Background="{StaticResource MyBrush}"
  OpacityMask="{StaticResource MyOpacityBrush}"/>

Summary

If you’re using Silverlight for Windows Phone 7 and plan  to use a lot of rich graphics, creative use of OpacityMask is an easy way to lower your storage and memory footprint

The Clique Effect

If you’ve worked at a software company that’s bigger than a couple guys working in a garage, it probably won’t be news to you that the tendency for people to form “us” and “them” peer groups didn’t get beaten out of them in High School. Welcome to Human Nature 101. Whether it’s management vs. code monkeys, developers vs. testers, full-timers vs. interns, or even that smelly guy in the end cubicle vs. everyone else, the typical software company is filled with human division. While these groups may communicate very well within themselves, communication between groups tends to be overly protective and “need to know”. Sometimes there’s a genuine need to protect strategic information, but a lot of times this comes down a form of insecurity (“I’m more important than you because I’m privy to this information and you’re not…”) and just plain comfort level (“I don’t know you or understand your job, so I won’t go out of my way to talk to you”)

Cliquenomics

The thing is that the more information people have, the better they can plan. The better they can plan, the more likely the plan is to succeed. The more likely the plan is to succeed, the better it is for business. By stifling the flow of information, we inherently hobble the ability of the company to plan and therefore succeed. When I work as an architect, I always try to understand not only the immediate requirements of a component, but also what it might need to do in the future. I don’t necessarily intend to implement any of the future functional requirements, but knowing what they might be helps me come up with a design that will allow us to easily plug that stuff in later instead of spending unnecessary time re-writing a huge chunk of code. By knowing more sooner, I can reduce risk and overhead later. The same is true for project planning, and a successful project plan needs everyone’s input.

How Do I Make This Better?

What you’ve got to remember is that the company isn’t about you succeeding, it’s about everyone succeeding. There’s no down-side to stepping outside your comfort zone and making an effort to reach across the human divide. If you help others succeed at their jobs, there’s a pretty darn good chance they’ll a) think you’re awesome and b) go out of their way to help you succeed at yours.

The next time you have a choice between emailing someone or walking downstairs to talk to them, tell yourself you probably need the exercise anyway. Heck, if you work for a software company then the chances that you do are pretty high, and I’m sure your slowly atrophying muscles will thank you for it. Start inviting other groups for lunch and get to know people. Getting to know people socially will grease the communication wheels in the work environment. If you’re having a conference call with a customer about requirements for a feature that you know Developer Dave in Sector 7-G is working on, invite him to sit in. By all means tell him to keep his mouth shut if necessary… sorry, but it’s true that most developers are terrible at talking with customers… but listening to the customer directly will help him understand the requirements better than getting the info second-hand. Without launching on another topic completely, it will also increase their personal investment and feeling of ownership in the feature… which increases morale and productivity… which further reduces risk.

Summary

The key thing to remember is that no matter what role you play in your company, you’re all part of the same team and trying to get to the same finish line. Unless you’ve been led to believe that you’re in an 80′s movie starring Patrick Dempsey or a guy named “Booger”, leave the high school politics and cliques to the cheerleaders and jocks.