The first half of the title of this post comes from a conference session title, which I saw on line. It made me startle a bit.
While I'm sure that the intended meaning was different from how I read it, the idea of "managed development" is different from any concept of being a "managed developer".
SET KNEE-JERK OFF: managed != good
I appreciate it when I'm well-managed by human managers. And I appreciate the benefits of managed development, in general. And I appreciate why Vista is designed to lock stuff down. Really, I do.
But I don't like the way Vista, as an operating system, manages me, whether as a user or a developer. Somehow the title of that conference session made me confront this fact.
I tried to give a personal definition of productivity, from the point of view of development tools in a post a couple of days ago. Permit me to elaborate on that definition a little.
The right tool to use is the one that most efficiently and most excellently provides the result I want, period.
Whether the language is dynamic or not is irrelevant if I don't happen to need it in what I'm doing (although it is often an extremely useful feature). Whether overloads and/or multi-inheritance etc etc etc are available are not pertinent to my decision for a project-at-hand in any abstract way, either. They're not articles in a credo.
There is a difference between well-managed and managed, whether by software or by human managers, and this difference is somehow related to my definition of productivity:
If I'm well-managed I get more work done and the work I produce is better work. If I'm poorly managed… I don't and it's not.
Vista development
Leaving aside issues of "developing on Vista" or "living one's computer life on Vista", I have real concerns about the way "developing for Vista" is being taught, or actually not taught.
Case in point: the August issue of the same magazine that sponsors that conference has a very cogent letter written by John Halloran of Van Nuys CA, which reads as follows (in part):
My need now is to create an install program that registers everything correctly on Windows Vista. I could also use a discussion of the pros and cons of different forms of Windows Help files now that Microsoft is discouraging 32-bit help files in Vista. Your magazine is not meeting my needs…
The stuff John H asks for is the kind of information that I want too. It's what any developer who wants to develop, deploy, and distribute really needs to know, frankly. Articles about gradient fills and gadget examples can wait while we tool up on the truly important stuff.
I don't especially blame the magazines. In fact, I'm much more ticked off at the way Vista integration priorities were handled for Visual FoxPro SP2/Sedna.
How about (maybe) something in NET4COM that allows VFP developers to apply User Account Control principles when they need to, so that VFP apps can run with least privilege, detect the types of privileges they have, figure out what additional privileges they might need to ask for? (And here is an MSDN article to help you start out scoping the needful.) Do you think it was a considered management decision to opt NET4COM facility to play system sounds instead?
Do you really think that having Vista-style dialogs in your FoxPro application is the most critical detail that spells "professionalism" and fit in as a good Vista citizen? Just like the gradients and gadgets: we got what's easiest to specify, easiest to put in a sound bite.
Smells like Team System
On a somewhat related note, I was watching dev e-mails flying around on a team with whom, thank goodness, I do not share code. After a couple of disasters, policy was suggested and then invoked, quite rightly:
Please use the vss to maintain the latest working [code repository]… Over the past few days there have been instances where rework had to be done because [the code was not in synch]… Let's all use VSS and we won't have to worry about our code breaking because of someone else's changes.
From your mouth, Mr. Manager, to the Grid's ears, but it really ain't so that you won't have to worry.
Tools promote teamwork and coordination — but tools are not in themselves guarantees of teamwork and coordination. They're not even guarantees of productivity.