Microsoft offers a "freemium" software product that makes life considerably easier for the programmer or database administrator who has to work with their SQL Server database server. Its full name is "SQL Server Management Studio," usually referred to as SSMS for short. At work, it's rare that I don't have at least one instance of it open at any given time. But I thought this little quirk I've noticed in the 2008 version made a good illustration of programming for field conditions.
When you're writing in the SQL language, you're referring to various objects in the database--everything from tables to individual columns in tables to custom code to other database and sometimes even databases on other servers. But, just like the spell-checker in a word processor has its "dictionary," SSMS maintains its own dictionary of words that are reserved in the SQL language, as well as the objects in the database currently in use. The upshot is that if the programmer fat-fingers, say, the name of a database column, SSMS highlights it with the squiggly red underlining you'd expect from a spell-checker.
The weirdness comes in, though, if you're in the middle writing SQL code and make a change to the data structure to which it refers--for example, let's say you add a new column to a data table. Even after you commit your edits to the database (which basically checks all its references and slams you with error-messages if you've screwed something up), that new column is not added to the "dictionary" currently in use by your editing session.
That struck me as more than a little out of touch with the realities of the single-programmer experience, let alone within a team environment. Odd, considering how SSMS's market niche is quite small, compared to ubiquitously mainstream software like Word and Excel. As quirks go, it's pretty minor--at least I haven't caught it corrupting data. (By comparison, MySQL Workbench is absolutely worthless for the task I need it to do.) But to me, the existence of such a quirk is surprising in that, in terms of features, SSMS hardly needs to break its functionality into "ribbons" to avoid terrifying its users with menus so dense they just might collapse and suck the rest of the application into a black hole of complexity.
On the merits, you'd think that programmers writing tools for other programmers would result in the most meticulously thought-out software known to humankind. Sadly, it's quite the opposite, at least in my experience. On one hand, I suppose it's sorta-kinda flattering that you're considered smart enough to work around quirks that would freak out the "average" user (however "average" is defined).
But the reality is that programmers are users too, users who appreciate a fully-finished product as much as anyone. Yet--again, in my experience--so many "enterprise" tools are not actually sold to the customer so much as the CIO. Meaning, not the people who, y'know, actually have to use them or anything.
