February 2004 - Posts
Just finished “speaker training” for the Web Track at DevDays 2004. I've reviewed my content before, but I got to see the whole picture this time. I must say it looks very promising, that is, promising to be an event that every ASP.NET developer should attend. It's virtually guaranteed that you'll learn something, and more than likely you'll learn a lot and walk away with a slew of information and reading materials that will make you into the security-focused developer that you always knew you should be but were too intimidated to become. If you haven't registered yet, do it now!
I've spent a ridiculous amount of time trying to create a few Virtual PC 2004 images for my development team. All I want to do is get a copy of XP Pro running with Whidbey installed and ready for development. It's taken me way too long to just get XP and Whidbey installed, only to find that I underestimated the required disk space, so now I can't install the Whidbey docs. If anyone knows how to resize an existing disk without corrupting it, please shout out!
I think VPC is a very handy product and have used it for demos in a few presentations and non-production development.
Now a few gripes:
1. By default VPC installs to 'Give processes on the host operating system priority'. This is bad, for those of us who can be forgetful of small, but important, details. I installed VPC on this desktop and forgot to change that setting before I started installing XP Pro on a new VPC image. After four hours it was still telling me I had 37 minutes left, and it didn't appear to feel motivated to get past that.
At that point, I remembered this performance setting. Unfortunately, it doesn't seem to take effect until the VPC restarts, so I had to start over installing XP.
VPC folks: Please change the default to 'Run Virtual PC at maximum speed'.
2. Even running at maximum speed (and allocating 512MB RAM to it), it still runs a bit slow. I suppose you can only ask so much, but it would be nice to tweak it up a bit, especially on the installs. Whidbey took a lot longer to install than it does on one of my slower PCs (outside of VPC).
3. Is there any way to install the VPC Additions automagically, before the OS installs? It takes a bit to get to the point where you can install the Additions. And forget about Longhorn.... If nothing else, perhaps prompting the user to remember to install them would be handy. I've seen a good few folks worrying about issues that are solved by the Additions.
4. The help leaves a lot to be desired. Maybe I'm spoiled by MSDN, but it is hard to navigate and doesn't really have much there. This area really needs improvement. Maybe including a FAQ and/or performance tweaking section (if there's anything I'm not aware of in this area) would be helpful.
Other than general slowness, the idea of the product is great, and the implementation isn't bad (just could be better). Maybe it just needs time to mature, since MS just bought it last year.
I was struck recently (again) by the amazing laziness of some developers in our industry.
The way I see it, there're good laziness and bad laziness. Good laziness is that laziness that motivates us to seek the most efficient and best way of doing something, both for now and for the long term. This sort of laziness requires intelligence, planning, and a solid work ethic. It says, for instance, that once I'm done with this application, I never want to think about it again unless I want to add features, and in that case, I want it to be as easy and painless as possible.
In other words, it is long-term laziness. It is laziness that motivates me to learn as much as I can about what I do; it is laziness that makes me take those extra steps to plan, design, and write solid, efficient code--so that the total amount of work I (or those who work with or after me) have to do is oodles less than it would be otherwise. And, consequently, it is laziness that saves my company a wad of cash and makes them look better all around.
There is another sort of laziness that I have encountered far more often, unfortunately. This is the sort of laziness that requires no intelligence, little or no planning, and a what's-the-least-amount-of-effort-I-can-put-into-this-now attitude. This is the kind of laziness that doesn't want to do any technical specifications but just wants to start coding. This is the kind that prefers to copy and paste code instead of refactoring it. This is the kind that doesn't spend any time learning or working any more than is necessary to get a 'working' product. This is the kind of laziness that costs companies millions (if not billions) every year.
In my years of working in the software development industry, I think back and can think of only a handful of folks that are long-term lazy. Most just do the minimum it takes to get by and get paid and turn around and demand the same compensation that the long-term lazy want (and/or get). After all, we all do the same job, right? I would say no. There's a lot more to being a software developer than getting a grasp on a language and forking out software the 'works' occassionally.
In a previous post, I talked about working smart instead of working hard. These differing forms of laziness apply directly to that concept. Those who are short-term lazy are, much more often than not, the ones who end up having to work a lot more (and/or forcing their co-workers to work a lot more). On the other hand, you can't always spot them by this trait because they can also be the ones who come in at 9a and leave a 4p and let their co-workers sweep up after them, forcing them to end up working smart and hard.
And really, that's what leaves me writing this. If you don't care about your job and just do the minimum to get by, go flip burgers. I'm not saying that you can't or shouldn't be a smart-worker and flip burgers. In fact, I'm sure I could scour the burger joints, facilities services, and other less prestigious lines of work to find many smart-workers, and I wish I could--Lord knows they deserve a better-compensated, more respected job than a lot of the slobs I've worked with. What I am saying is that these short-term lazy types would have a lot less impact on the rest of us if they were constrained to flipping burgers; heck, our whole economy would likely be better for it.
If you haven't heard about DevDays 2004, you need to. Whether you're a Windows forms developer or an ASP.NET developer, you need to get in on this event. The Web Track is going to be a very focused look at securing web applications in ASP.NET and is something that we all need to know (and be implementing in our applications!). I'm looking forward to presenting a session on “Defenses and Countermeasures: Securing Your ASP.NET Application from Hackers“ there in Tampa, and there are tons of local experts around the country whom you can catch in your neck of the woods.
You should also be aware of and watching DevDays Bloggers, which is sure to be packed with extra info that'll help you prepare for and continue to learn from this year's DevDays.