On testing

Software development is an empirical yet inexact science. It's empirical in that we never write code without exercising it to see if there bugs. It's inexact because exhaustive testing is infeasible except for the most trivial programs--and even then, one has to wonder. And even if we could exercise the code exhaustively there still no guarantee there are no bugs since the specs could be wrong, we misinterpreted the specs, etc. While there are very formal approaches to testing, I have no data on how often they are employed or whether they are effective. It's just that testing is inherently limited by its very nature as Dijkstra observed and therein lies the dilemma. Testing is at least as difficult and probably more so than writing the software being tested. In fact, I spend most of my time and effort, not in formal testing, but informal testing without a test plan. How does that work?

On problem understanding

Problem understanding is really about asking the question, "What to do?" which is a matter of requirements. Why this question is so important is perhaps obvious. The issue is why is there a tendency to jump to the question, "How to do it?" which is about design. I wonder if we somehow instinctively know how hard the "what" is and simply avoid it. Even when it's written in black and white, it is still possible not to understand what to do. That's why there are courts of law and an entire legal system to interpret what is meant by such-and-such and the experts can still get it wrong. Does that mean we really need to understand the entire problem before we start working on it? I have reasons to believe that is impractical and furthermore, doesn't yield good results. Why? Because often we don't know what to do until we do it, or part of it. Only then the picture may become clearer.

After the dust settles

Someone asked Hsueh-dou, "What is the living meaning of Zen?" Hsueh-dou replied, "The mountains are high and the oceans are wide." ~Hsueh-dou (from The Little Zen Calendar)

I sometimes think the same is often true for software development: the mountains are high and the oceans, wide. In other words, there are no shortcuts--or if there are, they aren't yet apparent.

I've worked extensively with three "drag-n-drop" environments that purport to simplify programming: GameMaker, The GameFactory 2, and App Inventor. They are wonderful tools, inventive and colorful. And there are others, perhaps many, like them that I have heard about but not tried.

Yet after the dust settles, after we get past syntax and what Brooks (1986) called the "accidents" of software engineering, what remains?

The things that were there in the first place: problem understanding, testing, and debugging which the above tools, as powerful as they are, do not even begin to address.

Serendipitous driven development

I'm in the middle (quite literally) of working on a Scala research project involving complexity analysis that ostensibly has little to do with Umbo. The effort has been on- and off-again, thinking about it, not thinking about it and not actually writing code for a few weeks. I had other priorities.

I returned to the project today, after realizing during this little hiatus that there was an opportunity to gather more data and generate more interesting results which required writing more code.

So I wrote this extra code today that extracts the method names from the source. Then, I realized that I had tackled the last major hurdle. The only thing was that each obstacle along the path was solved by a separate program, one to strip the comments and count the lines, another to extract the method names, and finally another to parse the byte code instruction count report produced by a third-party utility.

I only needed to integrate these pieces which is a lot easier.

This approach is not new. The Roman empire was built piecemeal, a conquest at a time. We didn't get to the moon with one rocket or even a single launch. I'm just remarking on how the Scala project seemed to come together as such--or at least, there's definitely light at the end of the tunnel now.

What would have been the outcome if I had instead rushed it or been under more pressure to get it done? Suppose that serendipitous hiatus was not there. The effort would probably have lead to a very different solution.

A true story

I was hiking along the path in the park. I was enjoying the exercise, the sun, wind, trees, and grass. It was a beautiful day. I felt very much "present," in the "zone," as it were.

I had been thinking much of the time about the lost & found project, its simplicity and utility, how much I was going to learn and most importantly, what to name it. Every project has to have a code name. It seems somehow to give the effort a kind of center of gravity.

At any rate, a middle age couple, a man and woman, happened to be coming in my direction as I had made my way up the hill. The man stopped, stooped, and picked up an item. I saw it was a necklace, a long chain with a pendant of sorts.

As he stood up and at the instant we passed one another, I overheard him ask his partner, "Do you know if they have a lost and found here"?

