Engineering Tools Handbook

Tools Functional decomposition Wishful thinking Reframing (reconsidering the problem) Research Pugh charts Comparison matrix Teamwork Meetings Unperformant team members Team atmosphere Parallel tasks

toggle TOC (ctrl + ⇔)

Collected here are my assessment and guideline on technical tools and teamwork strategies. Each tool will be analyzed as to what they're suited for and when to use them, and when they're not useful is discussed, and the tool is assigned a general usefulness score based on the range of situations the tool would be helpful in.

Teamwork strategies examine aspects of teamwork and potential causes of problems inside each and how they can be dealt with.

Technical Tools

-------------------------
These are the tools I use to solve the right problem and solve the problem right. To solve the right problem, research and reframing has to be done to refine a better understanding of what the actual problem is. And to solve the problem right, the other tools allow me to create a modular solution whose components can be easily interchanged. I believe this to be more important than having a perfect monolithic solution since a modular design is adaptable to a changing environment and can be made better through iteration and alteration of parts.
###Functional decomposition
  • use in almost every situation
  • breaks problem into (mostly) independent subproblems
  • encourages modular treatment of problem
  • facilitates parallel task distribution
  • easier to focus on specific part of problem
  • forces consideration of what the actual problem is </ul> </div>
    • approximates problem since in reality all parts are interdependent
    • difficulty in combining component solutions to subproblems </div>
      9/10
      </div>
      • division of portfolio into styling (CSS), content (markdown/HTML),
        layout (HTML/Jekyll templating), and hosting (GithubPages)
      • division of causes of binder misalignment [1] into blunt trauma, misuse, and misplacement
      • division of the problem of meat refrigeration without grid electricity [2] into insulation, radiation protection from the sun, initial cooling, and meat storage
      • division of web development by the Django framework into models, views, and templates (MVC pattern) as used in the creation of timewatch </ul> </div>
        </div> </div>
        ###Wishful thinking
        • best used in software and other idealized situations
        • isolate consideration for use and implementation
        • creates layers of abstraction to manage complexity
        • works well with functional decomposition </ul> </div>
          • assumes that implementation is in place
          • assumptions break down in real life due to physical laws </ul> </div>
            7/10
            </div>
            • any component solution following functional decomposition assumes other parts of the problem are taken care of
            • any kind of recursive procedure assumes itself is already implemented
            • most procedures I write operate only on 1 implementation level, calling lower level procedures that I assume are implemented </ul> </div>
              </div> </div>
              ###Reframing problem
              • use when given a foreign problem by others
              • form personal understanding of problem through research and experimentation
              • promotes solving the right problem
              • results in finding easy to measure and relevant metrics </ul> </div>
                • very time consuming
                • weakness in research and experimentation would give flawed new frame </ul> </div>
                  7/10
                  </div>
                  • understanding the problem of binder misaligment [1] as the separate and related issue of shift misalignment and yield misalignment, sharing some common causes
                  • selecting for a food safe material [3] reframed to selecting for a corrosive resistent and easy to clean material, further reframed to selecting for smoothness and hardness
                  • injection of modularity and robustness into all of my projects, such as the ICE-Cube [2] and the design of this handbook </ul> </div>
                    </div> </div>
                    ###Research
                    • use in almost every situation
                    • helps understand the problem
                    • research accumulates and can be easily reused </ul> </div>
                      • very time consuming
                      • usefulness of research not guaranteed </ul> </div>
                        6/10
                        </div>
                        • survey used to understand the problem of binder misalignment
                        • contacting stakeholders in the headset and glasses RFP [4] and meat refrigeration without grid electricity for first-hand experience with the problem
                        • often found ways to improve value of solution --> ICE-Cube combines function of display and storage, an advantage over existing coolers which only store meat </ul> </div>
                          </div> </div>
                          ###Pugh charts
                          • use sparingly in the compare and select stage
                          • compares technical performance
                          • formalizes decision making </ul> </div>
                            • very difficult to remove bias in score assignment
                            • requires large number of diverse combinations/candidate solutions
                            • tedious and formal work that could damage team atmosphere </ul> </div>
                              4/10
                              </div>
                              • informally done for choosing portfolio setup in comparing against Wix, Wordpress, and Weebly
                              • comparison of food-safe materials (Table 2) </ul> </div>
                                </div> </div>
                                ###Comparison matrix
                                • use in the compare and select stage
                                • bias is not a problem (actually drives selection)
                                • quick and easy
                                • compares holistic appeal (usually more aesthetics based)
                                • use with pugh charts to see which combinations are technically performant and which are appealing
                                • used in combination can reveal the reasons behind a combination's performance or appeal </ul> </div>
                                  • requires large number of diverse candidates
                                  • depends on use of formal performance comparison (such as a pugh chart) to be more effective </ul> </div>
                                    6/10
                                    </div>
                                    • informally done for each project, immediately after brainstorming diverse ideas
                                    • disagreements add value to solution since they lead to more detailed research to back up claim, such as my justifications for maintaining a cubic dimension for the ICE-Cube </ul> </div>
                                      </div> </div>

                                      Teamwork Strategies

                                      -------------------------
                                      These are the aspects of that are likely to cause problems. For each I will examine the

                                      causes

                                      and

                                      remedies

                                      . The top box will cover causes while the bottom box covers remedies.
                                      ###Meetings
                                      • meetings without a clear purpose lead to unproductive time spent together, fostering animosity between teammates and a hostile atmosphere
                                      • meetings were too frequent, leading to members skipping
                                      • members relied on meeting time to do their work
                                      • all these cripple a team's ability to do parallel work, making a team pointless </ul> </div>
                                        • make clear that meeting time is only to distribute work rather than do it
                                        • make a simple checklist of things to accomplish at each meeting (be realistic)
                                        • only hold full meetings at critical points
                                          1. first contact, establish expectations and distribute tasks
                                          2. decide on which solution to prototype
                                          3. before presentation
                                          4. decide on major alteration </ol>
                                          5. allow room for asynchronous decision making (via facebook group or google docs), rather than requiring everyone to be present for all decisions </ul> </div> </div> ###Unperformant Team Members
                                            • different expectations from the start on what is a good job
                                            • not assigning tasks to members' strengths or giving them minor tasks that demonstrate your lack of trust
                                            • hostile team environment
                                            • communication issues and incompetence </ul> </div>
                                              • use the first meeting to set up expectations
                                              • take a chance with new teammates by trusting them to important tasks
                                              • maintain friendly atmosphere by keeping meetings infrequent and informal, as well as making personal connections
                                              • problem should resolve itself since reputation has a natural feedback cycle --> hardworkers will develop a hardworking reputation and will more likely select other hardworkers as future teammates while freeloaders become publicly known and are avoided
                                              • only way in dealing with current unperformant team is to take up more work yourself </ul> </div> </div> ###Team Atmosphere
                                                • depends on
                                                  1. frequency and formality of meetings
                                                  2. past success
                                                  3. personal interactions </ol>
                                                  4. best established during first meeting
                                                  5. upkeeping is much easier than changing it </ul> </div>
                                                    • hold full meetings only when necessary
                                                    • keep communication fluid (ex. facebook group, google docs) rather than static (only at meetings, either skype or in person)
                                                    • avoid working with previous unperformant members
                                                    • fix up bad social habits (ex. always being skeptical of others' ideas) </ul> </div> </div> ###Parallel Tasks
                                                      • purpose of team is to accomplish a large task faster and better by division of tasks
                                                      • serializing tasks indicate failing team
                                                      • team relies on meetings to get work done
                                                      • distribution of dependent tasks </ul> </div>
                                                        • use functional decomposition at each step to create independent subproblems
                                                        • visually render tasks, either informally or formally through a Gantt chart </ul> </div> </div>

                                                          References

                                                          -------------------------
                                                          [1] S. Zhong et al., "Shield Spring: Binder Misalignment," University of Toronto, Jan. 1, 2014.
                                                          [2] S. Zhong, K. Cota, E. Yang, and J. Zabala, "ICE-Cube: Meat Refrigeration Without Electricity," University of Toronto, April 12, 2014.
                                                          [3] S. Zhong, "Food-Safe Material Selection for Aerator," University of Toronto, Feb. 17, 2014.
                                                          [4] S. Zhong, K. Cota, E. Yang, and J. Zabala, "Request for Proposal: Reducing the Discomfort of Wearing Headsets with Glasses for Toronto Police Communication Operators," University of Toronto, Feb. 17, 2014.
                                                          </div>