Open Source Software, Self Service Software

Have you ever used those self-service checkout machines at a grocery store or supermarket?

This is a companion discussion topic for the original blog entry at:

When the grocery store next to the office finally put in self-serve checkout lines, one of our developers had a chat with the manager. It seems that there are levels of machines. The inexpensive ones have errors for no reason, the scales get out of calibration, and they require a lot of cashier support. The really good ones (and I don’t know what the price difference was) are reliable, have a good UI, are error-tolerant, and generally much easier to work with. This store put in the really good ones, and despite shopping there several times a week, I’ve never had an issue with them. They let you scan ahead of the UI (I believe the UI actually stops some of the detailed hand-holding if you’re fast enough), and they don’t require a cashier to come unlock them if you commit the horrible sin of picking up your bag while the CC transaction finishes. I know of one person who crashed one when he scanned his loyalty card as a bar code instead of using the card reader, but that’s been fixed. And the manager does his managing from the area around the machines, so when it’s quiet, I’ve seen him spend time with some of the elderly customers, teaching them how to use the machines.

All-in-all, it’s a pleasure to use them. The same can not be said of many other installations I’ve seen.

Isn’t the community for OpenOffice users not programmers, for the most part?

Open source blather works great for things programmers like to work on (or have to use to make a living, and thus have a motive to make work well, for their ends).

(And none of this affects the problems of collaborative interface design by programmers. I don’t think those problems are soluble without changing the collaborative and by programmers parts.)

I loved the idea of Linux, an alternative to the MS malevolent kingdom, until I started having to use it myself at an DOE lab while I was in college. The elitism was too stifling, any time I went on an forum to ask a question I was treated as crap. As a disclaimer, the staff at the DOE lab were very nice.
I still admit that Linux is a better product, but I cannot endure the EGO’s that go with it.
I see this attitude in open source in general. Sometimes it’s just better(not always there are some great open source products out there) to pay the money and be done with it.

The big problem I have with OpenOffice is not that it is a MS Office clone, but that it isn’t a good enough clone. Calc, in particular, has a lot of issues relating to formatting cells in a spreadsheet, particularly in the area of borders and fill patterns. Not only does it lose formatting from imported Excel spreadsheets, it doesn’t even keep its own formatting consistently under modifications to the cells. That’s a problem when it loses formatting that conveys semantic information.

No, I haven’t taken the time to try to file bug reports or fix the code; it’s often easier to just fix the immediate problem and move on. But I should note that this is an area where it’s hard to write good unit tests, since the failure is related to the appearance of the output on the screen or printed page, which are hard to sense automatically.

The problems of Open Office development have been looked at time and again and one issue that comes up again and again is the code organization.

My understanding is that it takes a good deal of time to even start to understand the codebase.

From there, if takes a while to prove that you understand enough to be able to contribute in non-harming ways.

I thought the 3.x+ versions were focusing on breaking the code into more manageable and grokkable parts. Anybody know of the progress of these things?

Forget to mention Excel. Thanks Dave. :slight_smile:
Excel is the best office product that I have ever used!! And I’ve used a bunch (does anyone else remember Star?). It alone is reason for MS.

I know this has nothing to do with programming, but…

People who support self-checkout systems have no right to complain when their 16 year old son/daughter applies to 100 different stores and still can’t get a job because none of them are hiring.

Just like we’ve alway said…computers are cheaper than humans, right? Sometimes this backfires.

Tom DeMarco goes into this in some depth in his book Slack. I can’t remember the original quote (and someone has borrowed my copy and hasn’t yet returned it), but it was something like this:

In a volunteer organization, the flexibility to decide how you are going to do something is the payment for doing it. If, as a manager, you take this control away, you find yourself without volunteers – and hence doing it yourself.

So, if you’re having difficulty getting software developers to participate in your open source project, I’d say the community isn’t failing your project. Your project is failing the community.

