Wednesday, October 27, 2004
The time is t - 12 and counting. I am sure you have all been there. You have planned out all of the tasks. You have worked hard to meet the deadline. You felt in control of the iteration. You knew you had this one nailed. But then, as the hour of deployment draws near, it seems like a cruel trick has been played. Suddenly there is an insurmountable amount of work left. Are the tasks multiplying? It seems like as each loose end is tied up, two new ones pop up as if some evil magic spell were cast on the project. It is in this hour, when the odds sometimes seem overwhelming, when I am beginning to forget what the outside world looks like from the long hours of staring at my laptop screen in my cubicle, when the pressure is on, that somehow I feel that I do my best work. Am I a masochist? I have decided that either I perform well under pressure, or I am delirious from a lack of sleep. Do you know the feeling? Where after staring at a problem for hours the solution appears to you so clearly it is as if it were the result of pure genius and you feel completely satisfied with the world…then again, maybe even a hack looks like an ingenious solution when time is short.
Tuesday, October 26, 2004
Monday, October 25, 2004
Let’s take architecture, for example. When architecting a solution, there are many roads I could take. I could spend 5 minutes on the architecture and hop right into the code. I could spend weeks on the architecture, fashioning a framework made of steel, a framework where I have abstracted every piece that may be shared, a framework where I have carefully planned the separation of the data layer from my domain layer so my customers could use XML, Oracle, or SQL Server as the data store by just changing a setting, and a framework where my domain layer never relies on a configuration file that is specific to a web front end. The more flexible my framework is, the more time that must be spent planning and executing.
The time spent planning a flexible architecture should pay for itself in the long run, when it comes to time spent maintaining and extending the solution. But what if my customer never wants to change data stores? What if my customer only wants to deploy a web solution? How do we determine when the payoffs from planning flexibility are no longer worth it? Can we plan so much that we are gold plating our architecture?
Thursday, October 21, 2004
Java, on the other hand, has a much shorter history. Java was born in the early 90's. By this time, OO techniques were really catching on. It is not surprising that OO concepts were included in the implementation of Java.
While the first object oriented paper was published in 1965, OO did not become widely accepted by the development community until well after the first release of Basic, into the late 80's. In response to OO programming, and possibly in response to the success of Java, Microsoft redesigned the Visual Studio platform into the .Net release that we have today. My question is this: In rewritting Basic into Visual Basic, and eventually into Visual Basic .Net, has Microsoft enhanced an easy-to-learn programming language into a powerful OO tool? Or has Microsoft been trying to fit a square peg into a round hole?
Wednesday, October 20, 2004
I worked for 5 years programming in VB. I struggled with ASP for awhile, too. So when the alpha release of Visual Studio .Net came out, I couldn't wait to get my hands on it. VB.Net was a change from VB 6.0, but I didn't find the move to be too painful. ASP.Net was like heaven compared to the previous version of ASP. I was excited to leave VB Script in the dust and have a full version of VB at my fingertips when building web apps. And the automated state handling in ASP.Net was another leap ahead for me. I have been working with Visual Studio.Net ever since, and I have never missed the days of Visual InterDev or Visual Studio 6.0.
When VS.Net was released, so was this new language written by Microsoft called C#. Within my VB community, C# was dismissed as a Java-wannabe. Since Microsoft has pledged to back VB.Net, we saw no reason to change. All the curly brackets and semi-colons gave me the shivers, anyways.
So last February when I decided to move to a new company, and my new company is a C# firm, I swallowed hard and cringed as I embarked on my adoption of the curly brackets, case sensitivity, and semi-colons. Thus was born Val the C# Gal. Although there are some syntax differences that take time to become accustomed, it has not been a big deal at all. I have not seen anything huge in C# that was missing in VB.Net and vice versa. What I have noticed, however, is that the mentality of the C# group is quite elitist. So why is that? Why do C# programmers so vehemently disregard VB.Net as a viable language? Why do C# programmers so quickly dismiss VB programmers as somehow inferior in intelligence?
I have worked with amazingly brilliant engineers on both sides, and I don't understand why the C# community feels that if someone chooses to continue crafting code in VB rather than porting over to the C# side of the tracks that the VB engineer is lesser for the decision. How do you feel about this?