Creativity killed the app.

Author: Kasper B. Graversen, 14/07/08
Keywords: Software development, Project Management
Abstract: Developers and testers must carefully consider whether their choices of programming or bug-raising are based on specifications or their personal assumptions about the system. While the intentions may be good, the end-result may be the opposite as illustrated in this article.
subscribe to my RSS feed


Bookmark and Share


Creativity killed the app.

Some time ago, I did a fair but of commuting. 200 km every day to be more exact. I usually got up before the sun and chased to the station around 6:00 am. As I had a long trip ahead of me and it was damn early, my primary objective, next to catching the train, was to fall a sleep as quick as possible. Every morning on the train the same ritual unfolded. And this is where things usually would turn to the worse.

On the very same train, a very friendly sales person was working. He was equipped with trolley holding with various alcoholic beverages - this is England after all! The trolley also had a collection of tea, coffee and various snacks. As the sales person progressed through the carriers attempting to sell his goods, he would call out "fresh tea, coffee, snacks.. anyone?". Now the sales person didn't mind not selling anything. However I noticed that due to his friendly by nature, he would always raise his voice when he approached my closed eyes and body stretching across the seats. On the train I tried ignoring other passengers, the smell of train, and in winter, the cold. Naturally, I would also try to ignore the sales persons calls. After a week of this charade, the friendly sales person tried with a heavier arsenal of items to get me awake. He exclaimed "fresh tea, coffee, snacks, redbull, extra strong coffee..".

At that point I realized that I had to forfeit my strategy of disregarding everything on the train in my quest for inner tranquillity. Instead, I revealed to him my cunning plan of trying to get some sleep on the long journey ahead of me, and that I had no intentions of trying to wake up or stay awake whilst boarded the train. The sales person gasped an "ohh" in surprise and never bothered me again with offers of extra strong coffee etc.

Relating to the world of IT

To understand how this story relates to IT, it is important to realize that the sales person wasn't a bad guy. I genuinely believe that he wanted to help me and I think his attention was a kind gesture. It just so happend, that his thoughts on what was being helpful conflicted with my plans of morning travel.

I've seen the episode with "the friendly sales person" unfold itself in many projects. There are those people, including me, who thinks that the end users are important. They are the reason de'tre of the software we develop and thus an IT systems must assist and support business processes the end-users. So when faced with ill-defined or lack of specification, it is easy to assume how the customer really wants a given feature delivered, and that your personal touch improves the system. And so boards the the friendly sales person the train of software development. Assume you were given the following specification
The user inputs into the search field, signals his interest in searching and the system brings back an answer.
This is a typical vague formulation found in a numerous use cases. It probably raises more questions than answers. How should the search field be fleshed out? If the number of possible search entries is limited, a drop-down box is preferable. Are the number of possible inputs bigger, a text search field is preferable. But how many are there in your part of the system? Do you know for sure?

Maybe you settle with the text entry search field. Now, how should the search be carried out? Should it be case-sensitive? Case insensitive? Should it be wild-card searched? And should the wild cards be explicitly stated? Maybe as a consequence of wild card search, how are multiple search results presented, how are they selected? By mouse-only or is keyboard supported?

In the role of a developer, tester virtually any other role is a software project, be careful not to assume you can improve a system through your personal (twisted?) ideas of how the system is going to be used, or which business processes are meant to be supported. When faced with an illusory specification, pause and reflect whether you should push the specification back to the Business Analyst, rather than cooking up a set of assumptions and code towards these. Similarly, when testing an application. Do not fool yourself into thinking, that the system is broken or is missing features because "it should be able to do this and that". While your attention to detail and your mindfulness of others are definite positive traits, your decision to help may have just the opposite consequences. Consult your business analyst, or the (representative for the) end users prior to you starting to code or raise bugs against your own set of assumptions.

If you found this story food for thought, you may find Jurgen Appelo's story Oh My God, They Fixed the Bug! entertaining as well as interesting. I sure did.



Comments

If you have any comments to this article, please drop me a mail at firstclassthoughts at gmail dot com please indicate if I can't publish whole or parts of your comment on the site.


If you like this site consider subscribing to my RSS feed or how about subscribing by Email.


Help spread the word

Share this post on your favorite social bookmarking sites:
If you enjoyed this article, found it thought provoking, educative or otherwise good, please link to this page from your page or social bookmarking page. If you have any texts you think are worth publishing on First Class Thoughts, don't hesitate to send me a mail! Quality always welcome.


Bookmark and Share


The most recent contributions
28/07/09 Magic in mathematics II Fun with the number cyclic numbers, and specifically with 142857 as it is the smallest of such numbers.
13/07/09 My top 8 time-saving Firefox shortcuts This article presents my favorite top 8 time-saving shortcuts in Firefox 3.0 and Firefox 3.5. Get to know these and you'll be saving a lot of time. They have been ordered by "the element of most surprise"
20/05/09 Board Game Jungle speed / Arriba Review of the cool game "Jungle Speed" aka. "Arriba".
16/05/09 Danish Twin words "Twin words" are words that not only have multiple meanings, they must be composed next to each other in meaningful sentences. This article explores the concept of twin words.
Nothing of interest? Try browsing the entire article archive...