Mark C^ot'e has published a "vision for engineering workflow at Mozilla": part 2, part 3. It sounds really good. These are its points:

• Checking out the full mozilla-central source is fast
• Source code and history is easily navigable
• Installing a development environment is fast and easy
• Building is fast
• Reviews are straightforward and streamlined
• Code is landed automatically
• Bug handling is easy, fast, and friendly
• Metrics are comprehensive, discoverable, and understandable
• Information on “code flow” is clear and discoverable

Consider also Gitlab's advertised features:

• Regardless of your process, GitLab provides powerful planning tools to keep everyone synchronized.
• Create, view, and manage code and project data through powerful branching tools.
• Keep strict quality standards for production code with automatic testing and reporting.
• Deploy quickly at massive scale with integrated Docker Container Registry.
• GitLab's integrated CI/CD allows you to ship code quickly, be it on one - or one thousand servers.
• Configure your applications and infrastructure.
• Automatically monitor metrics so you know how any change in code impacts your production environment.
• Security capabilities, integrated into your development lifecycle.

One thing developers spend a lot of time on is completely absent from both of these lists: debugging! Gitlab doesn't even list anything debugging-related in its missing features. Why isn't debugging treated as worthy of attention? I genuinely don't know — I'd like to hear your theories!

One of my theories is that debugging is ignored because people working on these systems aren't aware of anything they could do to improve it. "If there's no solution, there's no problem." With Pernosco we need to raise awareness that progress is possible and therefore debugging does demand investment. Not only is progress possible, but debugging solutions can deeply integrate into the increasingly cloud-based development workflows described above.

Another of my theories is that many developers have abandoned interactive debuggers because they're a very poor fit for many debugging problems (e.g. multiprocess, time-sensitive and remote workloads — especially cloud and mobile applications). Record-and-replay debugging solves most of those problems, but perhaps people who have stopped using a class of tools altogether stop looking for better tools in the class. Perhaps people equate "debugging" with "using an interactive debugger", so when trapped in "add logging, build, deploy, analyze logs" cycles they look for ways to improve those steps, but not for tools to short-circuit the process. Update This HN comment is a great example of the attitude that if you're not using a debugger, you're not debugging.

http://robert.ocallahan.org/2018/07/why-isnt-debugging-treated-as-first.html