Archive for the ‘Programming’ Category

Loveletter Worm

Yesterday was the tenth anniversary of the Loveletter (ILOVEYOU) worm. This was the first real virus/worm that I ever experienced that actually took down a mail server. It was also an early, widespread, damaging worm. At the time, I was in my colleague’s office (he was the network guy), and he got an email. He looked at me and said “Why would Gary send me a message saying ‘I Love You’”? A few seconds and 5 similar messages later it dawned on him what was going on, he ran down the hall to the server room and hard-powered off the Exchange Server. Later we determined only 79 accounts got the email before he stopped it. It still took two days to get the mess cleaned up.

What really struck me about this was the code of the worm. I was doing classic ASP programming at the time, so I was pretty conversant with VBScript. I printed it off the code to check it out (see a description of what the code does). I was really struck by the fact that I understood what they were doing, and it didn’t even seem that hard. It was a real watershed moment for me as a developer, I had reached a point of understanding with that technology; it validated my progress as a developer.

The Love Bug: A Retrospect

Posted on:
Posted in None, Programming | Comments Off on Loveletter Worm

Link Love

I’ve run across some great blog posts lately, and decided I needed to share and keep track of them:


Cultivate Teams, Not Ideas at Coding Horror. I am totally with Jeff on this one, I learned this a while ago. I’ve taken my last two jobs based on the quality of people working there, not the work that they were doing. I love the quote:



In software development, execution is staying on top of all the tiny details that make up your app. If you’re not constantly obsessing over every aspect of your application, relentlessly polishing and improving every little part of it — no matter how trivial — you’re not executing. At least, not well.


I want to work with folks that feel this way about the work they do. Quality matters, and even more in my profession as a consultant. Quality work today gets me more work tomorrow, I can’t afford not to write top notch code and deliver quality solutions. Few things really upset me as much as shoddy work, whether out of ignorance or laziness. If you are a professional, there is no excuse for either one.


My co-worker David Giard (the host of Technology and Friends) wrote a very insightful post about being a programmer, It’s not easy, so don’t pretend it is. I agree with Dave 100% that we are undervaluing what value we provide with our skills. I pledge along with Dave to take the word “easy” out of my vocabulary when talking about the work I do. As someone who has to estimate work, I understand the complexity of what we do and struggle to communicate that to clients, and I think what Dave describes contributes significantly to that problem. End users/clients can’t easily see the complexity of what we do (“it’s just a form”), and can’t understand that adding “one extra feature” may actually triple the complexity of the solution, because our long-term message to them has been “it’s easy”.  This actually relates to what Jeff said about teams as well. Good teams care about the quality of their work, so don’t minimize what you do to your clients or users, show them the quality of what you can do.


Lastly, I want to point out the terrific blog written by an ex-coworker of mine, Bob Kreha. While Bob does not write about technical topics per se, his observations about management really strike home as a person who is frequently managed (aren’t we all?). I particularly enjoy his insights into leadership, since I view myself as more a of a leader than manager, even though I technically may be a manager. His post BFF’s has a quote that strikes a particular chord with me, talking about a manager’s relationship with his subordinates:



So if you want nirvana, start with commitment, fairness, shared credit, transparency and vision.  You might be surprised where you end up…


I can’t tell you how many times I struggle with my job because the management above me is not clear enough on where the collective “we” should be going. I frequently think “help me help you” when I am dealing with management. Everyone has an agenda, some folks more than others, but really I wouldn’t be working at a company if I didn’t think we were working toward the same goals. But with management it often seems like they are not on my side over some of the most petty issues. Really, due to a lack of transparency and shared vision, I think it’s petty when really it may not be, I just don’t understand the scope of the issue (or other pressures from management higher up) because no one is sharing. When it feels like maybe we are not on the same team, quite possibly someone is on the wrong team. The bottom line is, tell me where we need to go, I’ll help us get there. If you don’t tell me, I can’t help.


I’ve been pretty dark from blogging for a while, it’s good to get back into the swing of things. I’ll try to follow up with a more technical post soon.

eBooks on CodePlex

Wriju has a gread roundup of eBooks/guidance available on CodePlex.

Laws from DDJ

Got my new November Dr. Dobbs issue today. The back column “Swaine’s Flames” has reminded me of some programming “laws” that I have seen before. I have added my own corollaries for each:

Kernighan’s Law: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

My corollary: “The developer who’s code that you inherit believed they were twice as smart as they really are.”

Eagleson’s Law: “Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else.”

My corollary: “You can recognize that you have written code to solve a particular problem but will be unable to locate the specific instance you recall.”

Posted on:
Posted in Programming | Comments Off on Laws from DDJ

Design with Users In Mind

We all spend lots of time delving into the technical aspects of our work, but don’t forget who we are creating all these wonderful apps for. You need to design your apps to work for the users, not create apps that the users need to work to use.

Required Reading: Four Modes of Seeking Information and How to Design for Them

Exception Handling – Too Much ‘Faith’

A recent post by Lamont Harrington asks about the proper methods for exception handling:

“Should exceptions be bubbled up the call stack and be unwound by a “global“ exception handling layer and logged appropriately, or should some form of exception handling happen at the point of code execution? “

I think a proper design does both. There are cases where the exception can be handled in the procedure where it occurs. Good defensive coding trys to identify as many of those cases as possible and handle them (Actually, good requirements and design should identify many of these situations). Obviously, you cannot foresee all circumstances so the “global” handling is necessary as well. Personally, I don’t like to repeatedly re-throw an exception up the call stack because the procedures don’t handle it specifically, I would rather let it bubble up on its own and handle it at the end. Re-throwing tends to bury the real source of the error when you are trying to debug a problem in a multi-tier application.

I have to add a plug for the Exception Managment application block. It has been very good to me so far.

Posted on:
Posted in Programming | Comments Off on Exception Handling – Too Much ‘Faith’

Business Objects Dead?

There a fascinating discussion going on at Tim Sneath’s blog about the functionality of the business layer moving to compiled stored procedures in Yukon. At least in my project, we have been doing that very thing and struggled with the n-Tier issue as a result. In our case, the database is Oracle 8i, and the application is/was ASP, which we are now converting to .Net. We have some very complex business logic encapsulated in PL/SQL stored procedures. There were two concrete reasons for the decision:

  1. The amount of data that would need to be transferred was huge.
  2. Oracle is more efficient than ASP code at many of the operations involved.

With ADO.Net, some of the ineffieciency may be addressed, but the database is designed for efficiency at certain operations that ADO.Net won’t be able to match.

We did not need to approach this from a scalability issue, as the app receives hundreds of hits per hour, not thousands or more. I still think it will scale OK as your business objects will have much shorter life spans and you can still pool and queue database connection objects if needed due to long-running stored procedures.

Posted on:
Posted in Programming | Comments Off on Business Objects Dead?