Beyond Blinking Lights and Acronyms

A True Error, Not a Glitch Tue 28 Jul 09

Baytown Mayor Admits Error In Release Of Banking Info

I've written recently about The Real Problem With Computer Glitches.  Computer glitches are when something goes wrong but we don't talk abut someone making a mistake or a bad process being used.  Something just happened without human intervention (yeh, right).  I followed that up with a comment an Another Glitch regarding Goveronor Scharzenegger and a computer glitch that kept a law student from taking the bar exam.

Although I don't want to beat this subject to death I just have to comment about an article I saw in today's Houston Chronicle, Baytown releases banking info for 10,000 by mistake.  It seems that some how banking information about 10,000 people that paid tickets after being caught by a red light camera.  What was interesting was how this was portrayed. 

Another Glitch Sun 26 Jul 09

Schwarzenegger: Overlook glitch, let paralyzed grad take bar exam

My last post, The Real Problem With Computer Glitches, dealt with the mis-direction calling failures merely "glitches" causes.  This morning I ran across a story on CNN, Schwarzenegger: Overlook glitch, let paralyzed grad take bar exam.  It seems that a glitch or technical error was keeping law student, Sara Granda, from taking the bar exam because she paid for the test with a check instead of the usual method of using a credit card.  Fortunately, it appears that Schwarzenegger is coming to the rescue.

As heart-warming as the story is, it is missing a couple of key elements. First, what really caused the problem, and second, what is being done to prevent it from happening again.

The Real Problem With Computer Glitches Wed 22 Jul 09

Calling system failures ''glitches'' only masks the problem.

Visa prepaid debit cards recently suffered a rather public and embarrassing problem. It seems that a "small" number of users made normal purchases only to be charged $23,148,855,308,184,500-- basically, $23 quadrillion and change. Visa later indicated that fewer than 13,000 transactions were affected. The credit card company subsequently removed the charges and magnanimously waived the overdraft fee.

This was, as is quite common in these situations, described as a computer glitch. But the term "computer glitch" really frustrates me. People have been conditioned to think of a computer glitch as something that just happens when the computer goes haywire and that there is nothing that can be done to prevent it. 

Fluid CSS With A Sticky Footer Fri 20 Mar 09

Adventures In Programming

The title makes this sound a lot more interesting than it really should be but does describes my latest adventure in programming.  You may have noticed that my blog has a new format primarily regarding how the main column appears.  It is now a variable width or "fluid" column that varies with the size of the browser window to maximize the viewable area.

Back at the beginning of February I rolled out a new blog format with slightly wider columns and different font to help improve the readability.  At that time I really wanted to have a variable or fluid main column that adjusted to the available screen resolution.  Unfortunately at that time I didn't have a clue on how to do that so I set the page width to 1360 pixels and left it at that.

What's In A Title / Job Description - Programmer, Developer, System Analyst, Business Analyst Tue 02 Dec 08

A reader from Singapore (fantastic place by the way) wrote me with a question a few weeks ago -- " Just wonder how a BA [business analyst] is different from a SA[system analyst].   My understanding of a good SA has attributes given in the 'job description. "  This is an interesting question as the two titles are often used interchangeably along with 2 other titles: programmer and developer.

If we look as some simple descriptions from Wikipedia we see some similarities and overlap and a progression.  There are lot more that can go into the job descriptions but these simple description do illustrate the point.

• Programmer - A programmer is someone who writes computer software.
• Developer - A software developer, one who programs computers or designs the system to match the requirements of a systems analyst.
• System Analyst - A systems analyst is responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements.
• Business Analyst - A business analyst or "BA" is responsible for analyzing the business needs of clients to help identify business problems and propose solutions.

What we see is a progression from highly technical orientation to highly business orientation.  Graphically it might look like this:

An IT Question: Are Access Database The Problem Or Only A Symptom? Mon 08 Sep 08

User-written Access databases (and other similar applications) always present a number of issues for IT.  Issues of on-going support, documentation, testing, Sarbanes-Oxley compliance, security, backup, licensing, disaster recovery and so on.  They represent all of the challenges that we continually work to minimize.

Some in IT view Access databases as the root cause of these issues and therefore the solution is clear.  Let's solve the problem by outlawing Access databases and limit user ability extract data from or to update data in the ERP systems other than through IT provided means.  No more user-written systems, no more issues.

Others view these user-written systems as a symptom of a larger issue.  The larger issue being that users take this route because IT doesn't give them a better alternative.  They don't feel IT is responsive enough to their needs and therefore they must take matters into their own hands.  Those that believe the Access database as a symptom issue don't believe we can ever eliminate them (users will always find away to meet their needs) until IT resolves the issue of responsiveness thereby providing a better alternative to users?

