• Mar
    4

    A Simple Aid to Avoid Email Embarrassment

    by admin

    Yesterday, I was watching one of the podcasts I regularly view, and they mentioned that on gmail there is a feature that will notice if you’ve typed something like “I’ve attached the file you wanted” and clicked “send” without actually attaching a file. If it sees that, it will give you the chance to cancel sending the email. I know this has happened to me several times over the years and has happened to many people that send me emails as well. And it’s always a bit embarrassing to the sender when it happens. But of course most of the times it happens to us we’re using Outlook since that is what our companies use. So of course my first thought is “Gee it’d be great if Outlook had this feature too”. It turns out that it’s really not that hard to add it to Outlook (assuming your security settings allow it). These are the steps that worked for me, your VBA may differ…

    1. Open Outlook

    2. Press Alt+F11 to bring up the VBA interface

    3. expand the project tree on the left to get to the ThisOutlookSession object and open it

    4. In the code window that pops up enter the following (Thanks to the commenters at http://www.outlookcode.com/codedetail.aspx?id=126 for the code):

    Private Sub Application_ItemSend(ByVal Item As Object, Cancel As Boolean)
   If InStr(1, Item.Body, "attach", vbTextCompare) > 0 Then
        If Item.Attachments.Count = 0 Then
          ans1 = MsgBox("There's no attachment, send anyway?", vbYesNo)
          If ans1 = vbNo Then Cancel = True
        End If
   End If
   If Item.Subject = "" Then
        ans2 = MsgBox("There's no subject, send anyway?", vbYesNo)
        If ans2 = vbNo Then Cancel = True
   End If
End Sub

    5. Save

    6. Test it out by opening a new email, typing something like “I’ve attached the file you needed”, setting a recipient, and clicking “Send”.

    You’ll notice that I also added some code to handle blank subject lines as well (another pet peeve of mine).

     

    Update:

    If the change stops working after a restart of Outlook, check your macros security settings. You’ll want to change it from “Warnings for signed macros; all unsigned macros are disabled” to “Warnings for all macros”. Either that, or sign the macro.

    That would have been a follow-up comment, but I can’t seem to post comments currently…

    Posted in Uncategorized | 2 Comments »

  • Feb
    9

    Deconstructing “always” and “never”

    by admin

    How many times has a statement (requirement) like one of the following been given to you? (only to find out months later that there is an important exception that was not given to you):

    • Field X will always be a positive integer! (except for the case where we decided long ago to populate it with “-9999″ to represent something specific)
    • Field Y always needs to be 10 characters long! (except for when we’re dealing with a specific customer, in which case it actually needs to be 11 characters long and the first character needs to be an ‘A’)
    • The user will always need to fill out this field! (except for the case where the user can’t possibly get that information due to the fact that it physically doesn’t exist)
    • The user will always need to fill out this new field that we are adding! (except for if they are editing something that existed prior to the field being added to the system)
    • Noone will ever need to change that value! (except for if they get additional information a month later)
    • The system should never accept an incomplete entry! (unless the user needs to be able to enter partial data and complete it at a later date)

    As I mentioned in my last post (oh so long ago), any time in software development that you hear “always” or “never” while gathering requirements, that should be a trigger to delve a little deeper. These are the kinds of blanket statements that can lead to assumptions being made that may be costly to change later on. As a result, it is good to do as much as possible to break these absolutes (in valid ways) before they make it into a requirements document. Some methods I’ve found useful:

    • First and foremost, if someone says “always” or “never”, make sure you’ve actually got the subject matter expert involved (this is always important for requirements, but doubly so when “always” and “never” start getting thrown around). Each step away from the expert you move, it becomes more likely that someone along the line hasn’t communicated (or simply is not aware of) an important exception case where “always” or “never” breaks down.
    • Turn the statement around. Often times, when given the statement that “X will always be true”, simply asking “so X will never be false?” will get the person you are asking to give it enough thought that the response you get back falls along the lines of “well, there is this one condition…”
    • Brainstorm. Start throwing out ideas for what may break the absolutes. Being able to do this effectively may depend a lot on domain knowledge. Come up with all the cases that could break the “always” or “never” and get them written down. Once you can’t come up with any more, work through and determine which cases are valid and which are not. If a field is “always” required to be filled in, ask whether what is entered into other fields has any impact on that. This is especially true if you are doing something like adding a new field to a screen that already exists and users may need to edit old data that has no value captured for your new field.
    • Write them down. Capture absolutes that are brought up, and review them.

    Now obviously (for a variety of reasons), you don’t want to take this to the extreme of asking “are you sure?” after every statement given to you. When in doubt, capture the absolute and take it back to your team (or a mentor) and ask for their input.

    Tags: , ,
    Posted in Uncategorized | No Comments »

  • Oct
    7

    Client Tenure – Dealing with clients for the long haul

    by admin

    I’m in a fairly unique position here at SEP. For the last seven years (out of the ten I’ve been here), I’ve worked almost exclusively on a series of related projects for the same client. When I say client, in reality I’m talking about the company since the individuals that I’ve dealt with have changed over time. Over the course of the years, there are several things that have come to my attention. Some of these are very obvious in hindsight, but hopefully writing them down may help out someone else that finds themself entering a similar situation…

    • To succeed, it helps to become an expert in the client’s domain. Chances are good that over the course of even a two-year project, people on the client’s side of the fence will change. And chances are good that when those changes happen knowledge will be lost. At that point you start getting questions that are not just “Does the system handle X?”, but “Why does the system require Y to be entered?” When these questions come up years after the original decision was made, it can help to have an understanding of the logic that went into the decision (bonus points if it is documented somewhere that you or your replacement can find it easily and not just trapped in the recesses of your mind).

     

    • “Always” and “never” are often wrong. Make sure that any time you hear these words that you work with the client to think of (realistic) cases that break the rule. There are almost always valid cases that are overlooked at first glance. Sometimes these cases can be expensive to account for later on if they are not planned for.

     

    • On a long-term project, not only will the small requirements change, but sometimes the entire focus will shift drastically. You will almost certainly hear something along the lines of “You know how we said we didn’t care about X at all? Well, it’s just become an important focus for the next year.” Take it in stride.

     

    • Communicate. Build the relationship on a personal level. Make sure that you are comfortable with giving the client both the good news and the bad. Don’t be afraid to discuss tangents that aren’t related to the project at hand (unless the client has given an indication verbally or otherwise that they don’t want to discuss such things). And learn what form of communication is best for the client and for the situation at hand. Emails are great for communicating with a busy client, and provide a written record of what was communicated (in case there is a question), but they lose a lot of context (verbal and visual cues). Know when you need to pick up the phone instead. And know when you really just need to sit down and discuss things face-to-face (no matter how hard it is to get scheduled time).

     

    • Get invested. Take ownership. Work so that when you look back over multiple years you are proud of what you’ve accomplished. Now the tricky part… at the same time you are taking pride, you need to understand that your beautiful snowflake may not be perfect. The longer the project runs, the more likely it is that some underlying assumption or design will be found to be faulty.

    As I said, many of these are obvious in hindsight, hopefully they will be of use to someone (or just as a reminder to me). Oh and some things to keep in mind… you don’t always know ahead of time which projects will turn out to be “long-term”, and even if a project isn’t “long-term” you can still benefit from the above.

    Tags: ,
    Posted in Uncategorized | No Comments »