#begin
The next section of the chapter is about solving seemingly impossible requirements. I think we’ve all faced such requirements before. What do we do when we’re asked to implement a requirement that’s impossible to implement due to current software architecture, technology or maybe a lack of knowledge. Sometimes all it takes is to think outside the box, but that can be really difficult. The solution sometimes just lies elsewhere.
The ‘think outside the box’ argument encourages you to think about the constraints that might not be applicable to the problem and ignore them. David and Andrew also say the following: “But this phrase isn’t entirely accurate. If the “box” is the boundary of constraints and conditions, then the trick is to find the box, which may be considerably larger than you think.” You must be able to challenge preconceived notions and identify constraints. When you have identified them, evaluate whether they are real constraints.
When you found some intractable problem you really have to enumerate all the possible avenues and don’t dismiss anything. Even if they sound really stupid, consider them. They might just open up your mind to the best solution out there. This is also something Prof. Ousterhout predicates in his book: A Philosophy of Software Design. He thought us to design it twice, or trice. Design two or more radically different solutions and then take the best parts from each to come up with the most optimal design. Weight the different strengths and weaknesses and see how they fit within the given constraints. You might just find that some constraints don’t seem to apply to a given solution.
David and Andrew then mention the following: “Categorize and prioritize your constraints. When woodworkers begin a project, they cut the longest pieces first, then cut the smaller pieces out of the remaining wood. In the same manner, we want to identify the most restrictive constraints first, and fit the remaining constraints within them.”
There Must Be an Easier Way!
Another common problem in software engineering is finding out that a problem you are trying to solve is much harder than you expected. This also relates to the problems we face while estimating features or bug fixes for example. Sometimes it might feel like you are going down the wrong path and there must be an easier way than the path you are currently traveling. Some paths might indeed be impossible to travel, yet taking a different one might get you to your destination. David and Andrew list a couple of questions you can ask yourself:
- Is there an easier way?
- Are you trying to solve the right problem, or have you been distracted by a peripheral technicality?
- Why is this thing a problem?
- What is it that’s making it so hard to solve?
- Does it have to be done this way?
- Does it have to be done at all?
I think these are indeed some great questions to ask yourself, especially the second one: Are you trying the solve the right problem, or have you been distracted by a peripheral technicality? I think this is the one we often get slapped in the face with. How often have you found yourself solving a problem that doesn’t really exist? Sometimes when you ask a colleague for a second opinion you might find that a different approach eliminates the problem you are facing altogether. But a different approach might introduce new problems, which is a realistic thing that will happen. However, different approaches have different trade-offs and thus might be easier to manage. Let me give you an example of what I encountered recently.
At work I needed to implement a requirement that our application can run properly on a multi-display or cluster setup. This required some interesting refactoring to be done in regards to rendering, caching and also UI. The camera setup in Unity we are using is quite custom where we manipulate the matrices ‘manually” to render the exact view we want. We also manipulate the projection matrix of the camera to move the center of the viewport to create obliques of the view. Now, when I was implementing the UI I thought that for each camera, I’ll just use a Canvas with ScreenSpace – Camera type, a ScreenSpace – Overlay canvas will not work since we might have multiple camera’s rendering to the same screen. But yeah, surprisingly, the obliqueness does not impact the Canvas and thus all the UI is in the wrong place. I think this is a bug in Unity3D because it should be oblique too. So I thought lets opt for a WorldSpace canvas but then I hit another problem where any manipulations to the field of view will screw up the UI. So what do I do? I asked a colleague for a second opinion and he came the the simplest idea I did think about yet. Let’s add a second camera, only render the UI and add it to the main camera stack as an overlay camera. Derp! I mean, I’ve done this trick a million times in VR apps, but I totally missed it here. This simple change in approach removed the weird constraints I imposed on myself to render the UI. This is far more elegant, simple and easy to manage and maintain. Great!
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments