Friday, January 27, 2012

load

If I were a unix server, my cpu load averages would be in the 90's.  like all week...

I have a disorganized desktop, a completed eval that I still need to go over with an employee, 320 emails in my inbox (ouch), and a list that's growing each day.

Did I mention that I had 5-6 hours this week that were not scheduled?
Holy hand-grenades.  It's been wild.  Oh, and I've not been feeling well for about 3 days (compacted by that disallowing me to exercise).

I want a nap, and a cookie :)  On the bright side, I had some very productive meetings this week.  Some might even allow me to have other people do some of the many many things on my list :)

KPI meeting(s)

Well, that's two meetings now that I've been to for KPIs, this week.

I really do understand that value of KPIs, but I'm concerned about the process.
1. The "consensus" process has so watered down the text/meaning/value of each KPI, that they have seemed to become a bit over-generic.
2. A whole team of academics (which I love, don't get my wrong) seem to have word-smithed them - so to be completely honest, I don't know what half of them mean :(
3. We're gonna have to find ways to COLLECT data for some of them, meaning that we have no comparative data (aka no KPI) for 5 years... ... ... ...
4. So many people do things so differently, I'm not what the value will be for us ... in 5 years ... ?

Anyway, I'm most likely confused because I'm --not-- and academic, and just don't get it all.  :)  That's fine - I'll let the smart people figure it all out.  Then we can build it!

Friday, January 20, 2012

The killer ratio

The longer I've worked here, the more obvious a trend has emerged.  It has begun to concern me, and I'm working to take steps to combat it this year.

When a developer starts out, the spend nearly 95% of their time writing code.  This goes merrily along (often for years), until the ratio begins to move.  The ratio is the amount of time that is spent writing new code, versus maintaining existing code.  As old projects need maintenance, updates, patches, etc... a developer can move from the 95/5 ratio closer to 75/25.  75% on new projects is still quite good.

But the killer ratio is when the sides change.  When a developer goes under 50/50, there is a problem.  Expectations have risen each year for the last few years.  Resources have not.  We are always encouraged to "do more, with less".  Sure :)
When my developers spend so much time babysitting old code, patching, etc... that new code takes 2-3 times as long, then campus members notice.  They complain :)  I don't blame them.  They don't understand.  I am only just beginning to understand.

How do we change the future?
We slow down, for one.  We cannot maintain a break-neck pace forever.  The summer comes quickly.  We will regroup, repair and rebuild some foundations.
We will analyze our projects, understand them.  Automate them.  Users should be able to use their seasonal apps without needing us to "prep" them.  This is the goal for existing and new code.  Having a huge codebase in the Portal has enabled us to simultaneously update CSS, security, etc...

But we must remain vigilant. 

The future is what we make it.  We cannot continue to pay the price of "heads-down" development and trying to work harder.  When an inefficiency has been identified, it must be resolved.  That's my job.  Updating the list, and including periods of rebuilding must occur.  It will occur.  Will it take "longer" to release apps?  In the short term, perhaps.  But it's a short-term loss, long-term gain.  I also cannot run my people near redline for long periods of time.  Everyone has to catch a deep breath.  Then we push on.  Stronger than ever.

SAML

We are embarking on our 2nd SAML integration project.  Our first technical meeting is next week.  I'm very pleased with SAML, and think we might be able to expand it to other systems in the future.

This project is for integration with a bank, and we are acting as a pilot for the project.  WOU has a team of 9 involved, but the technical lead will really be performing most of the work.

Running

Run, Forrest, Run!

Good advice.  Seriously.  Especially if you spend lots of time in front of the computer at work.  And at home.  And, well - you know.

Bill and I have started running at the Health and Wellness Center.  And honestly - I'm amazed.  I'm a pasta-lovin', Mt. Dew drinkin', over-technologized guy who's reasonably thin.  But running is like a drug.  My body anticipates it.  I feel stronger after I run, like right after. 

I'm looking at doing a 10K this year.  Spring/Summer/Fall ... maybe 2?  Not sure.  I ran 2.5 miles yesterday.  That's almost halfway there...

2012 is a year of change for me.  Time to stand up, and change things in my life.  And it's happening, and it's good. 

Friday, January 13, 2012

New Employee

Nathan Brake has joined us a Banner Programmer/Analyst!

After 3 failed searches for someone to fill this position, we changed the PD and hired Nathan.  We are very excited to have him.  Please join me in welcoming him to the team.  He has some big shoes to fill and is learning as fast as he can ;)

I'm exciting to have a full team again, and we'll focus this term on training and laying a solid foundation.  First on his task list?  Faculty Load (dramatic music)...

Project Management

And we welcome in the New Year --

This has been an incredible year so far (and it's only been a week!!!)

I'm making a change in 2012, and have started working out very regularly this month.  Yesterday I ran 2 miles without stopping.  For you runners, I know that you're giggling on the inside because that's no great feat.  But for a guy who counts a walk to the mailbox as his "weekly exercise" and loves burgers, fries and Mt. Dew - it's a big deal.
I've even started looking at doing a 10K this Fall (after I've gone more than a week).

In other news, I will be focusing very hard next week on Project Management.  I need to meet with each member of my team to figure out which projects they are still working on, the status of each - and others that have been assigned to them.
Coordinating with Bruce, I'll then assign a few more and attach a schedule to the whole process so that we have a clear picture of what's going on.