这也是我个人的疑问，同时也是时常出现在我身上的问题。之前在做团队比赛的时候时常会因为自己的独特的想法干扰到队友，甚至会因此导致比赛的失利。
在书p65页的讨论中有提到当代码量与成长的关系。我有所疑问的是，倘若在项目上遇到自己不会学的已封装好的库，例如在sk-learn库中早已封装好各类机器学习的库，但只会调用库无法提高自己对于知识方面的进一步了解，但去彻底的了解源代码耗费的时间与得到的收获并不成正比，如何平衡这一方面的矛盾呢？
书p53页中阐述了过于细致的深究每个问题导致在项目上一开始就困难重重无法进行。那么一个项目想要正确的进行是应当只要求大方向正确接着慢慢去分小方向交接给不同的人去做吗？还是应当不求甚解，从头开始慢慢探索呢？
软件开发是一门工程，是一门艺术，还是一门手艺？
我看了邹欣老师的博客园讲义中有关创新的章节，那么如何持续创新呢？
如何在用户体验方面创新呢？
如何进行软件设计？
测试要达到什么样的目标才能算通过？
如何得出程序员在工作中的贡献值？
在实际开发中要如何权衡的软件质量成本？
当测试人员与开发人员产生冲突时，如何让他们摒弃前嫌更好的协作呢？
当有两个团队邀请你，一个是较好的团队但工作风格与自己差异较大，一个一般团队但工作风格相似，应如何选择？
小强地狱部分，提到“阈值不宜频繁调整，最好事先宣布阈值”，这要怎么尽量一次性做到？此处阈值指的是bug数量的界限，如果开发人员“入狱”的比例过高，说明了阈值设置或者bug计算不合理，需要调整。我的想法是，假设在bug计算合理的条件下，阈值设置直接按照书上所说的5%-30%设置，还会不会出现不合理的情况，仍需要调整？如果仍然需要调整，那么多次调整会不会带来开发效率下降等不利影响？（可能多次调整才会趋近于合理）
CMMI是如何运行到实际的软件质量保障方面的？
如何把握好”灵光一闪“的机会？既然IT行业需要站在前人的肩膀上才会创新，那么就算“站在前人的肩膀上”，要怎样才能像牛顿、阿基米德等人把握好“灵光一闪”的机会？这个问题不是很明白。
书中提到了两种电脑键盘布局，两种键盘就其效率而言，更高效的那种反而不是我们日常使用的键盘样式。好的想法不一定赢，但是好的想法和成功的关系是完全意义上的必要不充分条件吗？查阅了相关资料，发现清一色的都是“有想法就去做，去尝试，想赢但也不怕输”的类似观点。也可以说，好的想法出现是想赢，但不一定会赢。那么虽然还提到了“提出一个创新的想法时需要考虑的问题”，对照一下本案例，仅仅是与大众习惯不符，为什么就输了呢？我认为这些问题仍然不是很理解。还有，如果是必要不充分条件，那为什么还要鼓励大家有更多的想法，而某些人有好多好的想法却没有赢，阻碍其他更多想法出现，自相矛盾？
如何平衡大量收入但在减少的软件产品和没赚钱但用户量上升很快的软件产品之间的投入。
效能过剩是否也暗示了另一种效能不足？效能过剩大概指的就是一个技术达到了持续阶段以后，他的效能已经远远满足大部分用户的需求，就会出现效能过剩的问题，例如书中举得U盘的例子：
2013年打算购买2GB的U盘（需求仅有2GB），但是市面上的U盘都是4GB以上的（效能4GB以上）
这里就是U盘储存空间的效能过剩，但是如果我开发一种快速的读取方法，使用空间换时间的策略（计算机很多优化都可以遵循空间换时间和时间换空间的策略），把原本2GB的文件，额外加上1GB的驱动文件来加速读取，并把这部分内容附在U盘的空间中，那么就可以得到一个3GB空间大小的快速读取的U盘，缓解了存储空间上的效能过剩，也提高了读取速度上的效能。这种情况下，是不是就证明在其他方面（如此处的读取速度）存在着效能不足，可以同时改进二者。