Well, around 14 months ago, I started on a journey to understand the SAS dataset so I could read and write one independently. Originally, I needed the functionality for a client but it became an obsession to figure it out. Client work and personal matters interfered non-stop but I have finally written my first SAS dataset using C# and .NET.
It isn't pretty (no data is in it) but it is a dataset and that is what matters. Putting data in is minor so I am not concerned about that.
A lot of effort still remains to get it all worked out but I am happy to be at this position. After cleaning the code up and finishing it, I plan on making interoperability tools to simplify interfacing with SAS, expecially in areas where SAS needs help (i.e. SSIS, MS Office).
It is a good day but it has taken a brutal amount of hours to accomplish this feat. I would not suggest to others to spend this amount of time on this issue: it is simply mind-numbing.
[Update 07/27/2009]
I just wrote my first data into the dataset. It is only numerics right now but it is a start.
[Update 07/29/2009, 3AM]
I just created a dataset that contains text fields. I had an extraneous bug that made me think it was failing when it wasn't. Such is the life of a coder. Anyway, on to cleaning up code that I left hard-coded and making the system a bit more robust.
Let me be clear: I am tired of looking at hex code.
476F6F646E69676874
[Update 08/27/2009]
Progress continues. After I created my first dataset, the goal was to get rid of any hard-coded values and make it more dynamic. While doing that work, I hit a major logic issue and had to focus on figuring that out. I have made it through that and am now mopping up the remnants and tightening up the logic. Since the goal is to ship a .NET dll for developers, I also need to consider how a developer codes to the dll. Basically, I am in cleanup mode and testing additional variables, labels, etc. to see where things break or do not work as intended.
Stay tuned.
Sunday, July 26, 2009
Wednesday, July 15, 2009
PM Stories
These are stories I have collected over the years. i hope people enjoy.
Project Managers In Practice (PIMP…sorry, PMIP)
Our first story involves a young PM, new to the project and not very technical
Ok, so I (senior consultant guy) have a project and there are 3 changes requested by the team:
1. Change a label (minor)
2. Allow a user to save their selections made on dropdowns (these select what displays in a grid)
3. Allow a user to change a grid and submit the values to another program
That’s all fine and good. I bid 44 hours to make the changes.
Team now wants a user to not only make the grid changes (#3) but save those changes as well. So PM says change 2 & 3 are now merged. We need to save selections and grid entries.
I said, OK, slight increase in scope, 50 hours total.
PM says, wait, we merged 2 & 3 together so now we only have 2 changes not 3 so it should be a decrease in hours.
PM survival tip #1: Reduce scope by merging letters on the plan and hope no one notices.
Story 2 involves 4 experienced PMs
Project is in a major crisis. High-demanding customer, a lot of screaming, no time to deliver on time. Save team is called in to try and pull it out. Atmosphere is very tense.
Some of the project members (developer/consultants) have to work on all 4 segments of the overall project simultaneously. Each segment is given a PM. Customer wants to know what is happening all of the time so PMs demand status reports at least twice a day. For consultants working on all segments that is 8 status reports per day. When complaints are lodged, developers are told that it has to be that way and why aren’t we getting the work done.
Revolt of developers / consultants ensues after months of this activity.
PM survival tip #2: if you flood your customer with progress reports they will think you are doing your job. See tip #4 below.
Story 3 involves a fixed bid contract and some super savvy consultants
Two senior consultants figure out a clever way around a major stumbling block on a late project. They can change the process agreed upon slightly and save time, money, effort, AND bring in a late project on time. The customer also wants it done since the new process has a lot of compelling advantages.
Guess who says no? That’s right, our friendly neighborhood PM. It seems that the PM has decided that the original project, as scoped and laid out, is immutable for all time. No changes are allowed from the project plan WHATSOEVER.
PM Survival Tip #3: Minimize risk by making no changes. No changes, no new plans to build. Voila!
Story 4 involves a PM with a dangerous weapon…Outlook
A project, as usual, is in crisis. The PM decides that their main role is to send out emails…lots and lots of emails. On the day of ‘the incident’, the PM has sent close to 50 emails since 8am.
Then it happens…just before lunch. The PM sends an email saying that people are sending way too many emails.
Consultants laugh and break for lunch.
PM sends 10 more before they get back….
PM survival tip #4: Forward everything, comment on everything, make up stuff. The success of a PM is ultimately measured by the suffering of others.
Story 5 involves a PM with no sense what a PM does
So, the PM contacts the lead on a project and tells the lead that there are too many emails about the project and could the lead please summarize all of the open issues and assign priorities…
…isn’t this what a PM does?
Story 6 involves a PM…again…
The developer has been waiting on getting access to the client’s machine for almost a week. Technical issues, blah, blah, blah.
After the week is up, the PM wants to know timelines (this is good, they are doing their job). Developer says the development has been pushed by 3 days. The PM, who has been copied on every email between the client and the developer, says that they don’t understand why the project is delayed because of a lack of access…
Rule #1 in computers: it is hard to use them if you can’t access them.
Story 7 Guess who…
This story involves, SURPRISE, a PM who we will affectionately call Rum. Now Rum is a great PM because Rum thinks that EVERY piece of email and/or communication must flow through him. Rum insists that no direct communication happen between the technical people or the customer and that he will just forward on what is relevant.
I…AM…IRON MAN…DO, DO, DO DUH DO…
Story 8 Who wants it early?
So, the consultant finishes the application early (1 week) but they can’t test it because it isn’t scheduled to be deployed until the following week. They are told to wait until the project scheduled date so they meet the schedule.
Story 9 This is a loving one that I just title ‘Make the Sh*& up’
Well, the customer wants a project plan. Enter our superhero ‘The PM’. Rather than getting requirements or design done first, the PM decides ‘hey, let me have fun with little chain icons and links and just create a project plan! Oh boy!’.
So a project plan is created, with no document saying what needs to be done and no involvement from the programmers. Developers finally start working on the project and are told you must meet this date for this functionality. Programmers say WTF!?!? Where did this come from.
Well, it is in the project plan that we designed w/o any involvement from the people who do the work…
PM Survival Tip #5: When in doubt, just SWAG the dates and blame the developers.
Project Managers In Practice (PIMP…sorry, PMIP)
Our first story involves a young PM, new to the project and not very technical
Ok, so I (senior consultant guy) have a project and there are 3 changes requested by the team:
1. Change a label (minor)
2. Allow a user to save their selections made on dropdowns (these select what displays in a grid)
3. Allow a user to change a grid and submit the values to another program
That’s all fine and good. I bid 44 hours to make the changes.
Team now wants a user to not only make the grid changes (#3) but save those changes as well. So PM says change 2 & 3 are now merged. We need to save selections and grid entries.
I said, OK, slight increase in scope, 50 hours total.
PM says, wait, we merged 2 & 3 together so now we only have 2 changes not 3 so it should be a decrease in hours.
PM survival tip #1: Reduce scope by merging letters on the plan and hope no one notices.
Story 2 involves 4 experienced PMs
Project is in a major crisis. High-demanding customer, a lot of screaming, no time to deliver on time. Save team is called in to try and pull it out. Atmosphere is very tense.
Some of the project members (developer/consultants) have to work on all 4 segments of the overall project simultaneously. Each segment is given a PM. Customer wants to know what is happening all of the time so PMs demand status reports at least twice a day. For consultants working on all segments that is 8 status reports per day. When complaints are lodged, developers are told that it has to be that way and why aren’t we getting the work done.
Revolt of developers / consultants ensues after months of this activity.
PM survival tip #2: if you flood your customer with progress reports they will think you are doing your job. See tip #4 below.
Story 3 involves a fixed bid contract and some super savvy consultants
Two senior consultants figure out a clever way around a major stumbling block on a late project. They can change the process agreed upon slightly and save time, money, effort, AND bring in a late project on time. The customer also wants it done since the new process has a lot of compelling advantages.
Guess who says no? That’s right, our friendly neighborhood PM. It seems that the PM has decided that the original project, as scoped and laid out, is immutable for all time. No changes are allowed from the project plan WHATSOEVER.
PM Survival Tip #3: Minimize risk by making no changes. No changes, no new plans to build. Voila!
Story 4 involves a PM with a dangerous weapon…Outlook
A project, as usual, is in crisis. The PM decides that their main role is to send out emails…lots and lots of emails. On the day of ‘the incident’, the PM has sent close to 50 emails since 8am.
Then it happens…just before lunch. The PM sends an email saying that people are sending way too many emails.
Consultants laugh and break for lunch.
PM sends 10 more before they get back….
PM survival tip #4: Forward everything, comment on everything, make up stuff. The success of a PM is ultimately measured by the suffering of others.
Story 5 involves a PM with no sense what a PM does
So, the PM contacts the lead on a project and tells the lead that there are too many emails about the project and could the lead please summarize all of the open issues and assign priorities…
…isn’t this what a PM does?
Story 6 involves a PM…again…
The developer has been waiting on getting access to the client’s machine for almost a week. Technical issues, blah, blah, blah.
After the week is up, the PM wants to know timelines (this is good, they are doing their job). Developer says the development has been pushed by 3 days. The PM, who has been copied on every email between the client and the developer, says that they don’t understand why the project is delayed because of a lack of access…
Rule #1 in computers: it is hard to use them if you can’t access them.
Story 7 Guess who…
This story involves, SURPRISE, a PM who we will affectionately call Rum. Now Rum is a great PM because Rum thinks that EVERY piece of email and/or communication must flow through him. Rum insists that no direct communication happen between the technical people or the customer and that he will just forward on what is relevant.
I…AM…IRON MAN…DO, DO, DO DUH DO…
Story 8 Who wants it early?
So, the consultant finishes the application early (1 week) but they can’t test it because it isn’t scheduled to be deployed until the following week. They are told to wait until the project scheduled date so they meet the schedule.
Story 9 This is a loving one that I just title ‘Make the Sh*& up’
Well, the customer wants a project plan. Enter our superhero ‘The PM’. Rather than getting requirements or design done first, the PM decides ‘hey, let me have fun with little chain icons and links and just create a project plan! Oh boy!’.
So a project plan is created, with no document saying what needs to be done and no involvement from the programmers. Developers finally start working on the project and are told you must meet this date for this functionality. Programmers say WTF!?!? Where did this come from.
Well, it is in the project plan that we designed w/o any involvement from the people who do the work…
PM Survival Tip #5: When in doubt, just SWAG the dates and blame the developers.
Subscribe to:
Posts (Atom)