October 2003

I sat one day, arriving a few minutes early, at 7:48am.  I’d spent the last few days tearing through tons of code and schema designs.  I finally was at a point where the product was working.  I looked across to my fellow associates’ seats and smiled.  Today I was proud that I would have this to present to them once they arrived.  My boss had not arrived yet either, but I was going to be very stoked to present this to him.  Just a few days earlier I had been reprimanded for not cranking down hard enough and getting this done.

I’m going to roll this story back to when it all began.  I had just finished up assisting with another major software creation application and a new assignment had come up.  The company had been dumping large cash on paper trail work flows for years. With technology where it was, that was just not needed anymore.  What we needed was a good clean, easy to store, easy to track, easy to report on form processing work flow application.

With that boss man and I met to gather some requirements that this application needed to cover.  I needed to store the forms, I needed to be able to process and recall forms at any point in a workflow process, and I needed these to be able to be signed off over long segments of time.  I look back and think, “wow, WCF, WPF, and WF are all based entirely around this type of enterprise software application”.  Of course, the technology that was up for use was ASP.NET 1.0, not even 1.1 yet.  We had some Infragistics Controls and of course SQL Server 2000.  There was also the user repository that had been created within SQL Server 2000 to compensate for Windows NT 4.0’s lack of metadata storage on users.  The boss man and I sat down and started ironing out the technology path, ideas, and where we wanted to end up with this application.

After the meeting for the initial layout of the applications purpose I set about laying down some concrete database schema ideas, application design plans, and creating a scope list of exactly what I was going to create.  I also did some meager price and feature set comparison of tools that where on the market at the time.  Nothing really played out to do what we wanted to do at the price point we where willing to pay.  Thus I started designing and coding.

My first rendition was placing actual documents, image documents, and some other random files in the database repository, but as time went on this wasn’t going to well.  It seemed like the logical thing to do, make a document, get the signature, put it in the repository, keep track of it.  There where however all sorts of problems with the integrity of the documents and that problem didn’t even touch on the issue of when one got to the point of a few hundred thousand documents in the database server.  It got real nasty real fast.  Fortunately this didn’t take that long and back to the drawing board I went.

My next rendition, after a good discussion with the boss man, led me into the realm of dealing with XML documents, and keeping the XML stored that had the data separately, and the XSL visual markup separate from that.  I ended up with the visual markup, the actual xml form document, and then a signed copy with just the data in it.  The forms documents along with their respective visual markup where historically kept at each change so that each could be used to display any signed copy with data in it at any time.  It was a grand idea.  The only problem was designing the nasty XML and getting all those forms transferred into the system.  The only tools I had to do this with was Visual Studio and notepad.  We didn’t have anything cool like XML Spy so I dove into an endeavor to copy the various word, excel, pdf, and other documents into the XML forms schema that I had created.

After a diligent month, I was able to get all the existing documents, and build an interface for adding future documents.  Finally, I was done.  I did some testing.  This was before unit testing existed to me, so I went clicking away like a mad man.  Hoping to iron out any issues that might come up.  A few things where busted, but I got those wrapped ASAP!  Thus we’re back to the beginning of this short story.

I sat, pondering all of this, and just surfing some information and development sites.  This app was wrapped.  Finally I heard him greet a cohort out in the hallway.  He breached the door and I pounced with my great news!  “Hey Boss Man!  I’m done!”, I blurted out with exuberance.  He looked at me with a grin and stated, “it’s about damn time!”  We both kind of laughed and he came in to check out the app.  After a thorough display of the features and the interface tool for making documents, he seemed content.  He gave me one of those boss man smiles and walked back into the main office space.

Later that day he told me the presentation with the boss’s boss man went well.  They where happy with the tool.  Later that day he proffered mixed drinks at his house for the whole dev gang (He had a penchant for creating mixed drinks and had a whole stocked bar at his house).  At that point, I knew for sure, that the application was done!

One of the things I really got ingrained in my habit while working at Bank of America was the respect of other people’s time.  Especially in fast moving projects this is a very important thing to practice.  While working at BoA one could literally be let go if they did not respect other people’s time when scheduling meetings and other such time consuming, yet much needed, work related events.  I was digging around some material I had found in storage a few weeks ago and it got me thinking about this.  The core facet of this trait is simply, “respect other people’s time“.  Everything about one’s work habit within a team should encompass this.  The core idea behind this trait is, “empowering the individual” and is simply part of a “meritocracy” based environment.

