Slashdot Mirror
Microsoft's Top Devs Don't Seem To Like Own Tools
ericatcw writes "Through tools such as Visual Basic and Visual Studio, Microsoft may have done more than any other vendor to make drag and drop-style programming mainstream. But its superstar developers seem to prefer old-school modes of crafting code. During the panel at the Professional Developers Conference earlier this month, the devs also revealed why they think writing tight, bare-metal code will come back into fashion, and why parallel programming hasn't caught up with the processors yet." These guys are senior enough that they don't seem to need to watch what they say and how it aligns with Microsoft's product roadmap. They are also dead funny. Here's Jeffrey Snover on managed code (being pushed by Microsoft through its Common Language Runtime tech): "Managed code is like antilock brakes. You used to have to be a good driver on ice or you would die. Now you don't have to pump your brakes anymore." Snover also joked that programming is getting so abstract, developers will soon have to use Natal to "write programs through interpretative dance."
(Puts hand up) Never, really? You haven't spent as much time marking up Word documents with bold, italic and other random tags, or working with people who have, as I have, then. Multiple people doing similar work on a crunch project would go home at the end of the night after about 14 hours, hands/fingers/wrists too sore to continue, because the actions required to highlight text accurately in MS Word either by keyboard or mouse are hard on one's hands and wrists.
Yes, day after day of 14 hour days or longer will be hard in any tool. But I've been able to work in various text editors (programming or doing similar document markup) for similar long stretches without coming home with hands so cramped that I couldn't even pick up a bowl to make soup. The experience reinforced two things I knew already.
(1) Just because a tool CAN do something, doesn't mean that that tool SHOULD be used to do it.
(2) The easiest tool to learn how to use passably enough for casual work is often not the best tool for intensive repetitive work.
Epilogue. The company eventually developed a tool to replace Word, which did not require engineers to perform extensive visual markup for bold, italics, etc. Sounds good, eh? The tool is based on Word. It requres extensive semantic markup which is used by a back-end process that replaces the semantic markup with visual markup. Lots of smart decisions were made by the managers who ran this project. Using Word as an XML editor (and requiring that files contain all of the Word XML overhead, thereby making it next to impossible to use any other tool to edit the XML) was not, IMHO, one of them. Really, I understand vendor lock-in as a marketing strategy, but for an internal tool?
Company name omitted for obvious reasons.