To Code or not to Code

I was reminiscing about one of my previous posts, where I was giving advice to a business student, who was trying to make sense of the technical (software) world, and integrate with the technical teams as a product owner. He was under the impression that he had to learn to code to work well with the technical team members. I have a different perspective: the product owner needs to understand some of the subject-matter fundamentals, and understand the high-level implications, but does not need to go deep, such as coding.

In this post, I use 3D graphics as the example subject matter. In 3D graphics, we tend to do some degree of cheating to achieve the necessary run-time performance, and only compute what’s necessary to make the 3D models look aesthetically appropriate. Such cheats may result in robustness issues that would affect your application. The product owner will need to chime in and decide what might be the best set of compromises in order to make good business decisions, but the product owner needs to know about the implications first. Here are a few examples for the product owner to consider from a generic 3D graphics standpoint.

Shadows

If shadows are important in your application, it needs to be understood that shadows rely on the exactness of the 3D model, thus cheats will reveal themselves quite easily when shadows are rendered. One example cheat is bump mapping – it’s a great way to add bump-like features to your model without adding geometric complexity to the model. See the above image (forgive the quality, this was rendered in 1987), where the floor is a just one polygon associated with a bump map. While it is convincing that the floor is bumpy, the shadows (on the floor) from the floating objects reveal that the floor is really just a flat thing. For the graphics expert, you might say “use horizon mapping”, but that does not work because that only solves self-shadowing and won’t affect the above image. Then the graphics expert will say “use relief mapping or displacement mapping”, but that may defeat the run-time performance criteria.  

The product owner does not need to code any of the mapping types. Nor should he need to examine the fascinating vector math equations that make the mapping work. He just needs to understand the implications of the limitations and robustness, to make sound decisions for his product. The best question for the product owner to ask would be something as simple as: how do your algorithms behave with shadows (and show some visual examples)? But ask the question at the beginning of the project, not as a side thought, because shadow calculations may complicate matters quite a bit if not considered early on - my favorite example is "simply" adding shadows to an augmented-reality application that does not even extract the scene's 3D model necessary to compute shadows.

Triangular Meshes

The triangular mesh is the most popular way to represent a 3D model, in which a lot of small triangles (and their vertices) are grouped together to form a 3D shape. In some research publications, the triangular meshes tend to be well behaved – i.e. evenly-sized triangles whose vertices are evenly distributed. But in the real world, 3D models are comprised of unevenly-sized and elongated triangles, especially after it has been modified (sometimes to optimize triangle count to increase performance). When we do simulations or dynamic modifications on the 3D model, some algorithms only apply the modifications to the triangle vertices themselves. When applied to evenly-distributed vertices, the results look good – when applied to the unevenly-sized and elongated triangles, the results simply look awkward.

In this case, the product owner does not need to code anything or understand the physics behind the simulations or dynamic modifications. But he does need to know what implications do unevenly-sized and elongated triangles have on those algorithms. In fact, that is the appropriate question for the product owner to ask.

Quantization

Quantization is the procedure of constraining something from a continuous set of values (such as decimals) to a relatively small discrete set (such as the whole numbers). It is usually done to either simplify the code or gain some performance. When done right, it is glorious, but when done wrong, it is really bad. When the product owner hears the words quantization from the technical team, best thing to do is to insist that the test case includes running the algorithms through a simple animation before declaring victory, because an animation can reveal quantization problems very easily. In some cases, the artifacts are acceptable, but the product owner needs to know about it to make the proper call.

For the graphics expert, a bad quantization example would be a simple line drawing algorithm.  I implemented something that was fast and the image rendering looked great on the screen. But when it came to final production of animated triangles, the triangle motions were not smooth. After some investigation, it turns out there was nothing wrong with the animation code or the line drawing code. It was the quantization of the input coordinates that caused the jumps, because the lines would appear in different pixels if the original decimal coordinates were used.

To Code or not to Code

I don't feel that is the correct question for the product owner. The product owner needs to understand some of the subject-matter fundamentals, and understand the high-level implications, so that he can ask some of the appropriate questions such that good business decisions can be made.