Amen! But do you have a concrete suggestion to the OOo management?

After the Kohei story it looks like OpenOffice is doomed without an independent foundation.

Had to be done - sorry Jeff! I like the comparison. As for your problems with self-checkout I find that people that would have problems with them generally steer clear. I’m assuming the same would go with OSS. If you aren’t comfortable with your abilities and skills, you aren’t going to contribute.

Maybe the solution (or part of a solution) would be to make the adoption barrier easier by providing tutorials on how to contribute. By providing lists of fixes that are required. By advertising which sections of code need to be created or maintained.

I’m aware of bug databases and requirements, but I’m thinking more along the lines of the following:

C++ programmer to fix bug #123 [ link to bug ] in project. Likely source code is [ here ].


Python developer to help implement X feature in Y product.

On the otherhand, providing specifications to enthusiastic developers would probably mean that person has the time to implement the feature themselves.

For instance, I probably wouldn’t mind contributing to a project, but I don’t know which project I’d like to help with or where to start. People say ‘check out the bug databses and issue a patch’. I hear look for a bug description, download source code, look through the mountain of code, fix it, and sit on it.

My .02.

Could the problem be that the people who actually want to use OpenOffice are not the people who can or want to contribute to open source projects? Programmer focused tools (Linux, Emacs, vi, etc) never seem to have trouble attracting talent.

I’ve always been an advocate of the ‘one strong leader’ philosophy myself. After that, you can have whatever levels of politics you like to delegate tasks to, to make recommendations, to answer the questions that the leader needs answering - but there must always be one single voice of ultimate authority, if you ever want to get things done.

I used to disagree with this philosophy entirely, as I suspect many readers here will, thinking that people who can’t make democracy-based organisation work are the problem. What I believe now is that pretty much everyone on the planet is in that group, myself included, and very few of them realise it.

People with a chance to have a say rarely let that chance pass them by, even if they have nothing worthwhile to do with it.

I think the main problem of Open Office is, that it still feels slow, bloated and ugly. I doubt there is much they can do about it, besides rewriting large parts of the software.

But there’s only one me, and at most a half-dozen other checkers working the store, compared to the multitudes of customers. It doesn’t scale.

Sorry, doesn’t work as you want. There’s still a limited number of self-service checkout devices. Sure, in some supermarkets many lines are not manned all the time, and this would be an improvement, but there’s still an imbalance between customers paying and lines.

Hey Now Jeff,

Great comparison.

Coding Horror Fan,

The problem with Open Office is that developers don’t use office.

At risk of diverting into the whys and wherefores of supermarket operation, I’d like to see more of the automated checkouts which work by having a scanner that you take round the store, scanning the items as you take them off the shelf.

This is because even in a crowded store, individual products are pretty much uncontended. There are thousands of lines in the supermarket, and maybe only a couple hundred folks in there at most. And even if I do have to wait for someone to scan their item (and there’s no reason why they couldn’t remove the item from the shelf, move away and then scan it if that shelf is popular) it will take me an extra three or four seconds at most.

The checkouts, on the other hand - there might be only a dozen or so of those. So it’s not efficient to have a time-consuming process such as scanning all your items happen here. Far better to do the scanning before (when there is spare capacity for it) and reduce the checkout (which doesn’t have spare capacity) down to the only the relatively fast operation of payment.

This works if we shop with the big re-usable type of shopping bag - because there’s no need to unload and then bag groceries at the checkout. They already got scanned when they went in the bag. Providing the checkout system knows the weight of the bag (most automated checkout systems I’ve seen enforce honesty on the basis of checking the weight of your bag against the expected weight of what you said you bought) all you need is to weigh each bag on the way out to make sure it tallies.

In programming terms, this is effectively precomputing results while you have spare processing time in order to maximise throughput in a performance-critical loop. Perhaps more developers should take sabbaticals to run retail businesses. :slight_smile:

Timberwolf, have you seen this? Related to checkout: