developer.* Blogs - Web UI Design for Data Entry-Oriented Users - Comments

More on work time and integrity

Edward G Nilges — Fri, 07 Oct 2005 00:23:44 -0700

The problem, I think, is that you're essentially thinking on behalf as an agent for your employer, and thinking, unfortunately, includes rationalization: oh, I should visit MSDN to improve my productivity.

Eventually, this becomes use of employer facilities to "relax", where the relaxation is justified by the idea that the employer should support your efforts to chill.

In this connection, the US Tax Court looked at the parallel case of a taxpayer, an accountant, who'd deducted health club bills as a business expense since, he said, the health club visits improved his productivity.

The Tax Court rejected this beancounter's reasoning and their own reasoning was interesting, since, they said, everyone needs to stay healthy in part by getting exercise. But since this need is by no means restricted to the accounting profession, a variant of Kant's "categorical imperative" ("so act that your action can be recommended as a general moral law") means that no one taxpayer should be able to take a deduction for health club dues, since if everyone did, the category of deduction would be meaningless. ANY personal expense could be rationalized as a business expense.

The Tax Court restricted allowable deductions for accountants to accounting books and classes and would probably restrict deductions for developers to computer books. This is problematic, since mathematics and philosophy can in my experience and in good faith assist developers, with about the only category not being useful in some way being pure fiction.

However, we can apply their reasoning to the parallel situation of the work semi-break wherein we visit a technical site to increase our knowledge.

At the same time, the ethical problem is unavoidably compounded by the totalizing pressures of the corporation, because they more or less force the employee to continually adjust the (bad) terms of the bargain by taking excess breaks.

Also, consider that the company "wants" the professional to be as professional as possible, but no more than necessary. I am referring to the anxiety of software managers that their developers "go overboard" and spend too much time on a solution based on the developers' judgement that anything short of this would be unprofessional.

A former manager told me that he recently fired an SQL specialist because the latter had put all logic in stored procedures while the manager felt, after the fact, that most logic should be in client side calls (I think).

Without being fully familiar with the situation, I asked my former manager why he fired a guy for so consistently doing what Microsoft recommends. Nonetheless, I am very familiar with what happens to individual developers who in an inner-directed fashion follow a practice with which managers or their coworkers are unfamiliar, or which their managers and their coworkers know about but which makes the system "harder to maintain".

Sometimes, the charge "harder to maintain" is based exclusively on the unfamiliarity of the practice or even the surface appearance of the code, and since the days of "structured programming" I have seen the charge hurled inappropriately at good code.

For example: many programmers think that "good code" has comments, but many others do not and are particularly apt to dislike literate programming styles.

The problem is that these stylistic objections are convenient to an ethical and professional downsizing at the corporation, where the "needs" of the least able control the quality of the system.

Programmers regard themselves as "professionals", but the Uniform Commercial Code, a sort of template for business law, defines as professional only that employee willing and able to exercise professional judgement. In programming, judgement is replaced by team membership where Job One is finding out what won't bother other developers for the very good reason that it all has to work together.

In my experience, only Extreme and pairwise development solves these problems. You and your buddy naturally control the pace and addictive cascades (where the solitary employee rationalizes addictive behavior on work time, such as playing a computer game, monitoring his investments, or coding unnecessary routines) is forestalled UNLESS both your buddy and you have the same addiction, which is rare.

The fundamental paradox is that in programming, you are doing management in the sense of reifying its rage to control everything and this means that at one and the same time, you have to be a perfect agent while also being a perfect professional. So what happens when you find that management is doing wrong?

Marx felt that all the way down, management (which he referred to as the individual capitalist) was trying to pull a scam, which was the elimination of the worker's humanity EXCEPT for his capability to work and self-reproduce. Marx felt this a scam because over time it would make the worker unable to buy what he produced.

But even if this is true, it doesn't mean we should take back the time by slacking off.

The attraction of programming in former years was that owing to the underdeveloped state of programming work relations, many programmers could quietly expropriate tools and approaches from their employers. For example, H. Ross Perot essentially "stole" the idea of automating health insurance from his first employer, IBM, and used it to set himself and EDS in competition with IBM in a way that is explicitly forbidden to modern developers by universal non-disclosure agreements.

Which is why the only good thing about Perot's otherwise clownish candidacy for president in 1992 was the election of Clinton by the split electorate, for Perot pretended to know more than he did based on the fact that he was "at the right place at the right time in 1966".

More generally, the entrepreneurs I knew circa 1975 who were in fact and in modern legal terms robbing their mainframe employers blind of tools and algorithms they were transporting to micros were distinguished by the familiar arrogance of the conservative with a scam operant, who wonders why we all don't have a scam like him.

Donna's integrity, and her interest in ethics, is MOST refreshing and I am vastly more familiar with this level of honesty in women computing managers. She reminds me of my supervisors at Chubb and Princeton, both of whom were women and who had high standards in this regard.

Whereas all too many male computing managers are ethically challenged. They would never worry if an employee is downloading porn, only that he gets "results" in the form of code that seems to run and more important doesn't offend the dumbest team member.

