March, 2009

Musculoskeletal Disorders and the Programmer

Historically over the last 20 years I have spent the greatest part of my days in front of a computer and keyboard — sitting.  Of course I was sitting, how else would I be able to type and produce the works for which I was being paid?  It’s an occupational necessity to be able to sit!  Well, I’ve (obviously) not been blogging OR programming much over the last month as my “Musculoskeletal Disorder” in the form of sciatica has pretty much disabled my ability to sit without severe pain.  Specifically, my ability to sit in front of a keyboard with an ability to “think” (clearly or otherwise) has been generally non-existent in recent weeks.

Finding a workable pain management procedure has taken much more than I ever would have suspected.  While in one of my periods of relative “feeling good” I checked out the OSHA website and found an article on ergonomics.  In the referenced article it is stated that “Work-related musculoskeletal disorders (MSDs) currently account for one-third of all occupational injuries and illnesses reported to the Bureau of Labor Statistics (BLS) by employers every year. These disorders thus constitute the largest job-related injury and illness problem in the United States today.“  Finding data specific to those of us who sit for hours in front of our computers as programmers was not a quick find, and therefore I don’t have specifics.

What I do have to say is that MSDs are real, can be very painful, and get in the way of living ones life to the fullest!

Danger! Has Software Development Become Too Easy?

While reading on the web recently I actually saw a comment from a developer who expressed (rather strongly as I recall) his thoughts regarding software development ease.  His basic premise was that software development has become so easy given the tool-sets available to developers these days that there are too many developers who are developing software that shouldn’t be because while they may understand how to use a tool to get something working, they do not have the background knowledge to really “understand” what they are creating, therefore creating a “danger” - be it a security danger or data integrity danger.

WOW!  What a perspective!  I believe it was originally posted somewhere in response to the release of the SANS Top 25 Programming Errors.  (See my January blog post “Software Development, Security and Programming Errors“).  At the time I simply dismissed the comment as being way out in left field - but the comment has haunted me since reading it.

I suspect that the comment has haunted me as it has because I am keenly aware that certainly there is the potential of an element of truth to the perspective.  However, I’m not so sure that “easy” software development tools add to the problem, I would expect well designed tools (easy or otherwise) to be producing well designed and secure software.

Applications - Why User Documentation?

I’ve stated before that my goal with applications I create is to provide an application so intuitive that if one knows the job for which the application was designed that the interface be so intuitive that no training would be required.  This is a lofty goal for sure — and not one easily achieved.  It might be better to set the goal to be more like 95% of the time “…the interface be so intuitive that no training would be required…”, or 98% or something like that.  My first answer to “Why User Documentation?” would have to be that it is what covers the shortfall percentage of design that just doesn’t measure up to the lofty goal.

Secondly I believe that most applications will have those activities which are only seldom performed, or performed only as a “fix” to something gone wrong.  The infrequently performed operations which just don’t fit into the everyday flow of the business function, and therefore also not of the business application should be documented for users.  Of course, any documentation available will be only as good as its availability.

Ready availability of documentation for an application, or more explicitly documentation specific to a particular operation is crucial.  As long as I’ve been around applications this has always been an issue.  First off, creating good user documentation (read this as usable user documentation), is not an easy task.  It can also be a costly task.  Ineffective and it won’t get used, unavailable and it won’t get used, confusing and hard to find answers and it won’t get used!

More often than not what I’ve seen is an attitude of “Why document - nobody ever looks at it anyway”, or, “Document the obvious, don’t worry about the details - let them (users) ask!”.  Personally I think application users deserve more respect than that.

Data Rot

Here in the Northeastern U.S. it is snowing outside and I found myself starting my day browsing through the myriad of industry emails I watch regularly.  Now, I’ve blogged previously regarding my thoughts on the “paperless office” (See “The “Paperless” Office –  Myth or Real Possibility?).  But this morning I found the article “Paperless office? Ha! How about a paperless life?” — and of course I just had to check that out!

While mulling over the “…paperless life…” idea I recalled how yesterday while watching TV in the morning I was introduced to the term “Data Rot” in a CBS news story.  I’d never run into the term but I immediately could relate to the terminology, as well as the concept of data formats “going away”.  (I was enthralled with the “wire recorder” and “reel to reel” recorder when I was in my ‘tweens!). 

Anyway, “Data Rot”, the “paperless office” and “paperless life” all are interesting topics, and looking back at what I’ve seen for changes in my life, I can’t help but wonder what our lives will look like in 2080?  One thing I’m sure of, however, death and taxes - not necessarily in that order!