8/30/2011

Good 'ole days

We moved to Tampa, Fl from Poughkeepsie, NY in 1982.  My father worked for IBM.

He bought the family a new IBM PC, 1200 baud modem and a dot matrix printer.

When he wasn't connected to work, I'd get on there a mess around with the computer.

We had PC-Dos, no hard drive and 5.25 floppies.  If you cut a hole in the other side at the top you could double your capacity on the floppy.

We had a game called "decathlon" where you pound the keyboard as fast as you can to make the guy run.  To this day I never did figure out flight simulator.

I would dial the BBS numbers and page the SYSOP.  They had games to download, and calendars you could print out on the dot matrix, not advised for the teenagers.

I would call one number and get a list for 10 other numbers.  I would call them and get more numbers.

There was no question I was not allowed to make long distance calls or compuserve or any pay sites.

My neighbor had an Apple/Mac and I thought the graphics were better back then.

I wrote my English papers on the computer.  And learned to type with a program that measured your keystrokes per minute.

I wrote:  10 PRINT "HELLO THERE!" 20 GOTO 10.  My first programming experience.

I only took one computer class in 8th grade and one in 12th.  I remember a lot of kids cheating off me, which was usually the other way around in all other classes.

That's about it for memory lane.  I think that original PC is in the Smithsonian.

8/25/2011

Luxury vs. Necessity

When it comes to reporting, do you like to have reports or do you need reports?

Chances are, you need reports.

Any why is that?  Because all that data is just sitting there quietly in your database waiting to be freed.

What about data warehousing?

I'm sure you'd like to have one.

But if you had to cut your budget to the bare bones, could your department/organization survive without one?

My guess is you could still survive without one.

And with the latest news of budget cuts, including a 25% reduction in the Navy IT budget, you may have to decide sooner than later if you can afford to keep your Data Warehouse.

Just saying!

8/24/2011

Reporting Up Close

The goal of the BI Developer is to help the business make better decisions by turning raw data into information.


However, when you look at Reporting up close, the picture perfect scenario does have its limitations/challenges.

In my opinion, for one reason or another, the reports in production are not always accurate.

Perhaps the Quality Assurance person over looked some business logic.

Or maybe there was no QA department involved.

Maybe the business rules changed over time and no one was notified.

Perhaps the "business experts" or "super users" change departments or left the organization leaving a gap in knowledge.

So in general, you have to keep an open mind when viewing your reports.  The information you are given to base your decisions may not be always be 100% accurate.



Reporting requires more "maintenance" time than "development" time.

Reporting is not something you throw into production and forget about.


Typically, a department will request "reports" for their data. 

They hire consultants to build them a BI solution. 

The BI people create a data warehouse and a bunch of reports. 

Once created, they go on their merry way.

What if the business rules change?  What if the data gets moved to a new server?  What if your current staff leaves and you have no one who knows the architecture of the BI solution?  What if you want to incorporate new data into your warehouse?

Well, you could get out your check book and re-hire some BI Developers to assist.

You could also keep "maintenance" programmers on staff to support the BI once the developers leave.

The "maintenance" programmers are the knowledge base of the business rules. 

They fix the bugs and upgrade reports to new versions.

They work the tickets.

They go to meetings.

They are the grunt workers of the BI world.


The typical "maintenance programmer" position is not as glamorous or lucrative as the BI Consultants. 

However, they have a definite place in the BI world.

The role is just as vital and should get more exposure in my opinion.


At the moment, Business Intelligence is riding a huge wave in the IT world. 

Get out your surfboards!

Report Overload

Working in a Reporting Services department, I get to work on a lot of reports.

So many reports, in fact, that we are now on "report overload".

How did this happen?

Well, we have existing reports in production that need tweaks/bug fixes.

We have incoming request for new reports.

We have existing projects in flight.

We have new projects on the wings.

We have the emails for quick reports.

We have the stop what you are doing now and do this report.

We have the "holy cow" this report is broken, please fix it ASAP.

As you can see, managing the report queue can be quite a task.

I see a few things that could be changed to better manage this.

First, there is no control mechanism to determine which projects get approved. Every report project request gets approved no matter how long it takes or how many resources are available or what the deadline.

Second, there are not enough trained resources to contend with the work load.

Third, every customer thinks their request is #1, top priority.

So how do we manage this environment?

Well, first off we need to get a better handle on the workload. By identifying the volume of work, assigning hours to it, prioritize the request and assign based on available resources.