In China, my experience is that individual developers have high ethical standards based perhaps on Confucianism. One of my coworkers came in on Sunday to manually derive a complex set of symbols from a formal grammar because he didn't trust a free yacc he had to use.

Whereas at the management level, the culture is vastly more "pragmatic" and the managers just want "results". In other words, the individual non-managerial developers want their jobs as programmers to reinforce their self-images as *shih*, gentleman-scholars while the managers base their sense of self-worth on financial results, whether for the company or themselves.

This creates a collision as seen in Mencius, who was asked for "profitable" information by a warlord, but who told the warlord that his information would be "true" and not necessarily profitable.

Work Time and Integrity

Daniel Read — Thu, 06 Oct 2005 07:48:24 -0700

Edward, your comments in the last part of your post remind me of the recent "Integrity Testing" essay by Donna Davis in that you're touching on that gray area between the impossible extreme of dedicating every second and every thought to your employer and the point at which the little diversions become problematic.

Keep in mind...

Edward G Nilges — Wed, 05 Oct 2005 00:22:44 -0700

That the real procedure might be

Click the New Packet button.
Wait while playing Doom.
Switch from mouse to keyboard; enter the data on the first screen.
Switch back to the mouse. Click the Next button.
Wait while emailing Hot Asian Girl Who Wants Green Card.
Read error message from the server; switch back to the keyboard; correct the data entry mistake you made; switch back to the mouse; click Next again.
Wait while checking company stock price.

Or, you could open one browser for each of the 30 paperwork packets you mentioned and if the data doesn't have dependencies you could multithread the above procedures and complete 30 packets by noon. Assuming that the Cobol green-screen application was more tied to data as was often the case, this would be a massive productivity increase. Then you could spend the afternoon emailing your picture to the Hot Asian Girl.

On the job, alienated psychology might unconsciously ignore possibilities for multithreading. The employee, in Marx's terms, has ALREADY sold all of the work day to the employer in exchange for a wage, and Marx thought that at the quantitative point where the employee sells the full-time work day, a qualitative change occurs for unlike the employer and investor, the employee is, in the activity of work, unable to hedge several investments, and his wallet's contents have after payday a one to one isomorphism with the time he has lost, an isomorphism which necessarily immiserates him considered as a class and makes him unable to buy an Ipod Nano.

Whereas if you are primarily an investor (as I admit many smart corporate employees are) you have instead of a wallet with a small amount of cash, a portfolio of multiple instruments each of which is working for you (or, in many cases, soaking you blind: "churn 'em and burn 'em").

For Marx, the working day was a qualtitative break at the end of which we can no longer responsibly equate ourselves with buyers and sellers in a completely "free" market. For example, unlike an exporter here in Hong Kong, we're not free to choose the size of the "batch" (number of hours) we sell.

But, in the case of clerical jobs in front of a client-server computer, the situation may in some small way change, because most alienated corporate employees won't use multiple threads to perform multiple tasks for their employer, or, if they do, they takeback the time by getting all the work done early.

I suppose that if a developer were a total jerk with too much time on his hands, he could monitor the thread pool and advise the user that "n extra threads are available: why aren't you submitting more transactions?"

But the corporate reality is that multiple threading is often used in what lawyers call the "detour and frolic" (lovely phrase, that, with its image of capering on the commons to the hornpipe): playing games or monitoring investments while being "fully productive".

Of course, what we want and deserve is a non-alienated position for an employer who we so respect that we don't pull the detour and frolic. Certain programming jobs are like this, where you are eagerly compiling while working on the next version.

Browser-Based Macro Processing

Daniel Read — Tue, 04 Oct 2005 08:37:22 -0700

Thanks, Edward, for the response. I like the idea of macro processing as an end user productivity aid. In a fat client situation this could be especially handy. However, I wonder if it's even possible using todays Web browser technology. I suppose that with the recent emergence of AJAX as a vehicle toward a more robust client-side programming model we could be moving in a direction that would make that possible.

