Apr 24, 2006 | General
It’s been a while – a long while since I’ve posted regularly here.
Recently, I met Jeff Atwood at SDWest and he encouraged me to start up again. I’d been thinking about it for a while, and that was possibly the point that tipped it for me – at least enough to start the process of updating the server with the latest WordPress software (my existing blog site had become a magnet for comment spam, and my apologies to anyone who’s tried posting a comment that never was displayed – it was lost in the flood of messages in the moderation queue).
So where have I been? The best way to describe it is I guess a sort of Sabbatical. It actually took me a while to remember the word sabbatical – it’s not a word that often appears in the vocabulary of software developers (a topic on which I will write more on later).
The idea of a Sabbatical is simple – we get so caught up in the day to day activities of life and career (what my sister calls the “muck and mire of daily life”) that it’s hard sometimes to have time to just think – to gain perspective.
I can’t say that what I had was a true sabbatical – because I was still working. The point is – I was working less. Just a few conferences a year. No new books. Mostly handling Desaware and a few small consulting gigs (mostly to keep learning and keep my software development skills sharp). In short – my typical work hours in a week were what I think most Americans would call a “normal work week” (as compared to what what I, and many people I know, have grown accustomed to).
On the other hand, it was a long Sabbatical, and I do feel “recharged” so to speak. What I’m charged up for I’m not entirely sure yet, but returning to this blog is a part of that process. It’s nice to be back.
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)
Feb 6, 2005 | Technology
I tend to be a skeptic of gadgets. Oh, I do get excited by the latest new gizmo (I’m too much a techie not to be), but the excitement is mitigated by the knowledge that buying it would mean having yet another gadget to learn to use and keep track of. Another source of worry with regards to breakage, crashes and loss of data. Another charger to match with it’s correct device. And, of course, another device to inevitably replace in just a few months when it becomes hopelessly obsolete.
In my experience the benefits of devices from cell phones to PDA’s are often outweighed by these hidden costs and hassles.
So it was with doubt and trepidation that I opened a box containing an IPod shuffle that was recently given to me.
Honestly, when I first heard about it I thought the Shuffle was a stupid idea. With minimal controls – just enough to skip forward or back in a play list (which is either the order you defined when you loaded it, or a randomly generated order), and a volume control, this is not a “feature rich” device by any means. Besides, I already have a very nice MP3 player – a 60GB Nomad Zen which, while not as cute as an IPod, is quite usable and benefits from having a replacable battery. On the other hand, I only use the Nomad on flights – it’s too much of a hassle to keep charged, carry around, etc.
So I was stunned – floored in fact – to discover that I really like the Shuffle. That in fact, it is the very simplicity that makes it so useful.
First there is the size. It is truly a “fit anywhere” device. I swear it’s just about weightless. And there’s no pocket it won’t fit in.
And it has no charger to lose. It charges right off the USB port.
But most important, once you have loaded it there is nothing to learn or configure. In a daily routine that has way too many decisions, the Shuffle offers none beyond turning it on or off. And with 100 or so of my favorite songs loaded, it turns out I really don’t care what order they play in.
So to my surprise I find myself carrying it with me often. And sometimes just turning it on when I feel like listening to music, even if just for a song or two.
All is not perfect though. Like the regular IPod, it’s battery is not replaceable, meaning it’s ultimate demise will be much earlier than it should be. And it uses ITunes software. Now, I’m sure ITunes is a very nice program for managing a full IPod. It has plenty of features and power and a suitably confusing user interface. But the feature rich UI is in total conflict with the sublime elegance and simplicity of the shuffle. It is far too easy to accidentally delete songs painstakingly selected and loaded. It’s basically awful.
But such imperfections aside, the Shuffle is a surprising treat, and for those of you who appreciate that more complexity is not always better, you may find it a pleasant and painless gadget to add to your collection.
(for the record, I do still own a small amount of Apple stock)
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 9, 2004 | Technology
Like many, I have very mixed feelings about IBM’s sale of their PC division to the Chinese company Lenovo. Like many professionals, IBM’s Thinkpad is my notebook of choice. And it’s not just the features, or quality of construction. Or the incredible compatibility with everything. Or great support web site. Or excellent reliability. The real amazing thing is their technical support. Whether it was replacing a forgotten custom power cable on a few hour’s notice in Chicago, or being able to get a real person on the phone late on a Sunday night to deal with milk spilt on a keyboard, IBM provides a level of support that few if any can match.
My first thought when I heard of the deal was – so long Thinkpad. Because I couldn’t imagine that anyone else could maintain the overall quality that the brand name “Thinkpad” has earned.
But then I read their press release. Yeah, it’s the usual marketing fluff, full of nice semi-promises that don’t really mean anything. But there were a few facts that surprised me. First, that the new PC division would be headquartered in NY. Second, that an IBM VP was becoming CEO of Lenovo. Third, that IBM is maintaining a pretty significant ownership stake in Lenovo.
In other words, this looks less like Lenovo just buying the PC division and more like them trying to, in effect, become a major multinational company, like Microsoft, Sony, and dozens of others including IBM itself.
You see, the one flaw with Thinkpads is that they aren’t cheap. So it occurred to me that it’s possible, just barely possible, that this new company might be able to keep all the things that make Thinkpads so great, and just maybe do it at a lower price. Ok, I know it’s a long shot, but one can hope.
I’m going to be due for a laptop upgrade next year, and I’d really hate to start shopping around again. However, just in case – if any of you believe that another laptop line is overall as good as Thinkpad has been, I’d love to hear about it.
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.”
Dec 4, 2004 | General
Ok, I admit it, I’m a Trekkie from way back. Not an extremist, mind you. But I grew up on the original series, and by the time I was old enough to recognize how cliche it was, Next Generation was there as a deserving successor. Deep Space 9 was better yet, almost (but not quite) reaching the level of genius found in Babylon 5 (the best SF series ever made).
I must confess though, Voyager was a let down. I started watching, ready to give it the benefit of the doubt, but somehow it just didn’t work. Every other episode consisted of alien race threatens/invades ship, Janeway & Co. save ship, ship gets a few miles closer to home. Yes, there were a few gems in there, but on those occasions I watched I was more often than not disappointed.
With Enterprise, I started out hopeful, but again it seemed uneven. I almost gave up, but at the end of the last season something happened. Whether it was the introduction of multi-episodic story arcs (a key element of the success of both DS9 and Babylon 5), or just more sophisticated storytelling, I actually began to look forward to seeing it. With this week’s conclusion of a three part series illustrating a key historical event on Vulcan, I feel they’ve reached a level as high as any of the other shows.
So, for those of you who have abandoned Star Trek in one of its later incarnations, but remember one of the older shows fondly, I think it’s time you pay the franchise a visit. You may be pleasantly surprised.