I recently read an interesting article entitled “Testing training: Disturbing Behaviors of Students“. It’s author started the article with the phrase “Drive-by Training” – I’d never heard the term before but I love the term, as it made me think of much of the training I’ve experienced during various software introductions and implementations.
While the article specifically refers to testing training, the idea of “Drive-by” training is equally relevant to software application training as well. In his article the author describes 5 “Disturbing Behaviors” — but the one I particularly like is his #2 behavior: “Attending Class with a closed mind!” I have seen this behavior almost as a consistent way of being for most students attending training courses — and I just can’t relate to the attitude.
However, busy schedules, over-worked personnel and negative perceptions of the value of training are pervasive with workers today (…and has been for quite a while I must admit!). I will never forget August 1, 1999. That was the day I was involved with what became the most night-marish software implementation that I had ever experienced! When I look back at the “training” prior to implementation I shutter at the mistakes that were made.
“Drive-by” training is an apt description. There was no depth to it at all — and turned out to be about as effective as ordering from your car through one of those infamously poor quality systems — and ultimately receiving the wrong thing!
I had an experience this week! It was one of those unplanned “moments” where it seems that the universe aligns and presents an opportunity for the taking. This is the story of an experience involving a grand-daughter (student) and a “grampy” (IT blogger). You might guess the personalities involved here 🙂
A chance set of circumstances aligned such that the “grampy” in our story had an opportunity to transport subject grand-daughter back to her college with what was expected to be a 3-5 hour drive depending on the traffic involved. The travel day was beautiful, the traffic light, and the trip started off with little conversation (…it was still quite early in the morning!).
As the trip progressed subject grand-daughter began to think about what she was going back to at school — including her IT course which she began to fret about — saying that it was a required course for business students at her school and that she just wasn’t understanding any of it. She expressed concern that the book seemed so technical – and that she couldn’t seem to understand all the various acronyms – what they meant – and what they did. All just seemed to be one big mystery to her! She expressed concern about not being able to “see” or “visualize” such things as a LAN or a WAN — never mind the possible array of components that might exist within them!
Her frustration came through loud and clear! Enter the “Grampy IT Guy!” Now it just so happens that at the very moment that she was communicating her concerns they were less than an hour away from the IT department subject “Grampy” recently retired from. A quick call to said company IT Manager (MIS as they refer to it), and reassuring said IT Manager that there was no intention of pointing said student toward the IT ratrace as a career — a stop at the old company for an IT department “visualization” and Grampy’s IT 101a course 🙂 was scheduled.
The extent of the value of said stop remains to be seen, and can probably never be quantified — but what subject Grampy realized from the event was in fact valuable — first, that as an IT guy there are a lot of assumptions made regarding understanding, secondly, presenting IT to the business student provides a valuable foundation for the inevitable future contact with IT in business, and third that moving beyond the “book” learning adds significant value to the education.
As some new system or network need comes up either for myself, or for a client, I may find myself searching the internet for something to fill that need. Obviously this must be done with care and more than a bit of due diligence. There are in fact many excellent resources available from the internet — but when faced with finding a “new” supplier say for something like a utility — how do you decide who you can trust? I’ve been considering this for quite some time now and realized that I have developed some pretty basic “first steps” to establishing some trust in the site or utility that I’m considering.
- First impressions are lasting impressions for me – at least when it comes to a websites home page. If I follow a link to an interesting utility, the page I land on will determine immediately whether I go any further. I expect the page to provide information about the utility, I don’t want flashing “Buy Now” or “Download FREE Now!” buttons offering me a special discount (…why me? Lucky number? I don’t think so!). A site failing this brings me to exit immediately.
- Site References are important to me — things like “How did I get to this site? Was it a link from the page of a website I trust such as TechTarget?” Was it a link which the vendor has paid for — i.e. a purchased advertisement? Are there references on other sites which describe experiences with the utility as to its effectiveness. In other words, can I easily find anything about others experiences with the utility?
- Recommendations from personal contacts plays a large part in my deciding to “trust” a sites offerings.
- I recently downloaded a C++ script from a site I didn’t know and compiled it — a script to provide very basic IO and file creation and deletion information. This was a case where even I with my limited knowledge of C++ scripting could see that what the program was doing would be “safe”. The site I downloaded from wasn’t flashy, but it clearly met my requirements in 1 and 2 above.
With so much “free” available on internet pages a prudent approach to choosing downloads is essential. Selected wisely, much valuable information, utilities or even “free” applications can save time and dollars.
Regardless of the reason for a development project being delayed, coming back to a project which has been “on the back burner” for a while seems always to raise questions about the project. For me the questions may start out with “Where was I on this before I had to leave it?”, to “Why on earth was I heading in THAT direction with this?” — or my favorite “What was I thinking!” (…usually an indication that I wasn’t thinking! ) . Besides the “lost” time of re-aquainting oneself with the project, there have been many projects for which the longer they sat, the more I just wanted to start over again.
As an independent developer I’ve always had to be working with multiple projects at a time, and somewhere deep down in my being, I wished that I could just have one project to work – from start to finish! The problem with that idea is that for one thing a custom application project never seems to end — mostly as the result of constant improvements being made to the application — or “tweaks” as one of my customers call them, so there is seemingly always something more to be done.
However, coming back to a project can be challenging. It can also be an indication to one as a developer of how much they’ve learned in the say, six months that a project sat without being worked on. This is a good thing! Whenever possible when I have identified that some previous work can be improved upon to simplify or somehow make the code more maintainable — if at all possible I make the change.
Another thing I have experienced after coming back to a stopped project is that very often I find that in the time lapse since last working on the project the needs of the user community for which the project is designed may have changed. Certainly it is imperative that before going ahead with any stopped project there be clear communication with users or as a minimum the person ultimately responsible for the project from the business need standpoint.
Coming back to a project can be exciting — but it can also bring new requirements, expectations and challenges.
I remember the statement made by the president of a software company vendor of mine in a meeting some years ago as if it were yesterday. The comment, made to a salesperson of his also in the meeting, was this — “See, it’s all about managing expectations. We have to do a better job of managing expectations.” This was his whispered response to the “complaints” he was hearing from us, his customer, about our (I’ll be nice 🙂 ), disappointment with the software quality and performance.
In a similar vein I also remember being in a meeting with our previous software vendor where, trying to make light of our “concerns” with the ever increasing software support fees which we saw as getting us nothing, this president quipped jokingly “…gotta keep up our cash flow you know!” That statement was the opening of the exit door for that software and vendor — never forgotten by our company — and referenced many times over as the years went on.
While I don’t mean to suggest that either of these comments represent major attitudes of an application vendor to their customers, the examples above do point to an important attitude that (I believe) applications vendors “should” have — and that is “listening” to their customers expectations and really “hearing” how their software is, or is not, meeting the customer expectations. I’ve blogged in the past about “hearing” in my post “Please Hear What I Really Need“. This kind of active listening goes a long way toward managing software application expectations. I highly recommend it!
There’s nothing that I can think of to “shake up” business processes and the custom applications used to support those processes more than a personnel change. This is most clearly apparent in the small company applications used by a handful of key users in the company. If for whatever reason one of those key users is not available for an extended period of time and others are doing what was “their” job, questions are inevitably raised about “Why is this like this? Why are we doing this this way? Wouldn’t it be better to…?” In my experience while changes in business needs can elicit those same questions, by far the most dramatic and in-depth questions come from the change of personnel doing a job.
I have been dealing with a couple of situations in the past weeks that fall into this category — and the end result of those questions is, and will be, a much “cleaner”, “user-friendly” and “efficient” program. The change is good! It seems that the longer an application is used the more “set in our ways” we get about the program just “being” a certain way – rather than challenging either the process or the program. My clients are always encouraged to be on the lookout for potential changes to make their jobs easier, that’s just the kind of relationship that I’ve built with my clients, but it seems to take some dramatic change to elicit new requests. In so many cases the changes are not necessarily extensive — often just a “tweak” here or there that over time makes a significant contribution to efficiency.
So here we are — the stock market still sliding downward (…or is it a free-fall?), unemployment rising, IT jobs being cut, and seemingly unending bad news on the economic front! If you are on an IT payroll somewhere, you may be concerned about your future with the company – and rightfully so. If you are a contract or custom software developer you may be worried about where your next project will be coming from, or if not that, perhaps whether that project you’ve been working on will be safe with all the cuts going on.
These are decidedly difficult times, and it looks like they won’t be going away very soon. If you are a custom application developer what is your next step? What will be your future? How do you sell your services? Will you be able to? …and for how much?
My recommendation regarding your service pricing during this time is “Don’t Discount!”. Yes, potential clients might be looking for bargain basement pricing, but as an independent who offers a valuable service to your clients it is best that you maintain your value. If you are one who quotes hourly rates especially don’t discount! My recommendation is to get away from the hourly pricing and instead make it a practice to set a fixed price for a well defined task. Base that fixed price upon your best estimate, but make it a price that will be attractive to the client — and then get the job done well when its yours.
I’ve found that often a potential new client doesn’t stop to think about the extra expenses that an independent is faced with — and I don’t hesitate to remind them that much of my education which allows me to provide them with my service is the result of many hours and dollars invested in training programs, software and hardware. Every new software release must be tested, software updated, tested again, and new functionality learned — all during non-billable time! When a new operating system is released that too adds to the non-billable time spent in educating self.
It’s easy to forget what it takes to provide quality service to clients, but you owe it to yourself to value your services properly. Did I remember to say “Don’t Discount”?
Back in mid June I was interviewed by a freelance writer working on an article about software development project closure. It was an interesting topic to me, and one which I have honestly never really stopped to think about. While I’ve blogged often about my thoughts regarding user input, communications and other development topics — project closure hasn’t really been much a part of my planning.
The article for which I was interviewed is a well written piece which I will not try enhance. (It is already full of my thoughts during the interview!). I expect that readers of this blog will find it interesting. The article entitled “The Beginning of the End: Defining Project Closure” is a recommended read.
My previous post made reference once again to the human interface design of an application and application speed considerations. As a follow-up to that post, I find myself thinking once again about a few of the issues which I have previously posted about code maintenance and new design. “Software Quality and Maintainability” was one of my earlier posts which may be of interest.
The topic of maintenance vs re-design once again (as with so many of my topics) has been prompted as the result of fresh experiences with my clients. My earlier post made reference to factors beyond the programming considerations which might otherwise be no problem, such as hardware or O/S issues. The current issue I’m dealing with however is really a useability issue. The client needs have changed so much that another maintenance band-aid to the existing program just isn’t appropriate. It is past time for updating – new design is the only logical option.
There is of course the shrinking budget — and that is an issue for this client at this time whether they were to decide to buy off-the-shelf or build. Perhaps this is a time for them to ignore? I think not! Their need is there, the budget isn’t. This is where they should be making plans for the future. They’re still working with what they have, and, inefficient though it is, they are getting by. However, by using this time for planning future IT infrastructure improvements they will be well served and perhaps be able to establish a method where their investment can be “piece mealed” and thus keep moving forward.
ADD — aka Attention Deficit Disorder — is, some say, an altogether too common ailment in today’s society, at least in the U.S. While I certainly don’t intend to debate that issue, a recent experience got me to thinking about how children with ADD do and will grow up to be computer application users. These thoughts in turn had me thinking once again about application interface design and user needs.
Much is written about interface design. For years we’ve worked hard to provide intuitive “user-friendly” interfaces for our applications. Much has been written about visual presentation, and many options for changes to the visual presentation such as “skinning” have been introduced.
Perhaps, however, the most important of all the considerations for an application should be the application response time. I’m not aware of any user who doesn’t get impatient with poor response – defined here as a response time meeting their personal expectation! As more and more users (ADD or otherwise) become frustrated with either speed issues OR for some, the cluttered screen, it seems imperative that we as developers be constantly on the alert for signs of this frustration brewing. My experience would indicate that most computer applications used in a business environment are not being used by “computer” users, but rather by users who understand the task or job they are required to do, and (in some case, regrettably) must use the “computer” to accomplish the task.
Application design is no trivial task!