How do you view Access databases?  Are they the root cause of the problem or are they symptoms of bigger issues? 

"Help" photo by Cobber99

Got a question you'd like me to post for future discussion?  Email it to me using the "Email Mike" link in the left hand column.

If this topic was of interest, you might also like the other posts in the IT Question category.

Business Analyst Job Description Mon 11 Aug 08

Far and away my most popular post is Let's Get Down to Business.  Even though it was written about a year and a half ago, 20+% of my recent site visits are to this article coming in either through Google searches or Jonathon Babcock's review of this post.  Why is this so popular?  I think it is because it contains a great business analyst (BA) job description that gets to the heart of what a business analyst really does.  This job description doesn't just cover the skills they need but focuses more on the competencies that will make them successful.

Having just gone through the process reviewing a fair number of BA resumes I'd like to add one more item to the list.

Be able to describe and communicate the value of a project in terms of both its benefits and costs in terms used by the business community that will effectively obtain leadership understanding, support and approval of the project.

In other words the BA has to be able to "sell" the project.  Ultimately it is the responsibility of the business owner or sponsor to sell the project, however, the BA has to be able to play a critical support role in selling the project.  As I did in the original post I highlighted this competency in blue to convey convey the essence of what distinguishes a good business analyst from a good applications person.

The reason I've added this is that after reading a number of resumes it was apparent that many claiming to be BA's are missing this critical competency too.  (Perhaps I should have used a different colors since it may not be all that common with BA's either.)  How could I tell?

Interviewed On Dice.com About Business Analysts Raising Their Profile Tue 20 May 08

Back in April, Sonia Lelii from Dice.com, a recruiting and career development website for technology and engineering professionals, interviewed me as part of her story, Business Analysts Raise Their Profile in their Technology Today section.  Lelii also interviewed recruiter Christa Baker for her perspective.  Unfortunately, I had forgotten about this until Monday's post on hiring business analysts reminded me.

The article talks in detail about the need for people who can communicate between IT and business groups and what types of background and  skills they need.  Take a look, I'd love to hear your thoughts.

If this topic was of interest, you might also like these:

• Hiring the Right / Wrong IT People to Achieve Alignment
• Jonathon Babcock's post Business Analyst Job Description
• Let's Get Down to Business
<
• Or the posts in the Business Analysts / Analysis category

Agile Programming - A Poor Choice of Words? Mon 12 May 08

Agile Programming is a popular programming methodology.  But it's not alone. There are other methodologies such as the Rational Unified Process, Spiral, and the traditional Waterfall methodology in common use.  Each has it advantages and disadvantages and each is named in a way that describes the process.  However with Agile its very name can tend to cause confusion.  "Agile" gets confused with "agile".  Wait a minute.  Other than the capitalization aren't they the same things?  Well not exactly.  Agile with capitals does mean something different than lower case agile and that's where the confusion comes in.

Agile (upper-case) programming in overly simple terms is a method of developing programs using closely knit teams to quickly produce releasable code in short time frames.  Based on the Agile manifesto principles it has some certain processes.  Wikipedia provides a good overview and a simple Google search will provide a mass of references. 

agile (lower-case "a") programming simply denotes being flexible in our design and adjusting as we go.

The term Agile was no doubt derived from its lower-case counterparts and that's where the difficulty comes in.  When we speak of Agile others often hear agile.  And after all who wouldn't want some flexibility in programming?  So very often you quickly get buy-in to employ this methodology when you use this term.  That is until the realization sinks in that what your user thinks they bought is not what you thought you were selling. 

Keeping Data Accurate Mon 28 Apr 08

This weekend I got a new windshield on my car.  A few weeks ago a rock chipped the windshield and propagated and 18 inch crack within a few minutes so I arranged for a windshield repair company to come to my house to replace it.  Things were going along pretty smoothly at first.  They removed the old windshield, took off the various registration and safety inspection stickers and prepped the car for the new windshield.  Everything was going well until it came time to put in the new windshield.  That's when they found out that the windshield they brought wasn't the right one for my car.

The repairmen called their office and verified that all of the ordering information was correct.  The problem turned out to be that the database of auto glass parts that they subscribed to had the wrong information.  They finally were able to figure out the right part number, brought it out to the house and installed it.  All turned out well except that it cost them an extra 2 hours of delay.  As they were about to leave one of them commented that they recalled that they ran into this same problem the last time they worked on my model of car.  It turns out they had to work with an inaccurate database that didn't have a good means for them to update or correct when errors were found.  In this case an inaccurate database became a customer service issue.

It's a fact of life that errors will find their way into our databases.  There are things we can do to minimize this but it difficult to entirely eliminate errors.  So this begs the question - "What do we do about the errors?"