Aug 17, 2004 | Software Development
My latest ebook “Telling Time with .NET: Build your own Internet time component” is now available.
I’ve always wanted my own “Atomic” clock, and even though self-updating clocks have been available for years, I never got around to owning one. Internet time servers make it possible to come close though.
I ended up using a number of interesting techniques to improve accuracy, and while advanced .NET developers probably won’t learn much from this ebook, I think it will prove an interesting read for beginning and intermediate developers. Topics covered include .NET sockets, inheritance, code access security and regular expressions.
Aug 17, 2004 | Society & Politics, Software Development, Technology
Like many computer professionals, I?m often asked for career advice for those considering entering this field. Given the recent drop in the number of students entering college with computer science majors (see the May 2004 issue of Computing Research News), offering good advice is more important than ever. Here’s my version.
You had better like change.
Many careers require that you keep studying to remain current. Doctors and lawyers have to stay on top of he latest treatments and legal precedents. Realtors study the latest regulations. Contractors their building codes. But what makes computer science intense is that not only do you have to keep learning technology that is changing at a rapid clip, what you previously knew becomes obsolete.
Most developers like to learn new technology, or at least play with the latest toys. Sometimes we get so hung up on new technology that we don’t think clearly about the consequences of that technology (a topic for another time). But it is important to consider some of the consequences of the rapid change that occurs in this industry.
Because what you know will soon be obsolete, you’ll spend much of your career under intense pressure to stay up to date, the underlying fear being that if you don’t, you’ll end up unemployed and pathetic. This fear, though rarely admitted, is quite common, and can be a source of stress, which may not matter to you now, but is one of the reasons people leave the field. It’s like the Red Queen says in “Through the Looking Glass” – you have to run as fast as you can just to stay in place. You have to run even faster to get anywhere. Burn-out is a problem.
Being technologically savvy isn’t enough.
Being an extreme programmer is all very nice, but if you want to succeed in this industry it’s not nearly enough. You may have heard the political and economic pundits on the news talking about the “jobless recovery.” Bush is stressing because corporate profits are rising but employment is not. Kerry promising to create jobs, but it’s not clear what he can do. Why? Because our economic system demands that businesses become more productive, and more productive means (among other things) doing more with fewer people, or doing more with cheaper people. We’re all familiar with how technology eliminates some jobs – ATM machines reduce the need for bank tellers, self service pumps allow gas stations to be staffed by a single person. There’s no clear sign of this happening to software developers, in the sense that few software development tools are so sophisticated as to replace programmers (though it’s coming – automatic code generation is a fascinating topic). But it is possible to replace expensive software developers in the U.S. with less expensive software developers in other countries. How big an impact this is having, and how big an impact it will continue to have is subject for debate. But it’s too significant to ignore.
And even if productivity isn’t an issue, the inevitable tides of our economy will be. You will at some point in your career be dealing with a tight job market. And it’s not your technological skills that will determine how well you succeed at those times.
It’s your personal skills that will count. How well do you communicate? You should know how to present your ideas both to individuals and small groups. Can you write clearly and somewhat grammatically? Do you come across as confident in yourself and your abilities? Do you have leadership skills (that often translate into management skills)? Are you responsible? Are you a nice person to have around (or at least not completely repulsive)? Yes, there are those who are so technologically brilliant they can get away with caring just about technology, but for most of us these other skills are essential.
So, as you go off to college, don’t let your technical classes get in the way of getting a good education. Take a writing class. Take a class or get involved in an activity that forces you to do some public speaking. Do some drama or improv. Join a club. Do some volunteer work. Do some tutoring. This kind of experience will have long term benefits to your career that you wouldn’t believe.
Take CS for the right reasons
The best technology professionals are almost without fail the ones who entered this field because they are fascinated with technology. We like to play with the latest and greatest toys. We share an underlying faith that technology can be used to solve problems and make the world better. In fact, we’re sometimes so blinded by technology that we fail to consider other factors in our decisions (like business and economic factors, social consequences, etc.) – but that is a subject for a later time.
The important thing is not to go into CS just because you think it’s going to make you a lot of money. Sure, some software developers got rich in the dot-com boom, but even then most of us ended up with at least some stock that ultimately became worthless. Choose this major because it’s fun, and you’ll end up having a great time. You’ll meet lots of smart people, most of them pretty nice. And when the inevitable stress and problems occur, you’ll at least know that you’re spending your days doing what you enjoy the most.
Do you have additional recommendations for future CS majors? Please post them (remember, comments on this blog are moderated and won’t show up right away).
Aug 16, 2004 | Software Development
Recently a software developer came to me with a fascinating argument. He claimed that VB .NET is a poor choice for software development because it was more RAD than C# (RAD = Rapid Application Development for those who have forgotten), and that RAD tools lead invariably to bad code that is unsupportable and more costly in the long run. He based this argument on extrapolation from VB6 days, where VB6 was (of course) very RAD, and this resulted in copious amounts of bad VB6 code.
Now, there’s no denying that lots of very bad VB6 code was written. But does RAD really result in bad code? Are RAD tools really best for quick prototyping and “throw away” code?
This question is especially important as we approach Whidbey, where much of the differentiation between C# and VB .NET are in the area of RAD features, with VB .NET gaining edit and continue and native support for the My classes, and C# gaining refactoring.
To answer the question, let’s agree first that increased productivity is a good thing (in fact, in an age of increased offshoring, it’s arguably critical). But how do you measure productivity? Is it in lines of code per dollar spent? That’s a fair definition – but only if you qualify it. The lines of code has to have a specified quality level, and dollars spent has to include the lifetime cost of the software, not just the initial coding and testing.
RAD tools clearly allow you to write more code faster. But is it necessarily bad code?
I think not.
The reason that so much bad VB6 code was written was not because VB6 was RAD, but because it was easy. In fact, VB6 made writing software so easy that anyone could be a programmer, and so everyone was. Doctors, Lawyers, Bankers, Hobbyists, Kids – everyone was writing VB6 code with little or no training.
Now, I don’t know about you, but I still have copies of a few of the programs I wrote when I was just starting out, before I’d actually gone to school to learn a thing or two about software development. There was some BASIC, some Pascal, and looking at it now, it’s all pretty ugly.
So let’s get real. Bad programmers write bad code. Good programmers write good code. RAD lets bad programmers write bad code faster. RAD does NOT cause good programmers to suddenly start writing bad code.
RAD tools can make a good programmer more productive, because they speed up the coding process without compromising the level of quality that a good programmer is going to achieve.
I haven’t yet completed my comparison of C# and VB .NET for Whidbey (I’m in the early stages of updating my eBook “VB .NET or C#: Which to Choose”), so I can’t tell you yet which one is likely to be more productive. But if it turns out that one language is, in fact, more productive than the other, that will be a major factor in the results.
And the bad code is?
And by the way, it may be time for us to reconsider our definition of “bad” code as well. It’s the beautifully structured, object oriented, “good” C++ code that’s giving us all huge amount of grief due to security problems (buffer overruns, memory leaks, games with pointers, etc.). Barring use of Win32 API calls, VB6 was remarkably immune to all of these problems. Makes you wonder who’s been writing the bad code, doesn’t it?