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."
Yes, in some respects, programming is becoming easier and more unqualified people are able to do it.
But I think that these guys are really missing the boat. The closer the programming environment can come to providing domain-relevant expression tools to the user, the better they will be able to create programs that fit their domain.
In addition, content these days is a form of programming. Whether it is HTML/CSS or word processing or spreadsheets, the distinct line between what is a program and what is pure data is blurred beyond recognition. So a programming language for interpretive dance would probably find the Natal very useful.
"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."
Might have been more appropriate to compare it in that people in the high performance arena (nascar) don't like antilock brakes because of their limits and the separation you get from your task at hand. (you lose your "feel for the road")
Tho I'm a little strangely biased, I miss the days of assembly, when 10k was a LOT of code to write to solve a problem, thing ran at blindingly fast speed with almost no disk or memory footprint. Nowadays, Hello World is a huge production in itself. 97% of today's coders don't have any idea what they've missed out on and just accept what they've got. Even someone that understands the nerf tools like VB at a lower level can get sooo much more out of them. I recall taking someone's crypto code in VB and producing a several thousand-fold speed boost because of my understanding of how VB was translating things. They didn't know what to say, they'd just accepted that what they were doing was going to be dog slow. (and unfortunately the users are also falling under the same hypnosis)
I work for the Department of Redundancy Department.
because the modern Microsoft development tools need that infernal Dotnet library to be loaded and then when it gets messes up any software that depends on it does not work.
Indeed. One of my PCs has a broken '.Net framework' which can't be fixed without a complete reinstall of the operating system: even Microsoft's own 'completely obliterate every last trace the bloody thing' uninstaller isn't enough to remove all the traces which prevent it from reinstalling properly. As a result, a lot of new software simply will not run.
Fortunately I do most of my useful work on Linux or Solaris these days so not being able to run random Windows software is no big deal, but '.Net' is such a monstrosity that it makes 'DLL Hell' look good in comparison; if even Microsoft can't fix it when it breaks, what chance do users have?
We've got a crew of .NET developers writing us an updated replacement to an existing VB app. I keep calling the new interface Fisher-Price, but actually it's Hasbro. I was mistaken, but an easy mistake to make.
Where it should absolutely take two clicks to make something happen, they found a way to make it five. Where you should enter a date, they found a way to not allow special characters, like '/'. Where you should enter an address, well, no spaces allowed. Basic functionality is lacking for several features, but the interface is there.
And no help files yet, despite beta release pending in a few days. In fact, though we have well over 1,000 pages of documentation, there seems to be no functional install that preserves the users' data in case they need to reinstall. I'm told that the next build introduces that.
For all the fancy IDEs, tools, etc, these guys are still not getting it done. I dare not say how far behind schedule this is, nor what the actual platform is, or someone will guess and raise hell over how anyone could be so insensitive as to speak the truth.
Your tools mean crap, if you're incapable. Just as your plumber would probably suck at actually making the pipe, your developers will suck if they don't 'get' what your users actually do.
Of course, it would help if they asked what the users actually do.
But I'm not bitter. I get to support this. Plenty of work.
deleting the extra space after periods so i can stay relevant, yeah.
I just wanted to let you know I feel your pain. I worked at this place a while back and I really liked my job. It didn't pay that well, but I felt important and had a massive amount of freedom. Then they hired a consultant to come in and take over IT. He knew how to run a business, but next to nothing about IT (though he knew just enough lingo to fool people who did for a few days). His 'programmer' didn't understand how to navigate file systems on Windows with Perl (and was supposedly a Perl guy). Being a Linux guy myself, I figured maybe he was, too. No, he had never even used Linux. Once I found that out I started to get rather scared and discouraged, because he was reworking a complicated, arcane, mission-critical system. I demanded all passwords be changed and that I not be given any of them because I didn't want to be blamed when they screwed everything up (plausible deniability). After assuring me that they (my bosses) wouldn't, and finally relenting another month later they finally fired the guys because they couldn't get anything working. At all. I even told them where to start to get a feel for what they needed to be able to do on it, and they still couldn't do it. They didn't even know enough to mess it up (generally the easiest thing to do). So management's answer was to just not have any sort of IT department at all. I could do all of the old IT manager's job, plus my old one, for the same pay and no possibility for advancement. So I gave them a month's notice and left. Probably not the smartest thing I've ever done (the economy tanked about 6 months later) but since most everyone else had left or been laid off around the same time, I'm not sure how much a difference it would have made to do otherwise.
A decade ago when I was employed at Big Blue it's then CEO Lou Gerstner said "All code has been written, it just needs to be managed". We all laughed so hard it hurt, however the way things are going Lou may get to have the last laugh after all.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
But the OP may be right if it is statistically true (I don't know that it is) that there exists high correlations between "good" programmers preferring a text editor and/or "posers" preferring Visual Studio.
I'll buy the former, but absolutely *not* the latter.
Coding with a simple text editor, make/gcc/etc, and gdb implies a fundamental set of skills: familiarity and comfort on the command-line, ability to (presumably) write and invoke Makefiles, ability to use gdb (which, let's face it, ain't pretty for a newcomer), and so forth. So it stands to reason that there's a greater chance such an individual has the skills necessary to write decent code (also known as "trial by fire"), as a poorer developer would likely be scared away.
But I find it very difficult to believe that, given a population of VS users, there's a disproportionate number of crappy developers (ie, that the ratio of skilled to unskilled developers exceeds the ratio in the software developer population at large). A weak developer will obviously use any tools that make the job of writing code less daunting, and a good IDE definitely fits in that category. And a strong developer will use whatever tool makes their job easier, and guess what? VS is a *damn* good tool, particularly if you're targeting the .NET stack.
So I'd would say this: A developer that's happy using a simple text editor/compiler/debugger combo has a greater than average chance of being a good developer. But you can assume nothing about a developer who chooses an integrated IDE over the aforementioned environment if given the choice.
In fact, I would go so far as to say that any developer who actively *shuns* IDEs without good reason (and, BTW, simple familiarity is a good reason... mindless elitism, however, is not) deserves as much skepticism as one who isn't capable of using the editor/compiler/debugger environment, as they're expressing dogmatic tendencies that can be deeply counterproductive in the work environment.
Embedded development and bootstrapping is the last bastion of necessity in assembly.
Any other use is likely for obfuscation, academia or pride.
About this time last year I was told to implement (in a C++ app) something not unlike the IMPORT command in VB. In other words, it allows you to call an arbitrary DLL function from a script language in our application.
Since we do not know at compile-time how many parameters are going to be passed to it, the only way I could think of doing this was to manually construct the stack into the required calling convention using PUSH instructions and do JMP EAX to call the function.
It took about 10-20 lines of assembler. I then had to do a couple of alternative implementations to support win32, elf32, win64, elf64 and win32 on ARM for the PDA version, but since there wasn't much code involved, the whole exercise took about a week from nothing to fully working.
Maybe there is a way to do this in C++ without resorting to assembler, and without requiring the called module to have a predefined interface, but I'm damned if I can think of one. To be fair, it is the only assembler module in the entire program.