Perhaps this was nothing more than a meaningless coincidence. But, I wondered, what was the chance? At that moment, on that day, we're there, the necklace is there, I'm thinking of this, he says that?

I didn't know.

I chuckled and took this little incident to be a hopeful sign of good luck, namely, that I was on the right track--and in more ways than one!

And to acknowledge that sense of good luck and not waste it, I decided to name this project, Umbo, after the  album, Umbo Weti: A Tribute to Leon Thomas (2009), by Babatunde Lea.

User stories

I looked over function point analysis today. It's and old approach from the structured programming days. I had heard much about it in the 80s and today it sounds anachronistic, files, data, physical design, etc. Use cases on the other hand live higher than even the logical view: they are about what to do, not how to do it.

The problem with use cases, however, is the emphasis on documentation and they are "heavy weight" in that sense, not appropriate for agile development.

The user story, as an agile method, cuts right to the chase, as it were: "It captures the 'who', 'what' and 'why' of a requirement in a simple, concise way, often limited in detail by what can be hand-written on a small paper notecard. User stories are written by or for the business user as that user's primary way to influence the functionality of the system being developed." 

Some thoughts on users

However the requirements are expressed, whether in use cases or function points, it seems there are three types of basic users.

1) Someone who lost something
This user needs to report as much as they can about the object of interest, what it is, the location, shape, size, color, version, etc.

Curiously, when I've lost something, it's never one place I'm sure about. It could have been in multiple places. We'll need to deal with that twist.

Also, it would be a knockout if I had a photo of the thing or a link for a version of it.

This person may also want to leave contact information, although the confidential nature of it will need to be protected from casual access.

2) Someone who found something
This user needs to report as much as the can, too, about the object of interest: what it is, the location where it was found, the last location of it (e.g., did they leave it where it was, take it to the lost & found pickup office), etc. And once again having a photo would be dynamite, either of the actual thing or a version of it. And a photo here, too, would be awesome.

This person, too, may want to leave contact information which is protected from casual access.

3) Admins who need to maintain the system
In both of the above cases, these users won't need a login, although something to thwart bots (e.g., CAPTCHA) may be needed.

The admins need to add users who can maintain the system including functions to add other admin users, manage lost & found items, gather statistics, clean out the system, etc.

The admins could also set configuration parameters for the system (e.g., how much old stuff to show, how often to purge the system, etc.).

The admins jobs might also entail contacting the person who lost something. For instance, suppose someone finds a backpack and brings it to the lost & found office. An admin, recognizing that the backpack looks like one reported in the system, could initiate contact with the person looking for their stuff. The admin might simply have the system contact the person via email or text if something was brought to the office and the system notes that fact. If no acknowledgement comes back after say a week, the system might automatically move the item to the recycle bin to be emptied periodically.

Bagging lost-n-found

Ocho Uno (a.k.a., 81) is a cloudy application for managing lost-n-found stuff.

I had for years thought of projects for students to work on until I ran out of ideas. Then it occurred to me: Why should I have all the fun? So for the first time I asked students to come up with their own projects. In turn, they produced some very interesting proposals and ultimately demonstrations, one of them being a system for solving the lost and found problem. They saw the solution as going beyond merely recovering things but furthermore reducing the anxiety of misplacing valuable belongings.

The first student version was an exploration of the concept, namely, the development process. They ultimately implemented a desktop rich client as a prototype per the requirements but we knew it had knockout potential as a mobile app.

I never bored of the idea. They definitely had something that which, at least conceptually, had everything a killer app tended to have: simplicity and utility. Nobody needs to explain it.

Who has ever lost keys, smart phone, book, hat, or rabbit foot? Who has ever found what they were looking for and wasn't deeply grateful?

The lost & found project is an further experiment that builds on all these ideas and experiences.

However, in my view such a system is not about just reporting and/or recovering lost objects. There are the problems of bagging (literally, gathering), matching, cataloging, collating, and often, recycling unclaimed and sometimes unwanted paraphernalia of the throw-away world.