The Human Problem In Developing Unique and Wonderful Software (Usability and Learning Curve)

This post details an important issue in programming (and in the development of solutions which solve certain problems): the problem of human nature. It outlines my experience and the lessons which I have learned. I will share them for the benefit of

our readers.

What happened? What was the problem?

I had originally created all the data a client needed and more – streamlined and efficiently placed in pivot tables – in neat rows and columns that allow you to configure and query the data to find out anything and everything you need to know. To me it was a no brainer – surely they’d opt for this solution over the earlier inefficient solution. This data basically was a list of items that needed to be ordered, their quantities, and lengths, listed by the panel number which they were to be cast in. It’s like giving you the power of the sun, but in the palm of your hand. It’s amazing!

I presented this solution to the client, hoping that they would appreciate it and understand its value, its beauty and simplicity. It sure beat the old fashioned way by which items were ordered: hand counted and then manually compiled into a table in AutoCAD – of all places – yes you read correctly, in AutoCAD, not Excel or some RDMS. From AutoCAD, revisions are nearly impossible to track, especially when you have thousands and thousands of items to be ordered. And from there, from the AutoCAD drawing, that data is then again **manually** recompiled into another Excel spreadsheet that sits at the client office. There is so much duplication, needless inefficiencies, and the potential to make costly mistakes. It’s crazy!

What if there were revisions to say, 100 panels? Wouldn’t it be handy to know that you don’t need to order an extra 30 or so cast in plates (given they were previously ordered) – and cast in plates ain’t cheap? It’s a walk in the park for a pivot table. But there just one problem: that was not what the client wanted.

What was the lesson to be learned?

Nope: the client wants their data presented in a certain way, in a certain style. Pivot tables are a whole new kettle of fish. The client does not want Excel. The client wants AutoCAD. And moreover, that data must be presented in a certain style: red text, white lines, and the curious anomaly of those sheets having the same data unnecessarily repeated numerous times throughout the same page.  Now that’s fine by me. But it raises a very important lesson which is worth sharing:

1. Don’t depart too far from what your users are used to. If you do, they simply won’t use it or appreciate your solution. In this case, the pivot tables were too big a leap. It is not easy and it’s complicated. It’s like presenting to users Git, and telling them that it will solve all their version control problems – when those users are used to simply “Saving As” – as their version control system. It’s too big a leap and too far a learning curve.
2. Give them what they want: Your customer wants red text. Give that to him. Your customer wants white lines: give that to her. Sure, you have an obligations to suggest other alternatives which may be of benefit to them – but at the end of the day, it’s their call. Don’t argue with them about what is best for them: shut up and simply give ‘em what they want! This is the most important lesson that I learned.

Would be curious to hear your thoughts.