Month: April 2011

How Long Will It Take To…

As a developer I have heard this a million times, and my response is – I don’t know. Anyone who claims they can estimate with any kind of accuracy how any feature or fix will take is a liar. Flat out. No exceptions.

From a managerial standpoint the ONLY budget that can possibly work is this. “You have 10 days to implement X, let’s see what you can do”. And this is where management needs to understand the dynamics of software development, and understand it well.

Imagine you ask a painter “how long will it take you to paint this wall”. Some might say 10 minutes, others might say a full day.

Quick Development
This didn't take long

The manager did not expect this. In his mind, “painting” means something more than just splattering color on the wall. But here is a question for the managerially inclined out there. If you go back to the painter who gave you the long estimate, do you think his estimate is going to change. To some folks, since the work is half done – the “slow” painter should be able to do it in half the time now!!! right??

Here’s another dimension you need to consider. The painters have painted hundreds of walls, they know that some walls are even and easy to paint, others are crooked and dimpled and need more work. But why not ask the guy who painted your house how long it will take him to give your new Porsche a new coat of paint? Its pretty much the same thing – right? For the house-painter to give you a good estimate, he would need to KNOW how to paint a car, and to know it, he’d need to do it. And when he has done it, do you need the estimate?

The world is full of idiots who think they can estimate the time it will take to do something that is as vaguely defined as it is when people ask about features for software. To them, the answer “I don’t know” is a sign of incompetence, when in reality – that question is the hallmark of incompetence. Clearly, laymen will ask these things, and we’ll be happy to give them a ballpark number, but it always comes with a disclaimer, and most end users understand this. But if you work in the business, you should not keep asking for estimates every day, and then make a business plan based on those estimates.

H.264 vs JPEG Redux

Oh, don’t we all enjoy labeling things? There’s reassuring to be found in the idea that A is better than B. No disclaimers, no gray areas. Just pure and simple… “Better”.

One of the best things about the good old JPEG is that it is fairly simple to fit the video to the recipient device in real time. Imagine that we have a few 5 MP H.264 cameras in our system. 99% of the time, the video is placed on disk, never to be looked at. So 99% of the time, JPEG is worse than H.264 (apples to apples, H.264 is better but sometimes you crave oranges). If the client always connects via a fast connection, and always has good resolution on his device, then fine; stay with H.264, but what if sometimes you connect via a low-res device (phone), or have low bandwidth (phone and ADSL)?

Mindlessly streaming H.264 over a low bandwidth connection will be a horrific experience. You can’t use YouTube as a reference, because YouTube is playing back recorded video and thus the latency can be extremely high. The problem with H.264 is that you need ALL the bits and pieces, otherwise the quality will degrade and you will experience “ghosting”, so if the server has a 10 MB GOP, containing 2 seconds of video, then you need to wait until you get the whole thing, which could take a while. Then you need to decode the first frame of the GOP, which gives you a 1920×1080 frame. This frame is then brutally scaled down to 640×480. Assume that it takes 10 seconds to process the entire 2 second GOP (sending, decoding and scaling), now you are already 8 seconds behind real time, so we need to skip ahead 4 GOPs to avoid the latency building up, making the video look very, very strange.

To resolve this, the NVR must support multiple streaming profiles, which means that the camera must support them too, or alternatively, the NVR must be able to transcode the video on the fly, while not jeopardizing the recording. And – by the way – all of this tweaking and turning knobs is to be done by someone who is already struggling with a fairly complex piece of kit.

Transcoding H.264 to H.264 is an expensive proposition (the encoding bit). It can be done, for sure, but it will come at the cost of other features in the app as development resources are directed towards solving this particular problem. Transcoding H.264 to MJPEG is much more flexible, and since MJPEG is supported on a wide range of browsers making it fairly simple to create a mobile app.

Sure, with infinite development resources, we could do everything, but lets stay within the realms of reality.

As a little commercial plug, here’s a small test i did with some video hooks in Heimdall.

LinkedIn Recommendations?

I suppose most people start thinking about getting recommendations when they are about to leave their current job. It should be a flag for any manager when an employees LinkedIn profile starts getting a lot of recommendations in a very short timespan. I am almost certain that if you look at LinkedIn’s statistics you will see a high degree of correlation between “recommendation frequency” and job changes.

I don’t care much for these recommendations. To me they have zero value; instead I prefer looking at a portfolio of products. I once hired a guy who brought a folder with screenshots from the apps he’d made in his spare time. Turns out the guy was one of the best programmers I ever met, and more importantly – because he had such talent, he did not need me, or anyone else, to write a blurb stating that he had talent on his LinkedIn profile when he wanted to leave. It is obvious if you have real talent, and fairly obvious if you do not.

While we sometimes stumble across a diamond in the rough, it makes a lot more sense to me to pick diamonds from a barrel of diamonds. I have a really hard time understanding why you want to pick up sailors that ran their ship aground; while they now have “experience”, they also proved that they were poor sailors. When you pick a crew, do you pick a drunk from a a ship hardly seaworthy, imagining that he is just a victim of the circumstances, or do you pick one from the pristine vessel that is the envy of every other sailor on the dock?

 

Too Many Cooks Spoil the Broth

Did you ever watch “Kitchen Nightmares”?

There’s something exciting about seeing Gordon Ramsey walk into a crazy dysfunctional restaurant and in a matter of weeks put the establishment back on track. Gordon Ramsey is a sort of restaurant Guru; as far as I can tell, he knows his shit. Not only does he know how to cook, but he also identifies the underlying management problems that usually plague these places.

It is tempting to believe that the world is full of Gordon Ramsey’s in all kinds of different areas. Truth is, there aren’t that many around, and when you bring in a buffoon, who fancies himself to be another Gordon Ramsey, things quickly go to hell in a hand-basket. Oftentimes, management wants to believe that this guy is going to be the white knight, who (magically) puts things back on track.

But to the team, the ones who cut the carrots, fry the chicken and prepare the desserts, it is just another chef and just another opinion, another way to cook the salmon, and another 4 items on the menu. When there are 50 items on the menu, it is hard for a small team to cook all 50 to perfection. Instead, you have NO dishes that are prepared well. Adding another 4 or 5 items to the menu is not going to change that. When people are prevented from doing a good job (because they need to know 50 dishes), they become disgruntled, and I doubt there is anything worse for a restaurant than a disgruntled kitchen team.

Imagine if Gordon Ramsey was a horrible chef, and had a long string of terrible failed restaurants behind him. Do you think the show would be worth watching? Would the kitchen staff have any respect for the new chefs advice?

I doubt it.