Here's one of the first brainstorming diagrams I've come up with.  It's a break out of transportation modes.  I wonder if I've missed any?  Each mode is broken out to the amount of persons the respective mode can carry.  This information will then be broken down at some point.  Right now I'm off to some lively debate at Life of Riley's (it's in Portland, so if you're here, come and have a drink).

• Original Brainstorming Visio File 
• Original Brainstorming PDF File

So I've been planning to start a project on the side, just for fun, that I could really showcase some of my interests and skills all at the same time.  In other words, from a high level, all the way down to the nitty gritty example, build a fully functional application.  I got to thinking, what really truly interests me enough to stay focused on to develop an application for that I could use to present enterprise application demos with?

Well, I've kind of shut my "Transit Slueth" blog down for the time being, maybe permanently so what better topic to use. With that in mind I will be posting some brainstorming diagrams and other ideas on what I intend to develop.  It will be related to transit in some way, but I'm not 100% sure yet.  Feel free to pop ideas in the comments section.  Until then I'm off to brainstorming a problem to create a solution for!  (It's kind of funny, I usually don't create the problems, I just create the solutions!)

Project Manager Definitions from Sedition.com

The important ones:

scope creep
    hostile feature negotiation.

slippage
    retaliation.

...and the scary events of a software project.

Some of the key scary elements of a software project:

• Management has renamed its Waterfall process to Agile Waterfall
• Your eldest team member references Martin Fowler as a ’snot-nosed punk’
• The SCRUM master doesn’t really care what you did yesterday or what you will do today
• Your best developer only has his A+ Certification
• You do not understand the acronyms DRY, YAGNI, or KISS; but you do understand WTF, PHB, and FUBAR
• Every milestone ends in a dead sprint
• Project estimates magically match the budget
• You get into flame wars if { should be on new line, but you are impartial to patterns such as MVC
• The company hires Senetor Ted Stevens to give your project kick-off inspiration speech
• Your boss expects you to spend the next 2 days creating a purchase request for a $50 component
• The sales team decreased your estimates because they believe you can work faster
• Requirement - Rank #1 on Google
• Management can not understand why anyone needs more than a single monitor
• Your development team only uses source control as a power failure backup system
• The project code name is renamed to ‘The Death March’
• Your teammates don’t refactor, they refuctor

...and the scariest thing to see on a software project?

The return of the Waterfall Process.

On the InfoQ site today I've taken a listen to the "Agile Styles: Lean and DSDM" by Jean Tabaka.  DSDM was introduced by a group in Britain.  Jean gives a decription of where it came from.  Then the meat of the topic is brought up.

DSDM = Dynamic System Development Method

Jean goes on to describe the topic in some detail, laying out the bullet points.  I listened to a few others but cut those short as they weren't as pertinent to what I am currently working on or interested in.

The next one I did listen to that was worth writing about was the Chris Anderson on WPF interview.  This gave some good history on why WPF was created and what the intentions are behind the platform.  The two coolest questions (and of course answers) that I dug where;

• Is there a standardizing process that's happening at Microsoft in regards to controls?
• Where does Avalon start and Areo end?
• Where does the intersection occur between rich and web clients?

He goes on over more than a few more questions.  Overall this is a pretty decent interview.  One of the last questions posed is about MVP/C and how Avalon and WPF are going to make it much simpler and useable instead of the "high science" that it currently is.  I believe this is good mostly with only a few negative points.  I look forward to Model View Presenter/Controller work with WPF in the near future!  It sounds like it should rock in comparison to some of the mundane effort that is required with current MVP/C technology from Microsoft.

So go and check em' out.  They're interesting and easy to listen to while you're working (if you can multi-task)

I've been doing some CAB & MVP/C work for almost a year now on and off.  With that I've gone digging for a lot of related topics.  One blog that I stumble onto regularly, and also have book marked now, is Jeremy Miller's Blog.  Recently while digging through his blog I came upon the entry titled "OO, TDD, and Agile processes are all good, but better get the basic things right too", which then for some reason led me to the entry "How I'm, sigh, going to become a better developer".  This later entry got me thinking about what I'm doing to become a better developer.

The first thing, which I'm really good at to begin with, but always can use improvement, is communication.  When I mention communication it isn't just getting one point across from myself to another person.  I also mean being able to read other people, understand how they learn, what "hats" they wear in an organization, understand how they fit into the communication from meetings to office cooler chat.  Communication doesn't stop at the spoken and written word, it goes far beyond that.  Some might call it politics, some might call it haggling, and some call it other more vulgar things.  The fact is, everybody gets frustrated with the various levels of communication.  I'm attempting to get a grasp on these things, and get faster at reading people, better at understanding learning patterns, and improve my mentoring ability.

The second thing is to generally improve my architecture knowledge.  From a hardware perspective I've always been very strong, but from a 100k foot high view of software in large enterprise environments I've always felt a little overwhelmed by the layering, approaches, and generally open ended endless ways to "connect" software to other software in the enterprise.  I've read through at least a dozen books, including Patterns of Enterprise Application Architecture by Martin Flower and fellow crew.  Of course I make every endeavor to keep up with his material on his site and other similar to his also.

The third thing I've started doing is reading as many blogs that I can humanly read during the course of a day without eating up too much of my stress release and personal time.  Some of the key blogs I've been reading can be found at Code Better which has Jeremy Miller's Blog and Jean-Paul S. Boodhoo.  Others that I enjoy include;  Brad Wilson, Wyatt Preul, Phil Haack, Sandcastle, Mladen Prajdic, Tom Hollander's Blog, and .NET Slackers.  One other site I've been reading via RSS is InfoQ.  InfoQ is an awesome site with absolutely great material.  If you do Java, .NET, Ruby, SOA, or Agile you need to keep up with this site.

I kept reading these various blogs after reading Jeremy Miller's Blog entry and realized something, almost all of them had something in common.  They listed something besides software related things to start doing to help them become a better developer.  Even though some might consider it a bit unhealthy, that leads me to my obsessive nature of learning as much as possible all the time about all sorts of things.  Which in turn places me right at number four.

 The fourth thing is that I will continue to read up and learn about history, transportation and transit, music and specifically guitar, listening to great music, catching live bands, meeting new people all the time, having fun, traveling on the train, continue racing my car, and living a walkable-carless (except for the racing) life, writing lyrics, and generally, having a good ole time!

So now the question is, what are you doing to improve your developer skills?

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.

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.