Jul 21, 2006 | General, Software Development
So today I saw a funny series of Blog posts starting with Robert Scoble’s defense of his “Geekhood” after a post by someone named Cody who hates fake computer geeks.
What’s interesting about these posts are the examples that both use to define geekiness. Cody complains that Scoble doesn’t host his own Blog software. Scoble defends his geek credentials by mentioning past experience installing NT 3.5. Either way, those definitions don’t reflect the reality of the information age.
To put this in context, let’s think back 15 years or so to the Visual Basic story. Here was a tool that provided a high level of abstraction over Windows. Who were the geeks? The C++ programmers who blew off VB as a “toy language” or “glue language”, or the millions who adopted VB either as their first language or migrating from another language?
The answer is obvious – both were. The only difference was that the VB geeks were much more productive (for a wide class of applications).
The world has changed of course, and neither VB .NET nor C# provide the kind of abstraction levels that are needed going forward. We don’t have a tool that corresponds to the .NET framework the way VB related to the Windows API. Or put another way – VB was incredibly productive because it provided a level of abstraction to the underlying API for which C/C++ was the “first class” language. Today, VB .NET and C# are the “first class” languages for .NET – but we don’t yet have that new paradigm, that new level of abstraction, that will bring us to the next level (of geekiness, as it were).
Or do we?
At least in one area, I’m beginning to think that we do.
When I look at ASP .NET, I see lots of great components and features for building great web applications. At the same time, the prospect of building a site using it is – well, it’s about as exciting as Hello World was in C back in the 90’s. I’m working on a project now (not ready to talk about yet), that is web based, and building it from scratch wasn’t even a consideration.
For web applications, tools like WordPress and CMS systems like Plone, Drupel and DotNetNuke are compelling platforms on which to base new applications. Their open source nature and flexible architectures assures extensibility in much the way that VB’s support for custom controls allowed the language to do things that it’s developers never imagined.
This, by the way, should be something Microsoft pays close attention to – the vast majority of CMS systems today are LAMP systems – and this is what might cost them the web platform war (not the quality of the platform itself).
Anyway, I digress. Cody, Robert – you’re both geeks in my book.
And for the record, this particular Blog is on WordPress, that is in fact hosted on my own server – not because there is any geek value in doing so, but because my incremental cost to do so is zero (which is, coincidently, the cost of Robert’s hosting as well).
Mar 8, 2005 | Software Development
A group of VB MVPs recently signed a petition regarding the future of VB6 . I thought I’d take a minute and address some of their issues. I myself am a VB MVP, and have chosen not to sign at this time because I disagree with the recommendations listed in the petition, but not the objectives.
First, consider the objectives of the petition:
- Preservation of assets
- Continued support for the Visual Basic language
- Ease of migration of unmanaged VB/VBA code to VB.NET
If you have a business that has invested years of development effort in VB6 and VBA code, should you port that code to .NET? We�re talking existing working code here – not new projects. By any sane economic rational, the answer is no. In most cases porting is stupid and a complete waste of money.
The rational way to migrate to .NET is incrementally – using it for new development and porting selected components that can truly benefit from the .NET framework, relying on interop to allow existing code to work with .NET code.
The problem, if not tragedy, is that many developers are porting code to .NET purely out of fear – fear that they will no longer be able to receive support for VB6, fear that existing VB6 projects may not run on future operating systems, fear that they will not be able to obtain VB6 licenses.
Microsoft, perhaps in its desire to promote .NET, has not done enough to assuage these fears. Either they value .NET migration more than the best interests of their customers (which would be shameful), or they are just not able to get the message across. Porting is stupid (for proof – ask what percentage of the MS Office code base has been ported to .NET).
The classicVB petition recommends integrating some future VB6 into the Visual Studio IDE. I think this approach would be mistaken and a waste of resources.
I would like to offer the following recommendations as an alternative:
- A longer term commitment to providing support for VB6 and VBA
- Guaranteed support for VB6/VBA under future OS’s for an extended period (definitely including LongHorn and at least one more beyond).
- A commitment that once a decision is made to stop support on VB6/VBA, that the entire VB6/VBA code base will be placed into the public domain as an open source project, or perhaps a foundation similar to Mozilla, to assure that interested parties can continue to support and perhaps fork the project in the future.
I believe these alternatives would provide sufficient peace of mind for most VB6 developers to base their migration plans on sound economic factors relating to their individual situation – and not on fear, uncertainty and doubt.
Links:
Petition
Scobleizer (who blogged the petition under the “revolt” moniker, even though it isn’t)
Jan 24, 2005 | Software Development
It’s a rare conference that doesn’t include at least one (dozen) “best practice” sessions. A search on Amazon.com found 166 computer books with “best practices” in the title, an astonishing 2500 that have “best practices” somewhere in the description.
What are best practices? When you come right down to it – they are for most people a shortcut to expertise. The knowledge base required to be a professional software developer today is huge. To be a good one, even greater. Learning programming and a language or three is trivial, and just the beginning. There are also the tools, for both development and management. The platform you’re coding to (.NET framework, Win32 API, etc.). The services you’re using (web servers, databases, etc.). Each of these has to be configured. Most have their own languages as well (I just finished a project that required me to simultaneously program in VB .NET, C#, Regex, Javascript and SQL).
And the knowledge base is a moving target – every year or two it changes, grows and becomes more complex (sure .NET 2.0 twice as good as 1.1 – there’s twice as much to love, and learn.)
We can’t know it all. We can, if we’re very lucky, learn those parts of it we need to solve the problems at hand. If only an expert could come along for each of these technologies and teach us just what we need to know – being sure to include those “gotchas” learned through harsh experience. In other words – “best practices.”
Sounds good, right?
The problem is, those best practices can come and bite you. Because the phrase “best practices” is misleading. It’s incomplete.
The correct phrase is: “Best practices for solving X class of problem”
“Best practices” are always associated with a particular set of scenarios. And if you don’t know those scenarios, you can be in deep trouble. Because best practices for one scenario can quickly become worse practices for another.
Case in point:
Imagine if you will, an ASP .NET web application. Everybody knows that it’s a good thing to reduce round-trips to the server. Most ASP .NET “best practices” emphasize techniques to reduce round-trips and reduce network traffic. Like spitting out client side script for validation and to handle some of the user interaction. Like turning off viewstate where possible.
And you know what, those are all good recommendations.
Unless…
Imagine this ASP .NET application has section, say maybe half the site, that is very rarely used. Maybe it’s for administrators only. Or maybe it’s used rarely, say to view 1099 forms at the end of the year.
Coding a web application that makes heavy use of client side scripting is hard. It’s hard to develop. It’s harder to debug. It’s harder to maintain. It costs more. It turns out that for low traffic portions of a site, those performance “best practices” are actually worse practices. They cost a lot, and no one may ever notice the benefit.
I’ve seen projects like that – where developers follow the “best practices” recommended by Microsoft or experts, only to come up ultimately with brilliant implementations of flawed architectures. Best practices are not a substitute for understanding the fundamentals.
So next time you attend a talk that promises to teach you best practices, or read a book with that in the title, be sure to take a minute and ask “best practices for what kind of problem?” Because if it’s not your problem, chances are you’re about to be led astray.
Dec 7, 2004 | Software Development
Joel Spolsky has an interesting discussion on his site in which he challenges the Microsoft Solution Framework (if not software development methodologies in general) using the Hebrew terms “rosh gadol” and “rosh katan” to describe the characteristics of two types of developers.
While I would hesitate to try to translate the two terms (I think Tamir Nitzan does a much better job than I could), I thought I’d share my own way of looking at it. Though it may be a bit of an over-generalization, when it comes to approaching a task there seems to be a spectrum.
On one end you have the individual who solves problems. When they have a task or goal, and run into obstacles, they will solve them, overcome them, bypass them, work around, above or right through them, even if it means redefining the problem to do something just as good or better than the original task or goal. These people would, I think, be Joel’s “rosh gadol.”
On the other end of the spectrum, you have the person who stops at the first excuse. In other words, as soon as the individual as a justifiable reason to stop looking for a solution, they are finished. While this can be intentional (Joel’s example of a “work to rule” situation applies), it is more often just part of their nature. These would be the “rosh katan.”
There are, sad to day, a lot more of the latter than the former.
And this also supports Joel’s assertions regarding software methodologies. A true “rosh gadol” won’t actually be suppressed by a restrictive methodology – he or she will likely solve their problem by finding a better company to work for. A “rosh katan” won’t have trouble with it either – as the more complex a methodology is, the more opportunities there are to find excuses (uh, the additional 3 week project delay was caused by the requirement to review and rename every local variable to have camel casing…).
Of course, this isn’t just applicable to software development. It’s part of the human condition. In fact, I strongly suspect that this is part of one’s character that is formed when very young, because I don’t know of any reliable way to convert an adult from a “rosh katan” into a “rosh gadol.”
Nov 5, 2004 | Software Development
I’m pleased to announce the publication of my latest eBook “Visual Basic .NET or C#: Which to Choose (VS 2005 edition).” Based on VS 2005 (Whidbey) beta 1, it is a major rewrite/revision of the previous VS 2003 title, based not only on changes to the two languages, but on the evolution of .NET in general.
Available from Desaware, Amazon.com and Lockergnome
Oct 27, 2004 | Software Development, Technology
Now that we have reached the home stretch of the political season, the chance to actually vote on something… and the prelude to what is likely to be an extended and painful period of lawsuits, recounts and recriminations for one side or the other, it’s time to look ahead at what we can do to occupy our spare time for the few months until the next election cycle begins.
Fortunately, there is an ongoing contest that is quickly becoming just as extreme, just as polarized, and just as lacking in honesty as any political contest we’ve seen yet. Yep, it’s the good old closed vs. open source debate.
This is prompted by a couple of friendly messages I’ve received lately. The first sent by a good friend is an presumably objective report in the Register comparing the security of the two systems.
The other, an email from my good friend Steve Ballmer (who I’ve never met, but have seen from a distance at a technical conference or two), containing six pages (2700+ words) extolling the benefits of Windows over Linux in every possible way (including, of course, security, with an indirect reference to a study by Forrester Research).
Now, the Register article seemed to me well researched, but it’s pretty easy to see that despite the innocuous title “Security Report: Windows vs. Linux”, the piece is clearly advocating the Linux side. Let’s face it, an objective report is unlikely to have it’s first couple of sections titled “Myth: There’s Safety In Small Numbers” and “Myth: Open Source is Inherently Dangerous.” Still, it makes for a fascinating read, and the author’s arguments are based both on technological reasoning and hard statistics – not the anecdotal evidence so common in white papers and political campaigns.
I’m afraid this time the “Swift Boat Veterans for Truth” spam of the year award has to go to Ballmer’s letter. It was just too easy to see the spin. My first hint came with the name dropping – while reading the list of customer case studies I couldn’t help but see Kerry in his second debate name dropping an endless list of senators and generals. I also found Ballmer’s choose Windows because “being on the wrong end of a software patent lawsuit could cost a customer millions of dollars, and massively disrupt their business” argument comparable to Dick Cheney’s “if you choose Kerry the terrorists will attack us” tirade (as a technologist, the idea of choosing software to avoid lawsuits instead of based on cost represents a huge failure on the part of our industry and society).
Then there’s the security article itself. The MSDN page is headlined “Windows Users have Fewer Vulnerabilities.” Imagine my surprise when I found the actual title of the Forrester report was “Is Linux more Secure than Windows”
Ok, so maybe the MSDN page refers to the conclusion? No – the executive summary of the report concludes: “both Windows and four key Linux distributions can be deployed securely”.
Ok, so do Windows users actually have fewer vulnerabilities?
Well, Windows users do have fewer overall days of risk by their metrics – which might explain this quote. But the study also shows that Windows had the highest percentage of high-severity vulnerabilities.
I’m not going to try to guess which system is really more secure. I don’t have time to reconcile the methodology of these two reports (the Register report found that Windows had more vulnerabilities). Which brings me to my greatest frustration.
With technology advocacy and marketing becoming as polarized as a political campaign, who can we look towards to be honest brokers? Even non-sponsored objective reports are inevitably influenced by the biases and backgrounds of their authors, and their results spun by each side.
On one hand, I truly sympathize with anyone who actually has to make a choice between platforms. Between the lack of trustworthy information and the flood of marketing noise, the chances of being able to truly choose the best one for your situation are slim. On the other hand, perhaps there is good news after all. Both platforms work, and can be secured. Cost studies go both ways, but few of them seem to claim a real difference in total cost of more than 20%, which is probably well within the margin of error when calculating the cost of a large scale platform deployment anyway.
So if the two approaches really are comparable in cost, and security, maybe the right answer is to choose based on a more arbitrary standard, like which name you like, or which fits better with your personal politics, or maybe the roll of a dice. Who knows, the money you save by not studying and comparing and analyzing the choice may be more than the ultimate cost difference between Windows and Linux.