May, 2008

Small Business Application Development and Use Cases

While there is no shortage of writing available on the internet or in software development textbooks regarding the various software development methodologies available, I find that the great majority of it is really geared toward managing large projects for large companies.  Since I develop for small and medium size businesses who often have very limited budgets for development, I am always interested in the processes and methodologies that can help me produce better software for my clients.  My clients IT infrastructures often leave something to be desired - and therefore often I become an infrastructure consultant as well as software developer.

My reading this week pointed me to an article on the SearchSoftwareQuality site entitled “Useful app dev practices trump full-blown processes.”  The article, written about prominent software methodologist Ivar Jacobson touches on how Jacobson is willing to rethink processes and practices, something which is always difficult to do either because of time constraints or because of being reluctant to admit that something which you previously had thought was so great - perhaps isn’t, or needs to be modified.

Custom application software needs to be reviewed regularly in order to maintain or increase its value as it is used.  This is no trivial task.  I’m currently in the process of conducting 2 such reviews for clients, and they are taking considerable time — and it is these reviews which bring me to “Use Cases” and another article titled “Five use case traps to avoid“.  Use cases can be a very valuable methodology to incorporate when reviewing existing software, procedures and planning future rewrites or modifications to the application - even for small projects, creating such a document will help solidify understanding and communication among the analyst, developer/programmer and client.

Robotic Arm Programming, Mars and Agile Methods?

I read with great interest an article about the recently successful Mars Lander “NASA: Robotic arm key to finding life on Mars”  In particular what caught my attention was that the programmers for the mission are sending daily code updates to Mars to guide the robotic arm as it gathers and prepares sample for analysis.  They are on a daily schedule of writing, testing and sending new code sequences to their “baby” on Mars!  Sounds like a story straight out of science fiction!  (I wonder if this is considered an Agile team

The article refers to the sequences taking about 20 minutes, and then 12-16 hours later feedback from the Lander.  Certainly there’s no pressure to get the code right the first time - is there?  Well, there is also the pride of the development team — my hats off to salute them!  What an accomplishment!  Man and machine, working together - what a team!

May our programming future enable such flexibility, whether we program for business, medical or space exploration.

Developer Responsibility, Ethics and Attitude

I have heard too many stories in my years as a developer, of clients being taken advantage of by either inept developers or downright unethical schemes used to enrich the pockets of the developer.  I remember being shocked when a developer I met with talked about his clients only in the sense of them being “his revenue stream”.  The developer cared not one bit about the quality of what he provided (and clients were in fact very unhappy), what he cared about was giving them the minimum in order to protect his revenue stream.

Yes, certainly the revenue stream is important, but I do not believe it is all important.  Personally I believe that a developer has a responsibility to the client to provide service to the client which meets or exceeds the value intended for the project.  The attitude which has the customer as only a “revenue stream” is not one I respect. 

There are times when I will be asked by a customer to work with another developer with whom I’ve not worked before.  This is always an uncomfortable situation to be placed into since I find myself working with another whose attitudes and ethics I am not familiar with.  To further complicate matters in most instances I am new to the customer as well - so I don’t know the attitudes or ethics of the client either.  One situation that I ran into a few years back was a nightmare - clash after clash of values and ethical standards.  I couldn’t wait to get away from that situation.

The Half-Life of New Technology

The concept of half-life has always intrigued me, particularly so when I was introduced to the idea of the half-life of material possessions.  Wikipedia states “The half-life of a quantity whose value decreases with time is the interval required for the quantity to decay to half of its original value.”  In terms of technology I find it particularly interesting to follow the latest “gadgets” that seem to become “must-have”, and within a very short time span are found to be arriving at their half-life within a month or two, soon to be replaced with the newest “must-have”.

Perusing the latest issue of Entrepreneur magazine in their “Looks that Thrill” section I noted the “candy-bar” style phone by Motorola (ROKR E8), and wondered what the half-life of this device will be for its users.  The device combines phone, music player and camera in a very elegant design - but what is its real value?  Is it a device which will gain value as time goes on, or will it end up with a short half-life?  An idea that “…seemed like a good idea at the time…”, but doesn’t pass the test of time.

Applications can have a short half-life also — and when an application is put together and implemented, only to be used minimally for a short period of time, and decreases in value as time goes on — it is a sign of poor planning for the project.  Perhaps the project was one that was done because a “cool” technology could be used for it, but just because technology enables an ability doesn’t always mean that it “should” be used.  In other words, the value doesn’t really exist.  It is my belief that an application being created should increase exponentially in value as it gets used, and yes, certainly at some point it does begin to decrease in value, but beware of the short half-life application, chances are there was little value to be provided by the project right from the start.

Thoughts on Agile Methods

I ran into an article published back in January 2007 entitled “We are all Agilists now“, written by Matt Stephens.   As an independent developer since reading about Agile methods I’ve always been interested in the whole concept of Agile particularly as it would apply to the small developer group - especially the group that is geographically challenged. 

Stephens’ choice of title caught my eye and I liked what I saw.  The concept of agility as more a state of mind than a set of concrete practices I found particularly interesting.  I found the article thought provoking and worth the read - perhaps you will as well. 

Holiday Weekend Work and the Independent Developer

It seems I’ve often found myself in the position where a project I was working on required a concentrated effort on my part during a holiday weekend, and this Memorial Day weekend is no exception for me. 

A long weekend is actually a time when I really do prefer to work with application upgrades for my clients.  For one thing, it offers the longest time window that I have to work with live data to do table field additions, table changes or add/change indexing.  I’m fortunate in that only one of my clients requries 24×7 use of their database.

However, if I’m going to be doing such work over a holiday weekend, I want to make the time invested really matter.  Detailed planning and testing ahead of time really helps accomplish the tasks required in an efficient manner.  This tends to be an area where I use my “virtual” network extensively — develop on one machine, test from others.

If I’m going to be doing development work over a holiday weekend I really don’t want it to be just like any other day — in other words I’m looking for my holiday weekend work to be stress-free, who needs hassle on a weekend?  Certainly not me!  That’s why more than any other time I come into the work really knowing what to expect (besides the un-expected).  “Plan your work, then work your plan” is always a good method — but for me, prior to my holiday weekend work it’s a must!

IT, Application Development and Life

WOW!  What a ride it’s been!  For most people in the USA this weekend is a holiday weekend — but then there are those others of us for whom it is another holiday weekend where we get to work while others have their family cookouts and first weekends at the summer home or otherwise celebrate.  You have to love IT be able to take it all in stride — weekends, odd schedules and seemingly endless demands run with the territory.

 I was reminded once again this week of the “seemingly endless demands” on application human interfaces, and the difficulties encountered when the interface falls short of providing the user who knows the job they must do with an intuitive enough interface to just go to the system and “do their job”. 

 Picture this if you can — a busy hospital emergency room with patients overflowing into the hallway waiting for rooms — and a group of 4 ER workers trying to figure out how to get to what they needed to get to.  “I know you can get to it” says one, and another says “Here — let me try!”.  Other bits of conversation overheard included “I seem to remember something about this in the training - but we just didn’t get enough time to work with it.  (I was waiting with one of the patients in th hallway where the terminal was located).

What’s wrong with this picture?  What I observed just seems to fall in line with what I’ve always felt to be part of the job of the software developer — seems to me I’ve blogged about it before also :-).  I guess all this goes to show that IT, Application Development and “life” needs to co-exist smoothly.

