Reflection

On Janurary 5th, 2010 I start a new job.  I've been reflecting on the past 6+ years at my former job, mostly around what to write on the exit interview paperwork.  I think I've got some pretty honest truths to share with who ever reads it.

As a Software Development Manager one of the biggest changes the company must embrace is listen to your customers.  More then that, the employees of the company must interact with the customer.  I'm not suggesting that they aren't talking to customers but I am suggesting that there isn't a lot of listening and consideration of what is being said. 

I have seen a lot of features released that really have little or no value to the customer.  The feedback that does make its way to the software team is rarely what the client asked for.  Any context related to the problem is either withheld or ignored and useless information.  This is the wrong approach!

The folks building the software need the opportunity to interact with the customer directly.  I'm not saying that Software professionals should be account managers or maintain client relationships.  What I am saying is that Software professionals should have the opporutinty to interact with the customer so that they can build the best solution for the customer.

The final point I'd like to make is that simple is better.  Build the most simple easy to use feature you can, put it infront of customers and then listen to the feedback and adjust accordingly. 

With that I wish you all a Merry Christmas and a Happy New Year!

type = 1

I hope this can serve as a learning experience for the less seasoned readers or at least a bit of humor for the well seasoned.

Several years ago in a design review a developer was given feedback about a particular table design.  The design was fairly simple.  It looked something like this:

In the design reivew, the developer was instructed by his manager to modify the design to the following:

The design was modified as instructed.

The impact was that anyone writing a query starting at the top of the structure would have to remember to use 'type = 1' or risk displaying incorrect data.  As it turns out even the original implementor frequently forgets about this requirement.  Numerous bugs have been and continue to be caused by this design due to frequently missing the need to specify the type when joining to this table.

Update on 2010-05-15 16:23 by Sam Butterworth

A fiend and colleague recently linked to my original type = 1 post which got me thinking about a potential solution for the problem.

A fairly simple and hopefully not too painful solution would be to create a SQL view for each type.

For example, MyTable2Parent and MyTable2Child.  The view would contain the type specific qualifier and allow developers writing other queries to explicitly join to the desired entity.

This change would make the SQL statements easier to read as well.