At a conference some years ago a group of us developed an analogy for software development over a series of lunchtime conversations. (I won't mention names as my memory is sufficiently vague as to who participated in these conversations and who was simply around at the time.) The analogy was with the preparation of food. The circumstances under which software is developed vary from "fast food" to "gourmet" - and the way it is developed differs just as much. At the time the point of these discussions and the building of this analogy was a discussion of the differences between types of developer and the way in which they approach their work.
One of the points we explored was that the approach to developing software reflected the context in which the developers work. There is a place in the world for quickly developed "burger and fries" software - I occasionally write throwaway scripts to munge data from one format to another or to generate test data. This type of software is effective in meeting the immediate needs of the business, but achieves this with potentially poor error detection and handling, or with performance characteristics that scale poorly, and is written with no thought to reuse or maintenance. Also, it is all too common for such software to be unusable without the author on hand to deal with odd behaviour. There is, of course, a medium to long term cost of this sort of diet. Since this conversation Morgan Spurlock shot to fame with his demonstration of this in the context of food: "Supersize Me". (And a similar problem arises when organisations clog up their arteries with this sort of software.)
For the more discerning organisation there is a requirement for developers to craft something that can be used without the author standing by to fix problems if they occur, or that may be maintained over a long period of time, or used in a variety of contexts, or meets stringent performance characteristics. Different skills come into play when writing such software. A lot more care with the preparation of the ingredients, a different set of tools and a lot more thought. But the results are worth the effort: a diet of quality software base makes for a fitter and happier organisation.
One of the things that we were considering was the mismatch that occurs if a developer accustomed to working in one way encounters a situation that required the other approach. We can all imagine the consequence of swapping the kitchen staff of a burger chain with those from a good restaurant. (I hope I've not just invented another theme for "reality TV".) When this happens the frustration of all involved in such situations will be obvious - even if the true causes are not. All too often the incompetence is assumed where a failure to communicate what is needed is the cause.
During these conversations we also examined the role that tools played in the analogy - are great tools required to produce great software? Or can bad software be avoided by the use of good tools? It was my contention that it is the skills that matter: a top class chef would be able to produce good quality food even when separated from their kitchen. On the other hand, if separated from the freezer full of frozen burgers the results would not be so good for the McDonald's kitchen staff. The killing argument against this however was that "a real chef would not be separated from his knives".
These conversations - especially the usefulness of potentially dangerous tools to an expert in the craft - came to mind recently. I was reading the reactions of a group of C++ experts to the recent discovery that a vendor plans to ship an implementation of C++ that produces messages like the following:
c:\program files\microsoft visual studio 8\vc\include\algorithm(637) : warning C4996: 'std::swap_ranges' was declared deprecated c:\program files\microsoft visual studio 8\vc\include\algorithm (625) : see declaration of 'std:: swap_ranges' Message: 'You have used a std:: construct that is not safe. See documentation on how to use the Safe Standard C++ Library' ...
This discussion was the first I'd heard of the "Safe Standard C++ Library" - which is a bit surprising as for some years I've been involved with both the BSI and ISO working groups that define the standard C++ library. And, as it was the latter group who were discussing this development, I'm pretty sure most of the rest of them did not know about it either. We were also surprised to see the term "deprecated" used in this context - it has a technical meaning within the standard that is not applicable here.
Let me be quite clear about this: the so called "Safe Standard C++ Library" has no standing outside of Microsoft - it is neither an official standard nor a de-facto one. Also the ISO C++ working group has not deprecated std::swap_range (or any of the other functions that can lead to these messages appearing). So, what on earth is this all about? There are representatives of Microsoft that participate in the standardisation of C++, and they were able to supply some of the details. It seems that Microsoft have identified a number of "unsafe" constructs in the standard C and C++ libraries: that can overwrite memory, or functions that return pointers to static data, or ... There is nothing very contentious about there being "sharp knives" in the C++ library - although there may be some debate about some of the specific choices made by Microsoft.
To assist themselves in eliminating these "unsafe" uses from their own codebase Microsoft have modified their compiler to flag them. This is illustrated by the message shown above. (This was posted to the library working group reflector - I presume that somewhere in the part of the error message I've not seen it identifies the code that uses swap_ranges .) If carelessly written this code could lead to memory being overwritten.
Microsoft have also developed some "safe" alternatives to the standard functions they have "deprecated" - and this alternative is what they have called "The Safe C++ Library". Well, their code is developed in their "kitchen" - so they are perfectly entitled to ban sharp knives there and from their account of their experience it seems that they had good results (although it hasn't been made clear to me how they measured this).
Full of enthusiasm for these benefits that this initiative has achieved, they've decided that all their users will gain from having these facilities made available to them. However, many of the experts working in C++ resent the idea of these rules being imposed upon their kitchens! In these kitchens the sharp knives are there because they are useful and are (hopefully) used with the care they require.
Many of the experts involved in this discussion provide libraries that need to compile cleanly with a wide range of C++ implementations. Some have already announced that they will be disabling this message in their code - they clearly don't want to spend time producing a special version of their code for clients that happen to use the Microsoft compiler.
There are also concerns for the ordinary C++ developer. Like many others I require clean compiles, and while a few of us might recognise that the above message is misleading I've certainly worked for organisations where an extended debate would ensue about how to adapt to it. (Which is a waste of time and energy.) And there will be some organisations or developers that will blithely follow the advice to use "The Safe C++ Library" without realising that doing so locks their codebase into a library that is only available from a single vendor.
The Microsoft representatives seem to be surprised at the negative reaction of the other experts to their plans. They had come up with a way to improve the quality of their customer's code and had not foreseen the possibility that people would not want to have these "unsafe" uses of C++ highlighted or to be offered a safe alternative. They really hadn't considered how their efforts would be perceived by the remainder of the C++ community.
Now there are many things that Microsoft could have done differently if only they had realised the need. And, after the feedback they have received, they may indeed do things differently when they ship the next version! They could have avoided terminology that suggests that their coding guidelines are connected with the C++ standard, they need not have made these messages the default option, and they could have provided better mechanisms for controlling these messages. (In the current version if a library vendor disables them for the duration of a header from their library, then the messages are not always emitted for users that choose to adopt Microsoft's guidelines.)
A more generous option would be to ensure that their "Safe Standard C++ Library" is made widely available - preferably under a licence that allows it to be used and supported on other platforms. If it brings the benefits to others that Microsoft have experienced then it could be of real benefit to developers. I don't know how common they are in the wider community but there is certainly a class of buffer-overrun errors addressed by these efforts. If they are as common as Microsoft believes, it would be a shame if these warnings are ignored (or simply disabled) by developers as "yet another attempt to achieve vendor lock-in" - but that has been precisely the reaction of those developers I've consulted about this.
The "Safe Standard C++ Library" might even form the basis for future revisions to the C++ standard. The Microsoft representatives have indicated that the parts of this work applicable to the C standard have already been adopted by the ISO C working group as the basis for a "Technical Report" (due next year) and that "once there is a little more community experience" Microsoft intends to do the same with the work on C++. So, in a future revision of C++, using swap_ranges with pointer arguments (which Microsoft considers an unsafe practice) may indeed become deprecated!
From what I've seen on TV every chef thinks the way that they run their kitchen is the right way - and that everyone else can gain by emulating them. So it is not too surprising that the developers at Microsoft think the same way. On the other hand the resistance to new ideas cannot be absolute - otherwise we'd still be using wooden implements to cook over open fires. Chefs (and developers) are impressed by results - and if the results of using these tools are good enough they will be adopted.
And what will I be doing in "my kitchen"? Well, I see C++ developers writing needlessly platform specific code far more often than I see them misusing swap_ranges (and I don't think I've seen gets used since the mid-'80s). So I'll be turning that warning firmly to the "off" setting.