• Don’t be late to a meeting.  Not even a few seconds.  The only acceptable arrival times is at the scheduled time or before.
• If you’re going to be late notify well before the meeting and be sure to give an ETA so an accurate rescheduling decision can occur.
• Make sure to send any notices for a meeting well in advance of a meeting.  (2-4 hours minimum)  Otherwise expect nothing more than a quick conversation of 5 minutes or less.
• Take into account other people’s meeting schedules.  Don’t double, triple, or otherwise book people.  Even if you’re the boss, don’t do this without notifying the person of their priority, or asking what their priorities are for the day.
• Make sure to have clearly defined topics and understand the objectives and goals of the meeting.  Do NOT go to a meeting and just start conversation on a “cloudy” or unclear topic.
• Do not surpass the scheduled meeting time.  If you think you need time, schedule as much of it as you believe will be needed to cover the topics.
• Preferably take meeting minutes and designate a specific individual to meeting minutes.
• Make every attempt to stay on topic during a meeting.  If one leaves topic, have a designated topic watcher to maintain the flow of the meeting (the meeting minutes person usually is good at this).

Those are the summarized meeting points for the material I found.  I’ve blogged because I think this is a highly underrated trait, often unnoticed these days, and even more so unnoticed on the west coast for some reason.  However the amount of productivity lost to non-punctual, unscheduled, off topic meetings is massive.

del.icio.us Tags: meet, meeting, productivity, meritocracy, merit, individual, empowerment, empowering, respect, people, bank of america, trait, habit

Technorati Tags: meet, meeting, productivity, meritocracy, merit, individual, empowerment, empowering, respect, people, bank of america, trait, habit

In many ways describing what is and is not an actor is best left to project specifics and personal experience.  Below I’ve outlined a good rule to follow when trying to figure out if a “thing” is an actor or not in a use case.

Sometimes I hate stupid statements like that.  More secure than “what” Linux is what I’d like to know.

But to the point, some articles printed that I picked up from Steven Smith‘s entry on the topic.

• Usage stats of operating systems
• 90 day report of security vulnerabilities

I’ve been on a run about coding standards lately, reading about them, figuring out which to follow and which to not follow.  Well one thing I had not been looking at much was database standards.  I realized I had a bunch of questions;  how do you name tables, according to what schema, are views concatenated names correlated to their respective tables, do stored procedures have verb noun correlation, do functions get named similar to stored procedures, do we prefix database objects with shortened abbreviations and such related to what they are?  Well I’ve started keeping a list of things I’m starting to prefer when designing and building a database.  Enjoy…

Database Standards :: Build 0.01

1. Table Names should be named to a singular of the data object they hold.  At least when utilizing a domain or business object pattern approach to development, for readability of generated code (yeah, a standard based on generated code!) tables should be named singular.  Examples would include;  Car, Bike, Train, or if one had more granular break downs Wheel, WheelType, WheelTire.
2. Database objects should use casing just like code objects.  So if there is a Car Object that has Wheel Objects and a Wheel Type Structure the tables in the database should be named accordingly with the same casing;  Car, Wheel, WheelType.
3. Artificial name spaces should be setup for database objects.  If a table is directly related to a particular table, such as a Wheel having a type in the WheelType and a tire type in the WheelTire table, each should be prefixed as written here with Wheel.  This assures easy visual coordination of tables that are closely related via domain logic, business logic, and via referential relationships within the database itself.
4. If one goes with the base table pattern (similar to using base classes) and sets up a base table to hold vehicle information the base table should be post-fixed or pre-fixed to the associated tables.  Thus we would have VehicleCar, VehicleTrain, or VehicleBike based off of the Vehicle base table.  The reverse would look like CarVehicle, TrainVehicle, and BikeVehicle.  I prefer the fore-mentioned naming convention but the later convention is more readable in my opinion.

So far, that’s what I got.  If I get to deal more with database standards I’ll definitely post them here.  Anyone else have ideas, notions, arguments, or opinions on what should change, be added, or deleted?  Submit a comment.