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.

Advertisements

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.