To succeed, define constraints

Every time a client contacts me for a new project, one of the first thing I do is to determine the constraints. I’m not talking about the cost vs time vs quality of project management triangle here, but rather the definition of what the client really wants and whether he’s asking for the impossible.

I’m working in computer vision (I prefer this term to “image processing” as the later is often mistaken with Photoshop kind of work, which I’m not doing at all) and most client don’t know nor understand what I can do and what I can’t do. For example, one of them was recently asking me to develop a custom OCR (Optical Character Recognition) for pictures taken with different smart phones. What looked like a huge and complicated project, I don’t have control over the pictures the users will take, was simplified a lot by exchanging with the client to understand how its users would use the software. It appeared that the pictures would actually be always of the same type of object. This was good news for many reasons. Knowing this helps me define how the images will be analyzed and what will be the constants in the equation. In computer vision terms, this means that the text will only use one font, it will be horizontal as much as possible (dealing with rotated text is not impossible but it slows down the whole process), the background will always be of the same color.

By defining these constraints, I can allow my software to behave incoherently when fed with pictures which to not respect the constraints. The product is not used in life saving situations, so no harm will happen anyways. Even with these constraints set, I still had to deal with less-than-perfect image quality (bad lighting, small fonts unreadable even for humans, text not entirely in image) so having constraints does not mean the job will be easy.