March 2005 - Posts
For the soon to be released major update for LLBLGen Pro, v1.0.2004.2, I'm porting the Microsoft Petshop project v3.x to show some of the new code implemented in the upgrade. Now, I've seen a lot of crap code in my life but what Microsoft dares to offer as an example for .NET is beyond, well... , crap. 
Sorry to say this, but after working with the Microsoft Petshop code for a few hours, my eyes bleed. This isn't an example, it's code solely ment to run as fast as possible in the benchmark tests to show how fast .NET can be.
I truly wonder if this goo Microsoft calls Petshop 3.x is doing any good for .NET. Anyone looking at the code can only be shocked. The code is completely unmaintainable, inconsistent and can only set the wrong example, to put it mildly. A lot has already been said about this Microsoft Petshop version (and the previous versions weren't any better) but I'd like to suggest that MS uses a couple of hours to write a proper example using the Petshop code, to show new .NET enthousiasts it's not common to write code chewing-gum goo-style but to write solid, readable, maintainable code and .NET can help you with that.
Now if you will excuse me, I've some bleeding eyes to cure...
Various people seem to have discovered 'Codezone'. The name rang a bell, the color scheme did too. Then I remembered: I saw it first in the summer of 2004, at TechEd 2004 Europe. It was then introduced as the new developer community. It doesn't surprise me it's still the failing marketing driven 'community' initiative as it was back then.
Not only does CodeZone think that the world is divided into 2 parts: The US/Canada and 'the rest' (that really gives that warm feeling you're one of the group!), it also doesn't work. I selected C#, 'outside US/Canada' and '.NET framework and clicked the button. Oops! "Page could not be displayed. An error occured while processing your request. The site administrator has been notified of the error.". Apparently someone didn't think of implementing a check if the resultset was empty. But let's not nittpick on a technicality, the real reason codezone will not work is that it's marketing driven.
Marketing driven communities won't work for technical oriented groups. Technical communities are Q&A driven. A technical community has some key elements which are essential to make it a success: you have a question, you get answers. You see questions, you give answers. You have information, you share information so others get their questions answered. Another key aspect for keeping these communities together is a simple, yet effective interface to get to the information. Not the slow, cluttered interface of gotdotnet.com, not the Webdesigner-look-n-feel of channel9. But simple, effective interfaces, like Code Project, or Developer.com.
It's very simple: target groups and their benefits sought. Ironically the core rule of MarketingTM. And here they don't match. That's why all but two Microsoft's communities fail. All but two: the www.asp.net/forums community is a success, a lot of different sections crowded with people having a lot of discussions about technical topics. The other one is the MS newsgroup section. Why do these succeed and the others fail? One simple reason: they're not designed to be a community, they grew into the community status.
As soon as you try to 'design' a community, it will fail, because in 99% of the occasions, the people who are making the decisions during the design phase are not part of that community. This gives an environment the technical oriented people don't see as their home. Mind you: the internet is a pull market: the visitor decides what s/he will see/read, not the person creating the website, because if the visitor doesn't like your website the visitor will leave and move to another website or won't visit your website in the first place. The core rule of creating succesful websites has always been: deliver what your target groups want to find/read/see at your website, not what you think they should read on your website, because that's completely irrelevant.
I don't know any hard-core code writer, like myself, who visits channel9 often for example. Or gotdotnet.com. What's there to find? Ok, a random video of some internal MS lab or new product perhaps linked from a MSDN blog, but that's it. For example, if you have a question about a given topic, what's the first site which comes into your mind where you think you can find your answer? Channel9's wiki? CodeZone? Gotdotnet.com? If you do, how on earth do you search through the info there to get your answer? Most likely you'll either go to a newsgroup search using google groups, go to code project and search for an article there or go to the asp.net forums to search for an answer there.
The thing is: because you find your answer there, you stick around, you come back, because you learned you can get your questions answered there. In a technical driven community, that's key for building up a large(r) user-base.
Conclusion
So, Microsoft Marketing Department, take it from a guy who spend 15 years in usenet newsgroups: stay away from community initiatives and let fellow developers run the show. We know when a non-developer is calling the shots, we just do, call it a sixth sense, and we'll go some place else. You see, developers have to make a deadline once in a while and get things done and we can't babble away our failures, we have to deliver. That's why we visit sites and communities which also deliver and make us deliver.
To get your bonus this year: here's a tip for you all at MS Marketing: make the asp.net forums your core community and keep the interface raw, simple and fast as it is now and pair it with an article site like Code Project and make sure it's supervised by a group of hard-core code writers from the trenches, you know, the guys/gals you create the community for.
Eric Sink blogs his thoughts into the world about Team System, the pricing, MSDN and the recent uproar about all of this. I agree with him about the positioning of Team System, the pricing related to that positioning, the MSDN licensing as it is now and how it is misunderstood.
Though I think a lot of the uproar isn't about the fact that small ISV's or independent consultants want to use an enterprise targeting system like Team System (or as Sink put it: want to use a Boeing 747 to get to McDonalds). I think the real reason behind a lot of the negativity about the new MSDN model is fed by the fact that these developers, myself included, simply want to buy a package from Microsoft which allows them to write software, use sourcecontrol, have unit-tests, use fancy designers and do bugtracking/issue management.
In the past year, Microsoft bombed us with their Team System propaganda and a lot of people were very pleased to see Microsoft made a fully integrated system which did everything: allowed you to architect webservices, test your application with fully integrated test tools, use bugtracking/issue management and much more. This was what they're waiting for for years.
Microsoft offers developers a set of MSDN subscription flavors. These are often bought by ISV's to get every tool they need for a lower price (i.e.: per developer, the licensing costs are lower, if you buy for each developer a universal subscription). Because the universal subscription has everything you needed as a developer, it was the obvious choice: VS.NET enterprise architect was included, VSS and a lot of other tools/servers required for development of n-tier applications (the type of application most developed).
With the propaganda fed to these developers and ISV's for the past year about Team System and its functionality, the obvious expectation was that to get your hands on it, a MSDN universal subscription would be enough. After all, that was the package you bought for a developer if you want all developer tools that developer needed, right?
Though, this isn't the case with the new MSDN subcription model. For the first time, the MSDN flavors require a choice to be made: are you an architect? A developer? A tester? And if you need more developer tools, you have to pay more money. A bit strange, because, an ISV buys the MSDN package to get all the tools needed for development in one easy to purchase package.
These two things: the choice you have to make which team system functionality you want to use (the client version) and the requirement to shell out more money for the functionality you actually need, are the real reasons why people are upset.
Let's start with the first, the choices. I'm a small ISV, and with me a lot of people are. Because we have to make a choice what each developer at our small ISV is: architect, developer or tester (according to Microsoft), these developers can only use one of the three available applications while these developers need all three, as they wear more hats (often all three), not one. It's as if developers at small ISV's don't need to write tests or don't require an integrated test suite (I use testdriven.net, very good, but not as feature rich as Team System's features), and it is as if developers at a small ISV's don't need an architectural toolkit to design webservices or other higher-level design system. These small ISV's get VS.NET Enterprise Architect today when they purchase MSDN universal licenses for their developers (or should I say: testers/architects?). So Microsoft apparently changed their minds what developers at these small ISV's do.
Let me be blunt: Microsoft doesn't get it when it comes to what their customers need. That's right: need, not: want. These are two different things. If you as a developer can't use a feature you need, you'll be angry. If you as a developer can't use a feature you want, it's too bad, life goes on. Why doesn't Microsoft get what their customers need? The vast majority of developers in the world aren't large corporate developers, but work at small(er) ISV's. They were buying the MSDN subscriptions to get the tools they need. As times change and Microsoft did build the functionality these ISV's need now and in the future (real sourcecontrol, real integrated testing system, real bugtracking/issue management), they want to purchase that functionality from Microsoft using the MSDN subscriptions. Because that was the most affordable package to buy for a developer.
Though, they're not able to do that anymore, not by using MSDN subscriptions. They have to make a choice: who's the architect here, and who's the tester? What if there are just two people in the ISV? Buy three MSDN premium packages to get the applications for all three hats? Or is Microsoft really thinking developers at small ISV's don't test, don't need sourcecontrol, don't really need issue-management/bugtracking and don't need higher order designers for the applications they need? Oh, do I hear you say... "but you can buy it for a little more extra $$$" ? Ok, fair enough, but what's the use of having MSDN subscriptions if they're not enough? Why not make these MSDN subscriptions worth purchasing so they still contain the tools these ISV need? Why belittle small ISV's by forcing them to make a choice because their developers don't seem to test and use bugtracking systems and use sourcecontrol systems?
The other point, the money required to get the the functionality you want, is related to the first and is also related to the hype built up in the past year. As expectations grew higher and higher, and as developers saw that what Microsoft was creating was what they needed, it's a bit of a pain to understand that what a developer needs now comes at a price of $10,000.= instead of a $2,500.= (or thereabout). (looking at functionality, not at positioning, which is marketing/business related, not developer/feature related). There is only one question possible here: why?. Why did Microsoft bypass the small(er) ISV, by not offering the tools they need, while the functionality is there?
Personally, I can understand the pricing for Team Foundation Server as it is a product positioned at the enterprise teams. What I don't get is why I can't buy a package from Microsoft for a reasonable price, which gives me a Visual Studio.NET 2005 with integrated testing, bugtracking, issue management and higher level designers for services. Because I don't need them because I don't have 8,000 employees? The functionality is there, it just has to be packaged.
So what's there to do? Well, for small(er) ISV's, it's perhaps more efficient now to simply not purchase a MSDN subscription anymore, but buy a VS.NET professional edition per developer and buy /get the other services elsewhere, for example Source Gear's Vault. Or use subversion + the NCover/NUnit tools and a free Linux-based bugtracking system. Because, why would a small ISV still look at Microsoft for the tools it needs? After all, according to Microsoft, developers at a small ISV have just one single task...
The founder of VoodooExtreme, one of the first gaming sites, Billy 'Wicked' Wilson, died at age 33 yesterday. As a long time fan of VoodooExtreme and later on Gaming Groove, it was always a big pleasure reading his writings. A true icon.
Over a 100 MVP's have signed an online petition to make Microsoft migrate the behemoth Visual Basic 6 (VB6) to VS.NET and let it live on as an unmanaged language. More information can be found here: http://rblevin.blogspot.com/2005/03/microsoft-mvps-revolt.html
I wrote a fair amount of VB5 and VB6 COM objects for MTS and COM+ utilizing systems, because it was so much easier to write ADO code than it was in C++. At least until I found out that with smart pointers, generated by VS6, ADO code in C++ looked almost the same as VB6 (but then with curly brackets and MTA compatible 
)
Example (yes, lovely Hungarian Coding, code is from an inport/export tool) (comments added for the people who can't read C++)
// create command object
TESTHR(cmdADO.CreateInstance(__uuidof(Command)));
// fill properties
cmdADO->ActiveConnection=m_ggdInternalData.m_conADO;
cmdADO->CommandText = "sp_pdimport_AddModifyRemove_Users";
cmdADO->CommandType = adCmdStoredProc;
// Add parameters
cmdADO->Parameters->Append(cmdADO->CreateParameter("@sUserID",adVarChar, adParamInput, 10));
cmdADO->Parameters->Append(cmdADO->CreateParameter("@sPassword",adVarChar, adParamInput, 26));
cmdADO->Parameters->Append(cmdADO->CreateParameter("@iLogoID",adInteger, adParamInput, 4));
cmdADO->Parameters->Append(cmdADO->CreateParameter("@iLogoSmallID",adInteger, adParamInput, 4));
cmdADO->Parameters->Append(cmdADO->CreateParameter("@sAction",adChar, adParamInput, 1));
cmdADO->Parameters->Append(cmdADO->CreateParameter("@iErrorCode",adInteger, adParamOutput,4,0));
// execute the procedure
cmdADO->Execute(NULL,NULL,adCmdStoredProc);
// read back output parameter
iErrorCode = (int)cmdADO->Parameters->Item["@iErrorCode"]->Value;
if(iErrorCode)
{
// error occured.
throw(_T("Stored Procedure sp_pdimport_AddModifyRemove_Users failed."));
}
It's almost VB6! 
Now, I understand that having a huge investment in VB6 code and then knowing support will end for VB6 at the end of this month is not something you truly want. On the other hand, VB6 is over 6 years old. It works, if you could write software in it for 6 years, you can for the coming 6 years as well. So what's the big deal with these guys and gals wanting deliberately to keep VB6?
I don't know. It can't be the horrible syntax of VB6. It can't be the limited view on the world offered by a dated IDE and runtime. It can't be the limiting STA framework and pseudo-COM goo you had to work with. Apparently it's the 'ease of use' to write software for Windows, which is not offered (?) by VB.NET.
I say, it's a fear to change. Of course, software which is written in VB6 will get stale after a while. But so is my C code from 1992 using the CURSUS library for terminals. The tools used to write it will still work, but new stuff will likely be written for a newer platform. I also have a lot of VB6 code still in the sourcecontrol systems here, a complete CMS I worked on for more than a year, with management tools, COM / MTS based middle tier and great ASP 3.0 pages. It still works, we still use it. That doesn't change at the end of the month, the code works for 3 years already, why would it suddenly fall apart?
Every person who has worked with VB5 or 6 knows that when a new OS was released, and you wanted the new features of that OS, you needed COM components, and at the moment the VB runtime library gets pretty dated. With the upcoming managed Avalon layer and Longhorn core, the VB runtime will seriously look like something from the stone age. Microsoft made the decision a long time ago to move every developer to the same platform: no more COM or Win32 or VB or Java, but solely .NET. These kind of decisions are easily made but take years to become reality, and if you want to have something changed by 2006, you have to start perhaps 7 years before that to get things rolling by 2006. The decision to have a VB.NET is therefore a logical one: the VB developers would feel at home with the language and could migrate to the new platform, moving their code to the next platform.
What these 100 or so MVP's want though, is to keep the aged platform around but with new features, so they can use the upcoming platforms like Longhorn will offer us in VB6 like code. To get that accomplished, the VB language has to be adjusted to make use of the new platform features, the IDE has to be adjusted to meet todays (and future) standards, and the runtime has to be made up to par so it can be used for at least 10 years. So if you do all that, what do you get? I think something closely to VB.NET. So I don't see the necessity for the petition. And if you think VB6 is the only real computer language, the only real platform someone should ever write code in (these people really exist), you can also port your code to RealBasic. But while doing that, you'll discover how little VB6 really offers you if you don't have the nice COM objects available to you when you try your realbasic application on Linux.
Despite the fact that I'm a 'lefty', I don't particularly like 'use the next version, it's better'-kind of thinking that much, sometimes what you have is good enough. Though, being the realist that I am, in this case, I can only advice developers around the world: if you're a VB6 developer, don't think about tomorrow, think about next year, or 2 years from now. It will be .NET, .NET and oh, .NET, at least for the Windows/Microsoft developer. Make the change, now, when you have the time to familiar yourself with OOP, .NET, it's massive API and VS.NET, so you can make the transition more easily in the near future when you for example have to work on a .NET project: you then don't have to say 'No' or have to hastly learn all those classes and new VB.NET language elements.
I wonder if these 100 MVP's also still run Windows for Workgroups 3.11 on their Pentium 60 machines...
Mark Lucovsky left Microsoft today. Now, Mark is a legend, so I don't think he needs further introduction. What interested me was that he left to work for Google. Looking back at what Mark has done, you'll see things like 'Designing NT kernel', 'Designing in-house sourcecontrol system for win2k' etc. Not your average notepad-style projects.
What made him move to Google, a company who competes with Microsoft but in a complete different area? For that, you have to look at what Mark also was: designer at the Hailstorm team. Now, let's enter speculation mode. What if Google hired Mark to architect the all-you'll-ever-need-website/services system for Google, which combines all Google's current and future services? Strange thought? Perhaps, but let's look closer at what he has to say in his brilliant posting about shipping software. He tries to explain that Microsoft is not that good at shipping software. Some people in the blog community read in those words that Microsoft wasn't able to create CD's.
NO, silly!
What Mark meant was that the way software is shipped, by installing it on the client through CD's, DVD's or a cumbersome download process, is slow and the number of clients affected is not controlled by you and it will take some time before all clients have installed your software. That's not MS fault, it's the disadvantage of the way their software usually is distributed. However, with an online service website, a new feature is distributed to all users in one go. He gives that example.
You still think he'll work on some OS? Think again. Oh, and while you're firestarting your braincells, please think about what kind of impact this will have for how we use computers.
More Posts