Thoughts on the Career Software Developer and IT

Ron Richards in his post “The career software developer…” alludes to the observation that “…it is not surprising to discover that there are more people scoping, managing, testing and supporting the work of software developers than there are software developers.”  I would have to say that I believe this is a sign of hope for software applications - or at least it could be, depending upon just how well those performing in these support roles can identify and communicate, or otherwise translate user and operational needs into the formats for the career programmer or software engineer to do their job most effectively.

I recall a situation a few years back where I was part of a group evaluating potential ERP systems designed for the particular vertical market of the business.  One of the biggest selling points of the vendor finally chosen was that their software didn’t originate from software development guru’s, but rather from the roots of key company players who were firmly entrenched in the vertical market for which the software was created, and through the years they had developed and enhanced their product to keep up with the needs of the market.  Sounds good, makes sense, but the reality was that much of their successive revisions and enhancements after their early years were more created to boost sales or meet changing technology requirements.  Hence their system rather than being updated with re-design was rather “patched” together as a patchwork quilt.

I don’t believe that the career IT professional needs to start out as a programmer of software developer.  What I DO believe VERY STRONGLY is that to be most effective the career IT professional MUST understand the business of their employer to a level I suspect very few do.  Perhaps I think as I do because my introduction to IT had its roots in software quality assurance, though it really was more like software evaluation.  The company developers hated to see me wander into their offices - they knew I probably had another “brainstorm” about a feature that should be added. 

I believe that the most valuable IT professionals are those with an understanding of the business, an ability to adapt, a keen eye for opportunity and a burning desire to make a difference to their organization.  These professionals are not necessarily the “guru’s”, and in all probability are not.  Of course, being a bit crazy also helps!

Are Users Really “Trainable”? Should they Need Training?

I have developed a reputation around the way I work with users that I am “training” and who display various levels of skill (or non-skill) with their computer system.  From executive levels to the warehouse user my reputation for telling a new user something like “…see - I told you you were ”trainable” has become noted.  Naturally this statement gets many different reactions, but it is always meant as a compliment to the trainees natural ability to use their computer as a tool for accomplishing their job which they “know” how to do. 

That said, in my opinion their “natural ability” to use the tool depends solely upon the application interface.  Should users need to be trained or should they just be able to use an application if they know how to do their job?  It is a lofty goal for sure to think that new users (who know the job they need to do) can instinctively sit down and be able to do their computer tasks without training — but one I believe in.

Now, let the record be set straight — while I may always strive for that in my program / interface design, I seldom achieve it.  But like users, I’m trainable — and that is where listening to and observing users comes in.  My users have very definitely trained me through the years to be more aware and observant of their needs. 

Probably the best example I could give regarding user interface would be the custom order entry system that I was building a number of years back.  I kept getting feedback from the primary users - the ones using it day after day - that it “just didn’t seem right to them”.  I heard their “complaints” initially as that it just wasn’t the way they used to do it.  However, after this went on for a few weeks I volunteered to fill-in for one of the users and do the job for a few hours myself, using my program.  WOW - did I learn a lot!

I learned that my idea of efficient and what they really needed were two different things - and the program was updated within the next few days, and that truly is the way I think it should be.  Yes, users ARE trainable — but I really don’t think any application user interface  should be so complicated that it requires the significant training often associated with implementing something like an ERP system.  Train for the job, the tool use should be instinctive.

Technology Sales Styles

A recent article that I saw in a Computerworld email caught my eye and my interest.  The article “The six most infuriating tech sales styles” had me salivating at the very thought of the possible content contained in the article even before I opened it up!  The way I figure it, most of us that have been in IT management and around the “tech sales” arena can identify many of the types referred to in the article, I certainly can.  Heck, some of us might even BE one!

The article states “…That IT salespeople just don’t listen is a familiar refrain from technology buyers…”, and that “…too few of them act as honest advisors and problem-solvers…”.  Isn’t THAT the truth!  Just thinking about the recent experience that I’ve had trying to find proper RAM for an older server has brought at least 3 of the “infuriating” sales types into focus for me.  Continued »