Monthly Archives: June 2009

Crap Code

I wrote a lot of crap code the summer of 1977. It was COBOL and not of the structured variety. Oh, it had a structure and I developed and adhered loosely to many standards I dreamed up, but I knew nothing of structured programming at the time. My boss and mentor hired me based on a referral from my undergraduate college when he was looking for a student for the summer. He saved me from starting either of the two jobs for which I had been hired that summer: nurse’s aid in a nursing home, which is what I had done from ages 17 – 19, and waitressing, a job for which no one who knew me thought me to be a good candidate. Those half-credit courses in COBOL, BASIC, and Fortran during my junior year of college paid off.

That summer I wrote Accounts Payable, Accounts Receivable, General Ledger, Payroll, and Depreciation systems for a storage company, from scratch. I had never taken an accounting course nor worked in that area, so I learned a lot. I learned about debits and credits and what a 10-key was. I was fast. I could write and maintain spaghetti code and manage volumes of important and sensitive data as if I had no clue to the relevance of any of it. There is something to be said for hiring students.

After I learned about structured programming, I was embarrassed by the code I had written. Some years later when I taught COBOL and suggested a student for my old employer to hire for the summer, I let that student know it was important to make sure all of my code was gone or rewritten. She should do as I said and not as I did in my past.

So now that I am back at it again, after a couple of decades away from heads-down coding, my code is more structured, more OO, more easily maintained than my 70’s code…in theory. I’m adding in after posting this that I should be clear that in the 80’s my code was pristine, lovely, elegant, and in the 90’s my OO code employed various elegant design patterns, so spaghetti code is not the only thing I have written.

We started this project as one of the first teams to attempt to use the Model-View-Controller approach with the Zen platform on Cache’ and a MultiValue database implementation. We were new to almost everything about it. Both the MV and AJAX implementations were relatively recent for InterSystems too and the combination of these was not yet out in general release, so there were glitches here and there.

Others on our team had programmed a lot of MV BASIC over the years, while I had not. Most of the production code I have written was COBOL with a good percentage of that being CICS, so I had to learn JavaScript and MV BASIC better, having previously had a bigger-than-a-breadbox taste of each.

With the Zen framework, we are writing XML specifications, OO declarations, SQL against MV structures, MVBASIC and JavaScript methods, html, and CSS. In some cases, every one of these languages is in a single Zen page class. While learning all of these pieces and how they interact, something we are still doing, we often employed a strategy of stopping once something worked. So, if we took four roundtrips when one ought to work, but we can figure out how to make it work with this platform with the four roundtrips to the server, then we get to the point where it works and we move on to the next thing.

I have a bunch of little to mid-sized changes to make to what we have done to date to enhance the user experience, so I’m tempted to do some refactoring of old code based on what I know now. That has risks, will take time, etc, but will also pay off. Once there are customers it is much harder to be proactive about such. On the other hand, one could tweak working code indefinitely too.

I recall playing scrabble with my father-in-law when I knew there was a good move to make, but I wasn’t coming up with it. So I flipped my letters over and asked the others at the table to help me make the optimal word. Bad move. That wasn’t how my husband’s family played the game. I got the results I wanted and even told them they didn’t have to add it to my score. That wasn’t how they played either. Live and learn. I’ve considered asking if either InterSystems experts or peer volunteers could take a look at our code and make suggestions, but I figure that given that we have tons of suggestions when we look at our own code, that approach would not gain enough right now. Once we have something we think is good, then that might be a better time to ask, but I suspect that would be hard to do for a number of reasons, pride being one of them.

I’ll try to make good business decisions on when to refactor, when to do minor changes to improve such things as variable names since our standards have evolved somewhat. Is it ever a good decision to leave crap code in the software? I hate to say it, but probably. I can certainly imagine a good business decision in some cases will mean that there will still be crap code left after going through and making these changes, but I would prefer that everything be top notch, of course.  Hmmm…decisions, decisions.

The Lewis and Clark UX

We had a lovely day on Lewis and Clark lake, behind an Army Core of Engineers dam on the Mighty Mo (the Missouri River) last Friday. We had been to Lake Okoboji on Memorial Day, a fun, busy lake that reminds me of lakes back in Michigan. Lewis and Clark lake is surrounded by state park areas, however. It is quiet. We stayed at the vacation home of friends of ours, a beautiful house on a bluff overlooking this beautiful, peaceful lake.

After boating on the lake for a bit, we stopped to take in nature and settled in to read. I pulled out Don’t Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition I don’t often read such books a second time, but this was a good time in the project to re-read this one, and it was the right-sized book to bring along. It is simple, to the point, and almost like vacation reading, but with less of a plot.

One point Klug makes is that where there are standards in user interface design, it is good to use them or to know why you have opted not to do so. I can certainly agree with that. What might be a reason not to use the same user interface as others do when implementing similar features?

