Chapter 5 – Manage the Power of Machine Learning and Deep Learning

1. TensorBoard is simply a nice displaying program. (Yes | No)

The answer is yes and no. Yes, TensorBoard is a friendly interface for visualizing a dataflow graph. No, TensorBoard is not only nice but is also critical to designing the architecture of a project even before the data feed aspect of the program is written. In real-life projects, a good architecture shows that you can manage the power of ML/DL programs. 

2. Defining functions at the beginning of the source code is just like standard programs. (Yes | No)

No. Seeing variables and arrays at the beginning of a TensorFlow program could lead one to think that it is just a formality. However, these lines are in fact the real program, the dataflow graph, the architecture.  

3. TensorFlow is a library add-on to Python that provides some cool functions. (Yes | No)

The answer is no. It is a strategic tool for designing the dataflow graph of an application.

4. TensorBoard is not necessary to deploy machine learning and deep learning programs. (Yes | No)

The answer is yes. TensorBoard refreshes every n seconds automatically (this can be deactivated). When running large datasets during the training process, it is crucial to see whether the cost function is going up or down. And even if it is going down, converging to 0 or near 0, it is vital to see how fast the slope (gradient) is decreasing (descent).

5. As long as we're technical experts, we don't have to worry about our environment. It will adapt. (Yes | No)

The answer is no. Those days are over. Our environment decides whether our project will survive or not. It is critical to developing not only code but also communication skills to defend ongoing projects.

6. Presenting ML/DL projects doesn't change the architecture of a solution. (Yes | No)

The answer is no. If the presentation has been well defined and made to the right people, the architecture can be tremendously improved by optimizing the datasets, training phase, test phase, and expected results.

7. Managers don't need to understand the technical aspect of a solution as long as it works. (Yes | No)

The answer is no. This is a myth. It works early in a project, or in a dream world where projects never go wrong. But large projects always go wrong at some point because of dataset problems, bugs, communication tensions, sick leave, vacations, budget limitations, and scores of unexpected events. When that happens, communicating the key points and reasons of every aspect of the problem becomes essential.