We all know what it means to assume — but sometimes our assumptions are so completely hidden from us that we don’t even know when we are assuming.
I had an iinteresting conversation with another developer last week that illustrates this point (…and a few others that I’ve blogged about also). It seems that my developer friend had been involved in a project for another developer who had created an apparently extensive (read as complete) almost 80 page specification regarding what the application was to accomplish, and how. Required tables and fields had been defined, as had been the associated indexs for the tables. (Personally, by the time I would have developed such a document I could have had a significant portion of the program created – but that is another story!).
In the development process all appeared to be proceeding as desired — and then the customer began testing. It seems that with one of the tables the documented indexes reflected a configuration which would allow duplicate child records – not what was desired – but what the spec allowed. An assumption was made on the part of the developer writing the code that since the index allowed for duplicates, then duplicates must be desired and programmed to allow them (…all the while knowing that it was not usual).
This one instance indicates a problem that all developers face. In my experience, it seems that no matter how detailed the spec, there always seems to be some underlying assumptions being made – and they make for keeping our jobs interesting.
On a visit to my chiropractor today I heard a story that I found simply amazing to believe, yet I have to believe it as I was witness to some of the “events” a few years ago – and I remember them well!
It seems that some 6-8 years back my chiropractor (always on the lookout for a “good” deal) was in need of software to handle her business – appointment scheduling, billing – the “usual” stuff for a small practice. I remember this period as I had been shaking my head on more than one occasion as her employee struggled with the system that was being used. I also remember her excitement that she had ordered a new system that was really going to be much better than what she was using – and she couldn’t wait until it got installed so that she could address some of the “issues” she’d had with her existing system.
Well, making a long story short, let’s just say that it was a LONG time before improvements were noted by this loyal patient of hers. She struggled seemingly at every turn – reports didn’t work properly, things didn’t balance – just an apparently endless array of “issues” with this new system that was supposed to solve so many of her problems. “User friendly” was not how she described her new system at the time.
Interestingly enough, today after I commented about “…good thing your computer system is user friendly…” (her new office person was struggling with some entry is what prompted my remark) — she asked me if I remembered all the problems she used to have with the system? (I acknowledged that I indeed did!). At that point in time she told me “…I really didn’t understand what being a beta tester really meant! They gave me deep discounts!…”
Indeed they should have given her the software for free from my perspective — her beta testing was more like an alpha site – only she was running live! I chose not to ask her if she would buy into a beta testing again.
However, what I took away from this today was that if deeply discounted pricing is provided to a customer in return for being a beta test site — the developer had better convey VERY clearly to the customer just what it means to be a beta test site for them. It seems that in this case the expectations were not clear – the result appears to have been that the 5 years of high employee turnover, retraining, and resulting frustrations and inefficiencies probably cost a great deal more than paying for a proven product would have been.
Of course, I could be wrong!
I had an opportunity to witness once again the user frustration when software doesn’t perform according to expectation – in this case – the expectation unfulfilled was intuitiveness.
The scenario involved plugging in a Windows XP laptop into a network with no DHCP. (Networks I work with are all small enough that there really is no need for DHCP – and there are advantages to using a fixed IP scheme). In this case the simplicity desired was that by creating an alternate IP configuration the laptop (whose primary configuration was expecting DHCP provided IP address) would just use the alternate since no DHCP was available. Of course, it didn’t work.
In order to get the laptop onto the network we had to change the primary connection to use the “fixed” IP that we wanted — after that there was NO alternate configuration tab. (I wouldn’t have designed it that way!) . It was late evening, we were tired, we just took the easy route to get the laptop onto the internet. However, somehow it seems that we shouldn’t have had to look at help (sometimes not exactly helpful) to find an answer.
As I write this I am really wondering whether business intelligence and dashboards really go along with small business reporting. Now, I am not particularly analytical – nor am I a fan of statistics in general. However, when it comes to looking at business data I find myself constantly looking to create relationships to and amidst the data I’m looking at. For example, I might look at a report of production from a particular type of machine which shows high dollars shipped. Then I might wonder — well — great that we shipped so much – but how much profit was produced? How does that compare to last month? Last Year? etc. One question leads to another.
This scenario is perfect for the creation of a “dashboard” presentation. However, very much like the “business intelligence” applications that are available, creating the dashboard can be cost prohibitive. What a shame!
In my opinion the well run small business, be they multi-location or single-location, has perhaps more to gain from such information availability and presentation than does the larger company. There is more at stake for the smaller company.
I find myself constantly on the lookout for reasonably priced software (under $1000 – preferably in the $500-600 range) which can be used to create such a reporting application. For the small businesses that I deal with, spending $25,000 or so for a BI/Dashboard application just doesn’t make it. What I have found so far as a tool to use to create the application I’d like to provide is very expensive, cumbersome to use, and requires extensive programming beyond my particular skill set.
Where’s my reasonably priced tool out there? I’ll be searching, but if you have pointers please respond to this blog and help all of us out.
I don’t usually find myself paying much attention to Microsoft’s “previews of coming attractions”, or even checking them out when I see a link. However, when looking at the latest WServerNews references to Windows 7 I had to check it out – and I’m glad I did.
While the article presented some interesting comments on Windows 7, it also provided a link to a WndowsVista blog entry where a short demo of the developing Microsoft multi-touch screen technology can be viewed. This demo had my mind swirling once again at how this technology might be used in the business environments where I work — my mind was running wild with ideas of how I might use it.
I wonder just how long it will be before such technology will find its way into common usage – maybe 5 years?
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.
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.
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 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.
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.