For some design choices, I choose a 1980’s style design over a Web 2.0-like design (and no, I won’t discuss the meaning of that overused marketing term). I want a bit of that simple, rock-solid, ATM-like interface that even my mom would use without thinking it has disrupted life. I don’t want to surprise people with something they don’t want to see.
Or do I? Imagine my surprise when right there on Lewis and Clark lake, where the shore was almost undisturbed by civilization, I spotted a farm (you might call them confinement lots, we call them farms). If you have read previous blogs, you might recognize that one reason for me to get out of town and head to a lake is that I am allergic to cows and pigs and we live ever so close to ever so many of them. Really surprising to me is that I spotted it before I smelled it. Even when we got closer to see that this was a very meticulous farm, it still did not smell much at all.
We later learned that this was a Hudderite farm. The story we were told is that each year each of the men in this Hudderite community draws their job for the coming year out of a hat (metaphorically, at least). I enjoyed the story, enjoyed seeing a farm on this otherwise very secluded lake in spite of typically avoiding such, and enjoyed my entire time on the lake. This farm added to my enjoyment, it did not detract from it.

My Lewis and Clark lake experience recap: I left our farm town to find fresh air on a lake a couple of hours away, only to find that cows and pigs followed me there, showing up on a confinement lot on the shores of the Mighty Mo. What a terrible user experience (UX) this should have been, but it wasn’t. I enjoyed every bit of it. I like confinement lots even less than the average PETA person. It was a surprise, but an oddly good one, to encounter this farm.

Who would have thought that seeing a confinement lot on this lake would have been a good user experience for me? It seems so unlikely. Perhaps the fictitious, but likely, farmer on the boat a mile down from us was disturbed by seeing the farm. But how can anyone know in advance? Maybe on another day under different conditions each of us would have had the opposite reaction.

It really is very hard to know what your users will experience when they use your software. You can do UX testing until the cows come home, and you will learn a lot, but there will still be many mysteries. If you make everything calm and peaceful, like floating on a lake with beautiful weather and undisturbed (ok, that dam was quite the disruption at one time, no doubt) nature all around for miles, maybe that would not be as good a user experience as having users see or do something unexpected, even if not pretty.

From now on when I am surprised in some potentially negative way when doing a pre-UX test of our software, I might just consider the feature to be part of a Lewis and Clark UX.

No Customers Means No Customer Service

Someone once told me that librarians would be happiest if everything were checked in and no one was visiting the library.

We are at the point of needing to have at least a plan for collecting requests, suggestions, issues, and bugs from users. I purposely excluded a help desk application from the design for our software, intending to keep my eyes open for trends and free alternatives.

Twitter. Google for the words customer support twitter and you get close to 50 million hits. Wow!  Most of these are not about getting support for using twitter, they are not about Twitter’s customer service. Just the thought of using twitter for our own customer service is __________ (you choose)! I don’t know at what point simple e-mails and phone calls will be too much for us to handle, but even just one tweet might put me over the edge, and I am not even having them flow to my phone. Am I am too easily overwhelmed? 

If you check out the possibilities for software to help you collect and manage work orders issued by or ideas from users, they are numerous. Lots of software, but not an obvious solution so far, from what I have seen. Anyone with half a mind to write help desk software does, it seems (with a nod to Mark Twain as I think I am paraphrasing him, but googling is not yielding a quotation right off).

Google Groups. I’m not a fan of forums that are not e-mail based, but maybe google groups with their wiki is a good option for some aspects of customer service. That works for me as an InterSystems user for informal chatter as well as solid assistance. My frustration with yahoogroups is quite high right now.

Trac and Bug-trackers. E-mail lists and e-mail software on their own are not good for tracking. Each incident deserves at least a unique number. We are using trac internally for our tickets, but that doesn’t seem quite like the right type of software for public use. I might be wrong about that, because as a user I do like to be able to search for open issues, see what questions and postings others have had, and generally get the lay of the land from a ticket system that is open to the public.

Delay? Certainly with the number of customers we will have the first year of operation, we should be able to manage without putting a big whiz-bang customer service software infrastructure in place. On the other hand, “in place” seems better than “out of sorts.” 

So, if anyone knows any great free. as in beer. tools where we don’t have to do any work other than making a link from our site, and perhaps turning in a circle and reciting a chant, to get customer service software in place, please clue me in. We will be heading into more user experience testing in the coming months. I would like to get something in place for documenting issues or suggesting changes during such testing that can move with us into production. That needs to be tested too, and it can be useful at the same time.

Alas, the design for such, whether homegrown or selected, is not even started, nor can it fit on the plate very well just yet. Oh, yes, I do know that a high percentage of help desk software only had design in the mind of the developer while they were churning out code, and we might very well follow suit on that old tradition, but I hope to avoid that.

We do not have to write this software. While customer service is the new marketing (surely someone else has said this, but I’m not checking) and it must be done well, it is a supporting service to the software we are writing. I would rather not write it. I would rather not think about it at all right now.

While there is something difficult about being in that time where we are developing software with no income, with this posting I will also take a minute to count the roses.  Call me a librarian, but there is something really nice about having software with no users.