Stroustroup despre C++:
I think I know more about the problems with C++ than just about anyone,
but I also know how to avoid them and how to use C++’s strengths.
(Exact ce obisnuiesc sa spun si eu despre VB 😉 )
Despre programare la MS
When investigating a piece of code the developer first turns to the code itself: on average
respondents to the survey spent 42% of the time examining the source code, 20% using the
debugger, 16% examining check-in comments or version diffs, 9% examining the results, 8%
using debug or trace statements, and 5% using other means. In other words, the code itself is the
best source of information about the code. However it is not flawless. It is common for
developers to become disoriented in source code, and it is often difficult to discern the
relationships between observed behavior and the source code.
When the code itself does not give the answers the developer needs, one might expect them to
turn next to the vast amount of information that’s written about it – the bug reports, the specs, the design documents, the emails, etc. This however is emphatically not the case.
The second recourse for investigating the rationale behind code is in fact the social network. If
the developer thinks that someone within his team might be able to provide the needed
information (or the name of the person who might), he will walk down the hall to talk with the
teammate. Unplanned, face-to-face meetings happen frequently with teammates, averaging 8.4 in
the prior week, and much less frequently with non-teammates, averaging 2.6. Email is used
instead of face-to-face meetings when the issue is low priority, involves multiple people, or
crosses the team moat, averaging 16.1 sent to teammates in the prior week and 5.9 to nonteammates.
(Note that these data show that communication within the team is much more
common than communication across teams, indicating that the culture of informal communication
works well and that the team boundaries are typically drawn in the right places.)
Once the developer has the desired information, he returns to his office, applies the newfound
information, and gets on with his work. This information is precious: it is demonstrably useful,
demonstrably hard to ascertain from the code, and was obtained at a high cost. Yet it is
exceedingly rare for the developer to write this morsel down anywhere. The next person who encounters the same information need has to go through the same laborious discovery process. There are plenty of reasons that a developer would choose to not record the information – the overhead of checking the code out, editing it, and checking it back in (possibly triggering checkin review processes, merge conflicts, test suite runs, etc.) is enough to dissuade the developer from recording the information as a comment in the code. But the loss of this precious knowledge is, from an organizational perspective, a crying shame.
De ce am impresia ca asta se intimpla peste tot? Doar ca am intilnit-o si eu ?…