3 ms·

The problem didn't seem to be that C++ was slow to compile but the manager' inability to understand that C++ was slow to compile (i'm ignoring the whole "archit

by Crinus 7y ago

The problem didn't seem to be that C++ was slow to compile but the manager' inability to understand that C++ was slow to compile (i'm ignoring the whole "architecture astronaut" and "untestable code" angle because it relies on the author's ability to judge that and from my experience people need a lot of time to become familiar with non-trivial C++ codebases and way more often than not they blame the codebase itself and whoever wrote it for that). Considering the project folded it might also have been a sign of bigger issues with management there.

acqq 7y ago
What you ignore is: "It was managed by an architecture astronaut that, as one is wont to do, rewrote existing mature libraries as header only template libraries that were buggy and untested (one could even say untestable)." I'd like here to quote this: https://blogs.msdn.microsoft.com/ricom/2007/02/08/performance-problems-survery-results/ https://blogs.msdn.microsoft.com/ricom/2007/02/08/performanc... "Which of the following is more likely the culprit of this crisis that has your boss in a panic: 1) A developer failed to code a good algorithm in some module and now a very smart person must come along and replace that module with something much better. 2) The project has far too many layers of abstraction and all that nice readable code turns out to be worthless crap that never had any hope of meeting the goals much less being worth maintaining over time." "Of 27 responses at this writing 8 didn't specify #1 or #2 at all or were balanced 4 went clearly for #1 15 went clearly for #2" I've had my own experiences of #2 on different occasions (I work for decades already).
- Crinus 7y ago
  Yes, without having enough information to judge for themselves people tend to assume the worst. This applies to both the poll you linked and to people coming head first to a new complex codebase they have no idea about (yet need to learn fast due to boss pressure).
  - deleted 7y ago
    [deleted]
  - acqq 7y ago
    My experiences do confirm that there are developments which are indeed “worthless crap that never had any hope of meeting the goals much less being worth maintaining over time.“ There is a real problem of making unnecessary and long-term bad abstractions, and there is a lot of such often in the code using Boost, as an example.

by Crinus 7y ago

acqq 7y ago

What you ignore is: "It was managed by an architecture astronaut that, as one is wont to do, rewrote existing mature libraries as header only template libraries that were buggy and untested (one could even say untestable)." I'd like here to quote this: https://blogs.msdn.microsoft.com/ricom/2007/02/08/performance-problems-survery-results/ https://blogs.msdn.microsoft.com/ricom/2007/02/08/performanc... "Which of the following is more likely the culprit of this crisis that has your boss in a panic: 1) A developer failed to code a good algorithm in some module and now a very smart person must come along and replace that module with something much better. 2) The project has far too many layers of abstraction and all that nice readable code turns out to be worthless crap that never had any hope of meeting the goals much less being worth maintaining over time." "Of 27 responses at this writing 8 didn't specify #1 or #2 at all or were balanced 4 went clearly for #1 15 went clearly for #2" I've had my own experiences of #2 on different occasions (I work for decades already).

Crinus 7y ago
Yes, without having enough information to judge for themselves people tend to assume the worst. This applies to both the poll you linked and to people coming head first to a new complex codebase they have no idea about (yet need to learn fast due to boss pressure).
- deleted 7y ago
  [deleted]
- acqq 7y ago
  My experiences do confirm that there are developments which are indeed “worthless crap that never had any hope of meeting the goals much less being worth maintaining over time.“ There is a real problem of making unnecessary and long-term bad abstractions, and there is a lot of such often in the code using Boost, as an example.