I have always found estimating a project to be a challenge. Back in my early days as an independent developer I quickly learned that I had a tendency to under-estimate the time a project would take. My error would more often than not be in accounting for the time it takes to “polish” the application. My approach to that then was to produce my best estimate and then apply some factor to it, somewhat depending upon my “attitude” at the time, but always beginning with a factor of 2. If I thought a project would take 40 hours I could pretty much depend upon it taking a minimum of 80, so I’d double my estimate! Continued »
It’s been quite a while since I’ve needed to delve into the intricacies of procedural code to the extent that I’ve been into it over this last few weeks. Not just one new project, but two new projects acquired within a 3 week time-span has put me right into the middle of thousands of lines of procedural code, methods of programming I haven’t used since the pre-Y2K crunch, countless goto’s and code markers.
Out of the sometimes chaos of these last weeks, I have come to realize once again that producing a modern day application is not our father’s skill-set. Development has come a long way toward RAD (Rapid Application Development), though there is often evidence to the contrary. Just have one piece of code fail and see how rapid(ly) development comes to a screeching stop!
In the midst of my intensity with these projects a recent Computerworld article entitled “Old School Programming techniques you probably don’t miss” caught my eye, and I enjoyed my trip down memory lane as I read the article, and yes, those which I participated with in past years I DO NOT MISS 🙂 COBOL was my first language, and I remember spending hours on calculating data locations according to the imaginary grid of characters available to display on screen, and the amazing time it took to position data to print on the pre-printed forms used by the program. Those weren’t the good old days!
Data deduplication essentially refers to the elimination of redundant data. (from Wikipedia) As the term seems to be commonly used, deduplication really is referring to duplication of data on servers and perhaps shares throughout the domain. I suspect that nobody who has been around IT very long would not understand that as time goes on it is not uncommon to find multiple versions (…as well as duplicate versions) of files throughout an enterprise (of any size). This phenomenon adds considerably to time required for backups, can cause slowdowns in the network, as well as user confusion — none of which are desirable of course.
Database Normalization I believe runs a parallel to deduplication in that one goal of normalization can be elimination of redundant data. Many of the same benefits of deduplication can be realized when a database is normalized – such as faster transmission (less data), and less storage space required etc. Normalization has become very much a part of my most recent project – upgrading a 20 year old database application to a modern database using relational technology. The project is no trivial task – but I’m having fun with it! 🙂
I’ve discovered the greatest challenge of my application programming and design career, (Hopefully I haven’t met my match!). My latest project involves a rather large legacy character-based system which has evolved over the past 20 years or so. The source code directory lists some 800+ pieces of source code, with close to 500 being actively used, and others that were basically copies of some “active” source with minor modifications – mostly in the screen layouts for entry programs, and header footer changes on reports. In all, a lot of code to evaluate. Continued »
As a custom application developer working mostly with small businesses, users often look at “Why can’t the program do this?”, or “How about having the program add this, subtract this – when it’s this, then add a percentage…” yada, yada, yada. Perhaps you recognize the pattern. There can be arguments for doing much in the way of accommodating the requests, but in my opinion there can become a time when an application is too automated. Continued »
It can be a huge leap from the highly customized legacy application (which for many have been in use double digit years), to the newer graphical point and click or web based AJAX type application. So my question today is “What keeps them running?”, or perhaps a better question is what is it about them that keeps them in place for so long? My questions arise once again prompted by a vist with a new client now running their legacy character based system well into the double digit year mark. Continued »
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!
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.
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.
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!