What I Learned Today

Access vs. the Recursive Query

Today I was creating a tiered billing system (again in Access). The
natural solution in a (forgive the pun) normal database would be a
recursive/hierarchical query (each tier for a client has a parent tier
or is the root). Before even creating the structure for this query, I
was pretty sure that access wouldn't support such an advanced (and
until recently, also unavailable in it's big brother - SQL Server)
feature. A quick google comes up with this MSDN article from the
Access cookbook:
http://msdn.microsoft.com/en-us/library/aa188216(office.10).aspx.

The article explains a very manual way to query against a "self join"
(basically, make n copies of the table depending on how deep your
hierarchy is). This is, of course, *not* the correct way to write a
true recursive query, but it does give me a little bit of insight as
to why access/vba developers think the way they do. They are (to a
certain extent) trained into overly-simplified, somewhat limited
solutions.
They are the epitome of "good enough" solutions. Which, in a lot of
scenarios, is fine.

In the end, I added an "Order" column. Ugh.

What I Learned Today

I've been inspired by Seth Godin's "Is effort a myth?" blog entry
(http://sethgodin.typepad.com/seths_blog/2008/10/is-effort-a-myt.html)
to try and follow his "effort diet". The hardest part for me is going
to be the writing part, so here goes.

This will likely start as a series of posts on Access (since, ugh,
that's what I'm working with right now).

I'm not a huge Access fan, but I think it's a great tool for single
user/semi technical/entrepreneurial type environments.

I've spent the past week working on modifying a billing application.
Something I learned today:

The DoCmd object has a ton of handy little shortcuts hanging off of
it. In a non access environment, you'd have to write DTS, maybe some
API calls, and do a lot more scrubbing to replicate the functionality
in any of these methods. The one I used today is DoCmd.OutputTo.
This lets you open a "Save As..." dialog to save some dataset
(probably works for reports, too).

DoCmd.OutputTo acOutputQuery, tempQueryName, acFormatXLS

Where tempQueryName is an ad-hoc query I created based on user input.
Cool beans! It doesn't get much simpler than that. Just goes to show: Access isn't always the devil.

I'd still rather be using a real tool though :-p

(though if there was a nice IDE and ReSharper for Access, not sure
that I'd be nearly so confident in that statement)

Communication Styles & Leadership

A continuous point of musing for me is communication/learning styles.
When I was in middle school, one of my teachers, Mr. Egan, spent part of a day explaining to us that different people learn in different ways. We learned that there are three major learning styles: visual, aural, and kinesthetic. You learn by seeing, hearing, and doing. What is interesting is that most people have a strong subconscious preference for one of the three. For instance, I am terrible at receiving verbal information. I constantly lose track of the conversation and find my attention wondering.
Writing software is a team sport. You almost never write commercial software in a vacuum. There is always a customer, boss, or other developer who you need to educate/train/convince about ideas. One of my biggest challenges has been how to get what’s in my brain across to another person. Whenever I run into these problems (they have been much more prevalent since I’ve been in leadership roles), I think back to Mr. Egan’s class and remember that not everybody learns like me or thinks like me. I use that simple lesson to help guide my communication. These are the guidelines I follow:

• Try to use at least two of the three communication styles (use all three if the point is particularly important)
• When communicating visually, use a mix of written and non-written communication (I hate graphs and pictures, but these are key for some people to visualize a concept)
• Even though your audience won’t absorb all of the communication-types equally, repetition is a key strategy for retention (so seeing/hearing/doing it more than once will hopefully make it stick)
• Be patient! You’ll almost certainly have to try more than once. Of course your ideas already make sense to you - you made them!

A Test-Driven Development Manifesto

I have been asked to codify my beliefs and practices when using the Test-Driven Development methodology. One of the things that I like about this methodology is that it is fairly easy to describe.
I believe that to practice Test-Driven Development is to do the following things in the following order:
1. Transform requirements for your task into unit tests.
2. Verify that all of these new tests fail (since none of the requirements have been met yet).
3. Start designing my solution.
4. As I add functionality that wasn’t described in step 1, I will add unit tests first.
5. I am done with my task when all of my unit tests pass.
6. Maintenance: Whenever a defect is logged against my code, start by reproducing it with a unit test. The defect is fixed when the unit test passes! (this also ensures that we don’t re-introduce the same defect later.
Ideally, all execution paths in my code will be covered by a unit test. Again, this is a huge win for maintenance since I can write new features and refactor existing code without being afraid of breaking any existing features or defects (refactoring is complete and successful when all of my unit tests pass).

Statement of Purpose

I believe that in order to be a good software developer (or technical resource in general), one must be able to communicate in an easily understood manner. Unfortunately, dental work is usually preferable to writing for most developers (myself included).
I believe that the solution to this problem is simple: practice. I think that writing (indeed all communication) is a kind of intellectual muscle that needs to be excercised regularly if it is to be relied upon.

It is my goal to use this blog as a sort of arena in which to practice my technical writing (and get a few things off my chest at the same time).

Because I am a professional software developer and sometimes architect, expect to see most of my articles written around software development practices.