All this brings me back to the question of whether we should be writing these kinds of applications in a web browser at all. Web browser technology (especially in the 90's) was actually a step backward in terms of user interface design capability from the gains of the client/server revolution, which relied on fat clients with rich interactivity features. I'm thinking now that browsers were in some ways not only a step backwards from c/s, but from character-based, keyboard-based DOS and mainframe applications.

Browsers and web standards are closing the gap on the rich interactivity front, but I don't think there's been much progress on the efficiency front. Programmers need a way in the browser to programatically respond to all kinds of keyboard input (function keys, for example, and Ctrl/Alt/Shift combinations). This would be a good start, and macro recording would go a step beyond. I wonder if there are any movements afoot to make these things happen...

Dan

Fire the Web clowns who haven't actually had a real job?

Edward G Nilges — Mon, 03 Oct 2005 23:57:06 -0700

Throughout the history of business software, Dan, the pattern has been the same.

Some mainframe expert, then some client-server expert, and now some Web expert "designs" a system for the people who do the work, without himself working on the pre-existing application.

Thus in the mainframe era, mainframe analysts and programmers were initially selected from math majors, philosophy majors, and even batik majors, anything but actual file clerks or IBM tabulating operators, because the selected candidates were thought, as degreed people entering the work world, to be more likely to be loyal to management.

Their work product was characterised overall by the same insensitivity to the needs of the people operating the new system for a sensible pace. Sometimes, it speeded up the pace but more often (owing to the actual slowness of the new technology) it slowed the pace down which for a clerical worker can be even worse.

Now, am I NOT making some Luddite point here. Once we got the bugs out of the mainframe system, and also (like me) got some real experience working with and for the real user, the mainframe technology worked better than paper and pencil or the old IBM equipment. The real luddites (textile weavers of Britain circa 1820) simply wanted a more participatory work world and were misrepresented as wreckers.

OK, fast forward to today, and converting client-server and green screen mainframe to the Web. The meta-problem is reification where the designer confuses the "convenience" of unrecordable mouse gestures with ease in executing those same gestures over and over again in production, as opposed to using the keyboard (which in fact lessens the threat of carpal tunnel syndrome, caused in some cases by asymmetrical shoulder moves when the user grabs the mouse).

The reification of the "convenience" of using the mouse, which translates into physical agony for many real users, is opposed in an unquestionable political fashion with the Luddite tendencies of the real end user and clerk, who has become over time a human macro processor, able to execute a series of keyboard operations as a single unit without thinking.

His self-reification was a freely chosen act and deserves, but does not get, our respect. Instead, Romantic language is used to dismiss his embodied concerns.

Mouse movements and indeed any gesture can be reified PROPERLY. This is by designing the Web system consciously not as a system with an unquestionable analog and gesturable interface but as ultimately composed of atomic mouse gestures and keyboard inputs, and the provision, NOT as an afterthought, of a macro language.

There is a privacy concern here, for the explicit record of mouse and keyboard selections can always be used against the employee. But creating this data base may be preferable to the current situation, in which unmonitored employees in America, treated to management's systematic and ideological contempt for their bodies and their work, "game" the invisibility of their work to play literal games on the Web while looking "productive".

There are massive technical concerns as well. If you "record" mouse motion to coordinates, you are ignoring the fact that the user's intent isn't to move to coordinates but to something meaningful to him such as a field on a window, and this means that the ontology of the macro processor has to be the user's screen ontology, and to consist of large-scale objects, not twips or pixels.

Then, the real end user, once he learns the new sequence of required mouse gestures and keystrokes to process the batch, can assign this sequence to a function key.

In fact, if the designers know how to write threaded code, the end user can strike F12 thirty times, to call up thirty small windows on which he can enter the smallest possible set of keystrokes (containing only the actually needed data), using his trust in the competence of the threaded code writers (a trust often misplaced) to know that each individual batch will be processed correctly.

Of course, he also has to trust the OS which might mean that such humanized schemes work best on Linux and not Windows.

The problem in real development groups is that the (typically male) designers have never had a "real" clerical job and worse think themselves superior to end users. For this reason, they regard the approach of designing a system from the ground up as having a macro processor as unnecessary.

You can today buy any number of Windows programs which capture mouse movements and keystrokes. The problem is that these programs are designed exclusively for the "power" user because in our society, the sort of people who end up in clerical jobs are not thought to be able to program, even if they are restricted to straight-line code (which in my view they should not be).

The contempt for real end users becomes an ideological contempt for the geek who himself would like to develop a macro processor for his own use and share it with the user.

This whole syndrome is an artifact of the Taylorist American contempt, which was interestingly enough shared by Lenin, for actual workers and their ability to plan their work. It is largely absent in Scandinavian countries and the Norwegian computer consultant Tom Gilb has over time written a number of works for analysts and programmers (such as Humanized Input) to show them how to program for REAL "users" as opposed to managerial thugs.

Now, I realize, Dan, that my intemperate language is a good way to get shown the door as a consultant, especially in the Fundamentalist climate of modern American business. Weinberg was able to solve the equation represented by the contradiction (pointed out in Harry Braverman's Labor and Monopoly Capital) between management's need for control and its need for results.

The problem today is that management controls, or wants to control, more reality than in 1972, including mathematical and clerical reality.

My solution is for the developer to be able to write parsers and develop tools such as macro processors so quickly, and with such skill, that he can do so "under the rose" (sub rosa) and pass them off to the real end user quietly.

But this means that later on, maintenance programmers open up a "simple" system and to their horror, discover a compiler for a macro language that supports the Bohm-Jacopini primitives, in which the real end user has automated her work under the tutelage of the original consultant, who be chilling on the beach on Lamma Island.

And if you don't know what you are doing, my approach can create a real horror show. So I recommend it with some trepidation, or to use your lovely neologistic adverb trepitatiously.

Web UI Design for Data Entry-Oriented Users

Daniel Read — Mon, 03 Oct 2005 17:17:59 -0700

You may be able to deal with this situation when buying a book online, but it's just unacceptable when you have 30+ paperwork packets per day to process. So even though you have your new web app, you're not using it, and the machine with the vulture on top is still humming away.