Then implement "status reports" from all the report developers.

And get management's buy-in to mold the environment so the customer's expectations are in line with reality.

Train the developer's to produce better code in less time.

Perhaps have one developer work on bug fixes and the other work on projects. And then rotate rolls.

Have the DBA's give the developers a quick tutorial on all the recent database changes for "best practices".

I'm open to suggestions here. I don't have all the answers.

8/19/2011

Why do people in IT enjoy their jobs so much?

1. Creativity
2. Independence
3. Team Work
4. Development
5. Design
6. Build
7. Not Repetitious
8. Test
9. Organize
10. Problem Solve
11. Find Solutions to complex problems
12. Exceed expectations
13. Unstructured Free flow work
14. Troubleshoot
15. Fix bugs
16. Balance Reports
17. Concentration
18. Logic
19. Projects
20. Completion
21. Challenge
22. Intelligence
23. Service
24. Salary
25. Advancement
26. Learn
27. Knowledge
28. Growth
29. Change
30. Adapt

With an Anthropology degree from the University of Florida, and "almost" a minor in business, I'm basically a self taught programmer except for the FORTRAN class at UF and c++ from St. Petersburg College. I also learned PC-DOS/BASIC in 1983 on the original IBM PC.

I started my career in Credit for Sears and then NationsBank approving loans in a production line environment until I volunteered to do reports.

If I were to switch careers at some point, I think I'd like to be a credit councilor and help people consolidate their bills and reduce their monthly expenses.

I'd also like to help people create financial budgets for their home as I've been doing this since forever and when you have a cushion of disposable income it really frees up your life and allows growth.

If I ever struck it rich, I'd either teach tennis, open a cigar store or a used book store, or work on archeological digs.

I've got 20+ more years to work so anythings possible I guess...

8/07/2011

Job Security

Some people in the IT field have very good salaries. And some of those people will act in certain ways to make sure they keep those high paying salaries.

I've seem some people who deliberately keep their work private so nobody knows for sure what they do. That way they have job security. However, at some point even management sees through this ploy and I've seen a person like this let go. And he was forced to train the next person in his position.

I worked in a place one time where a programmer always claimed to be "so" busy that he pawned off work to the other programmers. After that person left, I automated his entire job in about an hour. So much for being busy.

Working for the government, I was absolutely flabbergasted at the gall of one particular programmer. He actually slept at his desk, read the New York Times at his desk, took way too long on assignments where the work had to be re-done anyway. Management could not get rid of this guy as much as they tried. So when the budget went south and they were forced to let people go, this guy was first on the chopping block. And to my amazement, this guy complained the most about losing his job. Kind of ironic.

Although this pattern is prevalent in IT, I'm seeing it less and less because of the economy. You really have to produce, even at the gov't jobs.

I still believe in hard work, even when no one is watching. I guess its the satisfaction of doing a good job.

I know there will always be the "slackers" who work so hard to avoid doing work, but I guess everyone gets what they deserve in the end.

8/03/2011

Trenches

Today I worked in the "Trenches".

The main user/stakeholder sat at my desk for over 6 hours.

We reviewed each of the 13 completed reports and applied some "standards" to them.

Each report has the same header, footer, font sizes, groupings, alternate shadings, sub-totals, totals, etc.

For some people they don't like people looking over their shoulders when they work. I'm the opposite.

I like people to watch me fly through the screens where the cursor never stands still for a second.

We knocked out those reports in record time. And they look good.

The user is thrilled.

We have another 13 reports which one of the developers is writing.

I showed the developer the "standards" and gave her a document to follow going forward.

I guess I really do like this job.

Just wished it paid more than minimum wage for the industry.

Oh well, there's more to life than the mighty dollar$.

8/02/2011

The Undo Button

I think I found out what I like most about programming.

The "Undo" Button.

Where else in life do you get an "Undo" Button?

Sports, nope. Relationships, no. Tests, I don't think so.

Only in programming do you get to do something, see if it works, if you don't like it, simply undo.

It's so simple, yet so profound.

Another thing I like is the ability to create. Programming is so unstructured to a point, wrapped within structure.

Working in IT/Programming/Reports, very rarely do you have two days alike, let alone two hours.

The ability to be imaginative, to create. At the end of the day you have something that did not exist before. To personalize it. And then release it to the world. Kind of spiritual.

Mountain Living