Polynomial!

The GUI-Usability-Fallacy

In my previous post I linked to that "Framework Studio" which I read about in the German dot.net magazin a while ago.

I just revisited their site and, browsing a screenshots section, encountered a typical example of what I'd like to call the GUI fallacy. Click the screenshot on the right for an example of what I mean. Somebody has obviously taken great care to give their application a "modern, fresh user interface". Maybe some manager demanded it as a "must-have" in "our competitive market", who knows. One can well imagine how a former version of the product may have looked typically gray and cluttered with information overload. Especially in the business market, you often have manager selling to managers, depending on those managers sometimes with decisions that annoy and demotivate the producers (developers) or the end users (some secretary?) or worse, both.

So now we have a "fresh, modern interface", that box is ticked, maybe they looked to iTunes or something for inspiration, done. But will it be any more pleasant to use? From the looks of it, I doubt it. (I will grant that judging a book from its covers is a risky business, but let me stress this: the customers, or rather, those who will have to use the system, do care; it highly influences their evaluation of a product as Ian Landsman so aptly pointed out.)

So merely judging from the screenshot, it seems to me that the graphics are all shiny, but the the program must be a pain to use. User interface without usability, that's what I call the GUI fallacy. "Just modernize the looks a bit, and we're done."

Who designs such interfaces? Who wants to work with that? People will work with that, no doubt: they have to, once they bought the product. But it is just a matter of time for a more attractive opportunity to materialize just right when they are ready to switch. That kind of GUI really makes it easy for its users to switch (ignoring the general hesitation of most to switch, especially when the financial stakes are high, which is probably the reason why badly designed applications are still so widespread).

But don't count on it.

Ah, the joys of reuse... but beware of productization

After I have decided to go for the localization tool (I find it difficult to blog about it without having a proper name for it first—usually, apart from my dubious company name, naming is not one of my weaknesses), I moved a great deal of the codebase of my other product development into a separate DLL for reuse. That class library, dubbed AuthorBase, now provides a pretty complete framework to easily and quickly create the scaffolding for an application that has some or all of the following requirements:

• A windowing system that allows for tabbed windows, separated into tool windows and document windows (similar to IDEs such as Visual Studio, Eclipse, or SharpDevelop, although my system does not support draggable or floatable windows—they are merely tabbed intelligently and can be re-arranged within their tabbing container)
• A 'project file'-based work flow, with all kinds of editors for all kinds of file types already built into the framework and easily extensible
• The application can extend the framework in specialized manners only, such as: extending the option dialog by additional tabs / sub tabs / option groups / options, extending the types of projects or items that are supported by the application, etc.
• There are standard commands (such as file, editing and formatting commands) and commands can be sent between tabbed windows
• Properties can be marked up to be persisted to and restored from user settings, this is done automatically on start-up and shut-down of the application
• There are pre-existing, but customizable standard windows such as splash screen, Start, Options, Create New Project wizard, Integrated Web Browser, Project Explorer, Properties and many more to come.

Since these are base features required by both my two forthcoming products, I have just halved the time taken for these base features per application simply by adding another application...  ;)

Both products belong to that strange hybrid application category that is authoring as well as productivity as well as developer tool (but in both cases, also offered to and usable by non-developers alike), so that shared code was the sensible thing to do. It also means that any further innovations (to user interface, usability, or even code-related stuff such as performance or the support of additional standard editors, say) are introduced to all applications utilizing AuthorBase.

A framework is not necessarily a product.

I'll admit it, AuthorBase was once a product idea of mine. Maybe it re-evolves into one, but I didn't go for it because although I saw a need for myself, I found the idea of pitching such a framework to development teams quite scary. That's a different matter with the two products I'm now developing: they, too, address issues that developers or development teams have, but they don't impose a certain architecture on their codebase, they merely offer outside-the-IDE process support to certain "orthogonal" concerns (such as localization) of their jobs.

Trying to sell generalized frameworks such as AuthorBase must be tough, because you are effectively selling a certain approach to application design. For prospective customers, that could be a real gain in time-savings, but there is simply a substantial risk involved: what if the off-the-shelf application design they purchased turns out to be crap? As programmers, how would they know before the market tells them, which would be too late?

In my opinion this is a very real risk that should be taken to heart and addressed by anyone attempting to sell products that essentially revolve around the idea of saving customers time by providing them with a fill-in-the-blanks application design. [1] My framework works for me because I have written it and although in theory generalized enough so as to be reused in third-party applications, my advantage is that as soon as I need an extension, I'll write it; as soon as I encounter a bug, I'll fix it. I know how developers tick: I wouldn't even try to convince them of my architecture by means of mere marketing. Notice the subtlety: they may well be fascinated enough by my upcoming products (or maybe not, who knows?) to enquire what kind of "component library" I have used, and if that occurs I might well wrap AuthorBase up and start selling licenses. But they would have to convince themselves by virtue of seeing and using a live application or two. I would have a hard time pitching something like AuthorBase out of the blue. The products, and for this kind of framework they would have to be very real products (not some kind of Notepad clone), need to be out there first (if only for quality assurance purposes, let alone the fact that these represent very real, time-consuming projects that hopefully will deliver a lot of value to as many individuals and teams as possible)—no amount of marketing lingo will sell developers or program managers a prefabricated application design scaffolding; however, a couple of successful live showcases might well do the trick.

Takeaway: no productization plans for AuthorBase at all, no time investment into it other than what is required by my current product development; but I'm aware that such an opportunity might well present itself, and I will probably not let it pass if that happens.

[1] As an indication that this risk perception exists quite in the way I describe, consider the fact that while generalized application frameworks, which suggest their own, unknown and unproven design philosophy to developers (such as Framework Studio) have a hard time gaining mainstream acceptance, there are other packages that prove extremely successful and serve the same purpose—to save time reusing attractive off-the-shelf design decisions (though mainly only as far as the GUI is concerned). The difference is that those are proven, widely distributed and thus standardized and consistent: witness the ubiquitous Microsoft look-and-feel clones. The risk element I talked about is simply taken care of here. If you want to sell your ready-made application design approach to developers,  it is that fear that you'll need to address and overcome.

A Micro-ISV diversion

While I continue developing my other major software product I have after a few hours of pondering decided to start developing another one concurrently. This one will be purely open-book development: I will blog about the whole process, gather feedback and ideas from others all the time, and hope to attract a small number of people interested in the tool and test-driving it for their own needs.

I want to develop the ultimate localization tool for .NET software developers and the translators they work with.

That's right. Am I serious? you wonder. I am. There are a few buts I'm ready to address right now, however I'm soo looking forward to hearing more: yours (before it's too late)!

But there are already existing mature packages on the market!

Yes, and they serve everyone and their dog, supporting .NET among 20 other technologies. Consequently, these products are priced between $ 500 and $ 5000 per seat, whether you need the full-blown suite including Delphi and Java and MFC support—or not.

But the .NET Framework and all IDEs already support us with basic localization tools!

While the .NET Framework comes with the basic technological foundation for localizing an application easily (namely the RESX file formats and editors readily integrated in the major .NET IDEs), there are a few points that I think are worth addressing:

• Ever localized forms or controls using the Visual Studio .NET designers? It is a messy process, particularly when you change sizes or other properties for controls in another language, intending to apply your change across all cultures, later realization you were accidentally working within a certain culture. Change your forms or controls substantially, delete or add controls, after already having localized parts of it and everything becomes a nightmare. It happened to me repeatedly that the designer fails to display the control and/or form again, or lost track of some binary property values (such as images) that just got lost in the ether. Attach a couple of cultures to a form or control and the designer gets slower, too. There has to be a better way.
• Ever localized forms or controls using the WinRes tool? (This is what you give translators who do not have Visual Studio and/or who you don't want to entrust with your entire projects with all other files etc.) The point is that this is only a very basic resource editor but it does not support the process as a whole. A translator might simply forget to check whether there are sub-menus in sub-menus of an item on a ToolStrip. Or think of localizable properties of items that are not directly clickable on a designer surface, such as ListViewItems.

I think that, just as documentation, localization should be somewhat separated from development, whether the person doing the stuff is the same as the developer or not. The whole "integrated" part of integrated development environments is a bit overdone, I think. It results in hacky tools that are fine for three-line demo applications but fail to provide streamlined support for the actual process and its many requirements. I don't want localization to interfere with my development, whether by having to switch between coding mode and translation mode or by having the inadequate, "resource"-centred rather than really localization-centred integrated tools destroy my forms/controls etc.

But the developer market is unthankful and you will have to face the not-invented-here syndrome!

One is typically advised against the market for developer tools along these lines, but I do not really buy into it. Sure, selling to developers may be tough, but selling to any particular market or segment has its own intricacies, I believe. Selling to consumers must be tough! Developers are used to, and keen on, trying new tools and interested in improving their processes using software. You do not have to first sell them on the idea that software can improve and streamline their work, something that many other industries still have to do. There is no, or much less of a chasm to cross.

Any more Buts?

So these are the three most obvious issues I have considered, apart from keeping at bay the burning vision of a fantastic product that I have in mind. It may soon take over, but first I'd like to hear your take on this.

Micro-ISV "opportunities": pick one for life

I have waited for this one: The new Google AdWords Editor desktop application (via Dennis Gurock). I used to dislike the web user interface so much that I'd rather not go in there to check stats or optimize ads at all! Such a "mission-critical" tool (for Google just as crucial as for their advertisers) certainly should provide an enjoyable experience (in software, if a tool performs according to expectations and behaves responsively, that already counts as an enjoyable experience). The web interface, while doing its core job satisfactorily, in my opinion didn't really deliver that.

Dennis Gurock writes:

It would be nice if MSN had a similar tool. It would be even better if you could synchronize ads and keywords between MSN and Google. Or if you had a single desktop application to manage all the different systems – complete with reports and statistics. Is this a Micro-ISV opportunity?

Sounds like a good one. I believe there are a few distinctive common patterns that lead to a Micro-ISV opportunity. If I have missed some, let me know:

• Pet project productization. A software developer identifies a software idea and thinking, "This could be fun!", starts a personal pet project around the idea. Later on s/he realizes that by "just putting in a day or two more", this could become a viable, marketable product. Still later, the one day or more turn out to be one month or more additional (mostly non-programming) work: polishing and furnishing, additional features to attract customers (that weren't required by the creator of the project initially), website creation, setting up payment processing, creating separate limited trial versions, including some kind of licence protection mechanism, you name it. This was the approach taken for my (mildly) "successful" first product, SuDoku Pro, and for my (rather) "failed" second product, Quotator.
• Consulting project productization. Producing custom software tailored to suit the requirements of consulting clients can lead to the realization of a product opportunity, once certain commonalities and overlapping feature needs are identified. Most products targeted at businesses, organizations and enterprises have probably evolved this way, as well as some authoring and developer tools, I assume, although the "personal pet factor" could well be higher here.  For the sake of simplicity, wether the work started out as a consulting project for a client or as an in-house project for an employer does not matter here; I think the commonalities are sufficient to afford a single category.
  
• Fix and improve. Working with some product or service, a slowly evolving and often repeating feeling along the lines of "how annoying, I could do this better, especially part X I would do completely differently" may yield a new Micro-ISV taking a new competing product or service to market. This can range from extreme cases (duplicating the entire product or service and including a few fixes) to extending (original product or service was too narrow) or narrowing (original product or service was too niche). Hint: try to avoid producing that feeling in your customers and you may avoid some future competition. ;)
• Deliberately seeking out a product idea. Some people are so fascinated by the Micro-ISV "career path" that they decide to pursue it first, then go looking for product ideas, sometimes even in an industry they have yet to learn about.

If you are serious about starting a Micro-ISV, what I would like to pass along as advice is a question I want you to ask yourself: would you mind spending the next one or two decades, or even the rest of your life, working on your solution / product / service?

Hell, no way!, I hear you answer and rightly so: who wants to spend the majority of the rest of their lives with just one activity, any activity? After all, part of what makes life exciting are new opportunities, changing interests, evolving opportunities and having fun along the way. Change is a fact of life, one that feels sometimes inconvenient, but nonetheless one that is a major reason for most of the actions and choices we make.

Now, what matters is not whether you would actually enjoy doing what you set out to do for the rest of your life, but your comfortability with the imaginative prospect. It can be helpful assessing whether, how well and how patiently (and consequently: how successfully) you will:

• go the extra mile that will be required before any milestone, no matter how small
• deal with challenges such as unsatisfied customers or customers failing to materialize, competitors, copy-cats, pirates and freeloaders
• continue to nurture and evolve your product, gearing it ever closer towards the needs of your customers
• and more or less enjoy the process

So here is my advice, maybe somewhat radical in Micro-ISV terms: when assessing potential areas of business to pursue, pick the one you would do for life. I'm not suggesting you should then go ahead and do it for fourty years to come, even ignoring the fact that such an opportunity seems unlikely. I'm merely saying that this will affect the outcome. Pick the one where you want to become a leading player. I'm not saying this is going to happen, or this should be your only goal and yardstick with which to measure whether you "succeeded" or "failed". I'm merely suggesting that this a good indicator for how enthusiastic you really are about the opportunity, deep down, and that this, again, will affect the outcome of your pursuit.

Case in point: SuDoku Pro. I never had any intention of entering the casual games software industry. While there were few competitors when I launched, this quickly changed within two to three months, given the many players in that market. Once launched, I was always quite hesitant to keep working on that product. I have done so for quite a while, up to a fairly mature point when I "freezed" the product. I'm now merely taking orders, issuing license keys and answering the odd support request. No marketing, no new versions (apart from the odd hotfix). Business has declined as a consequence that was predictable and that I have put up with, being the cost of developing my forthcoming product. It has more than paid for the up-front time investment, which is good. But had I asked the above questions beforehand, I wouldn't have done it, or rather I would not do something where the answer is "no" again. My main objective was to build, not a piece of software but a product, market it and sell it, and by that measure my experiment was successful indeed. (So maybe one "non-ultimate" project to get started with is OK for Micro-ISVs after all. ;)

However, you can quickly get lost in such projects and waste your energy and resources that would be better spent (better meaning more enjoyably and more lucratively) on "ultimate" projects: such where the answer to the above questions would be "yes".

My upcoming product is a lot more closer on the "ultimacy" scale, and it will have to be, for I have decided to go Micro-ISV for real.

Time flies like an arrow!

Would you believe it's August 13 already?

(Waiting period while you head off to less discouraging web content elsewhere.)

I have started working on my upcoming product in May and my schedule now is for a first public beta in mid-September. I will launch probably around the end of September. There will inevitably be unforeseen delays, and version 1.0 will be far less feature-complete than the "real, final product" vision I have mind—I hope it won't take me 10 years to get there—however, there is a neat deadline-of-sorts looming: the Larkware Daily Grind issue #1000 in late October, which I would love to sponsor by giving away a couple of licenses to my product.

I'm eager to tell, you're eager to hear...

but, alas, I cannot quite go into the details of this product at this stage. I'd love to!, seriously, I can't wait for the day when I can launch the public beta test and start blogging extensively about the project and associated topics. There is a cue as to the target market in this posting, but I can't afford to talk about it more. There are in fact a few existing competitors out there, and some of my ideas will address the shortcomings I see with their products as they exist to date, as well as the way they serve their market.

If my assessment is correct, I might well attract some of their potential customers (hopefully!), and naturally they will be quick enough to adapt their products where they see fit to address demand they have so far chosen not to service. By then it will be back to "equilibrium competition" (kind of) but I obviously don't want to give away that early and predictably short advantage, especially given that it will only balance the fact that I'm coming to market less feature-complete and probably initially a little buggier than those established players.

Don't get me wrong, I don't worry about competitors so much as I do about potential customers, but why grant them such a chance? I would love to do the whole web transparency thing, blogging about every aspect of the product and its development early on, getting early feedback and so on. But I will have to wait until the beta.

Fruit flies like a banana, but you knew that already.

I'm working for the best boss in the world!

Myself!

Starting up is difficult to grasp for some people, for example my parents. They seem to think, from the empirical evidence and what they see me doing and (so far) achieving: "so, being self-employed must basically mean to live on a level of bare subsistence in terms of earnings while refusing state benefits (but accepting the occasional parental financial support) and working through most of the waking hours instead of a nice comfy eight-hour day, three or four nice comfy weeks of holiday a year, in a nice comfy office, with a nice comfy car and the conveniences only a proper day job can offer."

I haven't quite managed to explain effectively to them what this is all about. Now I have finally found a good explanation of why software entrepreneurs work the way they work, by a guy just nick-named a guy over at The Business of Software:

If you are a programmer, then you work for pay.  If you are a business owner, you work for equity.  It's always the assumption that the business owner adds more value, and the programmer is a commodity to just build out the great idea of the business person.  But that is not really the case.  It takes a lot of money to build a product, 100's of thousands usually.

That is why we programmers can make microISV's.  We have the ability to build the product ourselves, saving those 100's of thousands in money, and instead investing sweat equity.  Then we teach ourselves marketing and sales.

 

Well said!

Non-modal user interface

The user interface of the new product that I am currently working on will be almost completely non-modal. This is of course only a minor feature, a goodie, rather than its unique value proposition.  ;)

In fact, this has evolved by accident rather than by design. In the process of designing the software (an activity that is not separate from development in my case) quite a few instances already occurred, and continue to occur, where by conventional wisdom I would just pop up a message box, a confirmation dialog, or design a small dialog window for details of the current user task.

Message boxes and dialogs break the user flow and take away the system focus (annoying when you scroll through a list or type text), and so I (and many users) despise them.

Are you sure you want to...?

For confirmations where I really want the user to think twice (very rare, I usually tend to trust the user's decision if he already took the trouble to click a button...), drop-down menus very nicely replace yes/no confirmation message boxes:

Information bars

I implemented flashing information bars (as can be found in the current generation of Internet Explorer and Mozilla Firefox web browsers) which pop up at the bottom of the application window for a couple of other events that would typically produce a message box or dialog:

Wizards

More complex dialogs (such as Options) and wizards are completely integrated into the document window management of the application and are thus non-modal, too:

Standard dialogs

I have no plans to waste time replacing standard dialogs such as Open File, Save File, Print, Page Setup or Print Preview at this point. There would be a very real risk that usability might suffer unduly (people already know how to operate these dialogs) and my intention is not to be religious about non-modal user interfaces, but to avoid breaking the user flow or stealing the focus. The product is meant as a productivity booster for a certain type of task, it is targeting power users, so the main purpose of these experiments is for the software to get out of the way.

Philosophy of Liberty

...laid out and explained in a brilliantly simple fashion; thus demonstrable to and comprehensive for just about everyone... Caution: I wouldn't have chosen such a dramatic soundtrack, nonetheless a very nice piece of work.

Innate Talents

Aaron Swartz' Non-Programmer's Apology has touched an issue that I have been pondering about for a long time:

[...] that statement [...] only makes sense [...] if you believe that abilities are somehow granted innately and can merely be cultivated, not created in themselves. This is a fairly common view, although rarely consciously articulated (as indeed Hardy takes it for granted), but not one that I subscribe to.

I have always taken issue with the idea of unearned privilegues (even as a child I was uncomfortable with the notion that I would have a "special talent for music and languages" as I was told, when all I did was listen to music, sing and read lots instead of playing outside as the other kids did; I concluded for a while that "talent" was a moniker for "special interest"), and an innate talent surely would be just that. What would be the point of celebrating the best sports-people, musicians, composers, writers, painters or the business-people of best productive ability, and of rewarding the "best", if "success" does not stand for individual achievement but for inherited genes. Shouldn't we reward their parents instead, no wait, better yet, their grandparents, no, their grandparents' grandparents' grandparents?

It is obvious that some are born with weak knees while others are not (and indeed this is sometimes due to inheritance of certain strengths and weaknesses, rather than an unfortunate incident at birth), so because of that some may have a lower probability of succeeding at running than others. Why shouldn't it be the same with certain regions of the brain? Again, indeed, this was shown to be the case (forgive my lack of references and general sloppiness, but hey, I'm just blogging, not essaying, and I'm mainly a software developer and entrepreneur, not a sociologist, biologist, psychologist or philosopher).

However, this alone does not constitute innate talents, only starting conditions.

Paul Graham has discussed the issue of innate talents refreshingly in How to Do What You Love:

Of course, figuring out what you like to work on doesn't mean you get to work on it. That's a separate question. And if you're ambitious you have to keep them separate: you have to make a conscious effort to keep your ideas about what you want from being contaminated by what seems possible.

It's painful to keep them apart, because it's painful to observe the gap between them. So most people pre-emptively lower their expectations. For example, if you asked random people on the street if they'd like to be able to draw like Leonardo, you'd find most would say something like "Oh, I can't draw." This is more a statement of intention than fact; it means, I'm not going to try. Because the fact is, if you took a random person off the street and somehow got them to work as hard as they possibly could at drawing for the next twenty years, they'd get surprisingly far. But it would require a great moral effort; it would mean staring failure in the eye every day for years. And so to protect themselves people say "I can't."

I was always planning to research deeper into the issue of innate talents. One of the top-most results on Google revealed a paper titled Innate Talents: Reality or Myth? with the following promising abstract:

Talents that selectively facilitate the acquisition of high levels of skill are said to be present in some children but not others. The evidence for this includes biological correlates of specific abilities, certain rare abilities in autistic savants, and the seemingly spontaneous emergence of exceptional abilities in young children, but there is also contrary evidence indicating an absence of early precursors for high skill levels in young people. An analysis of positive and negative evidence and arguments suggests that differences in early experiences, preferences, opportunities, habits, training and practice are the real determinants of excellence.

Once I have accumulated some of that precious resource, time, I will work through it, as well as look further for discussion and criticism about it. Following academic discourse, unfortunately, is not something that can be done easily or quickly.

If you are wondering why this post is filed in the "Economics" and "Politics" categories, just consider the implications of the two conflicting propositions for the various brances of the social engineering industry (also called politics)... Of course, should it be found that nature is "inherently unjust" by dispensing unearned privilegues (innate talent), then people will find that the world must be "put to rights", society remade and equality of opportunity must be restored, by counter-balancing natural unearned privilegues with artificial ones. If that was the case, I might even find to agree at least with their conclusion, although probably not their approaches (more goals can be attained uncoercively than one would initially believe, and I do and will continue to maintain that a goal that can only be attained by coercion is not worth pursuing).

I'm prepared to accept as fact what can be logically and convincingly shown as fact (i.e. whatever we find to be the laws of "nature", or more concisely, reality), although I'm not yet sure about what conclusions to draw from either proposition and to what extent. Some thinking left to be done here...

An ancient conflict

Over at his new blog, as well as here, Ian Leitch asks:

There must be many, many developers out there working on software that will replace the job of a human being; how do they feel about it?

Fortunately, the economic effects of technological advances can make you feel good about it. Unemployment has a variety of causes (notably statist interventions) but a new machine (or software) that can perform automatically a job previously done manually does not necessarily reduce the demand for labour (which derives from the intention to produce for consumption, and there is no limit to how much people want to consume), it merely increases the output, the product, of human labour ("productivity") and this is in fact where "growth" (rising nominal wages that are inextricably linked to productivity) happens.

Ian continues:

I am firm believer in survival-of-the-fittest and I'm not about to give up my own job so someone can keep theirs, but at the same time I still have a sense of morality.

Quoting Francisco d'Anconia: Contradictions do not exist—check your premises, you will find at least one of them to be wrong.

Whoever claims that economic competition represents 'survival of the fittest' in the sense of the law of the jungle, provides the clearest possible evidence of his lack of knowledge of economics. The truth is that economic competition is the very opposite of competition in the animal kingdom. It is not a competition in the grabbing off of scarce nature-given supplies, as it is in the animal kingdom. Rather, it is a competition in the positive creation of new and additional wealth.
~ George Reisman

The morality of capitalism is based on volitional trade of value for value, voluntary exchange. The labourer your software might be replacing has no claim on what you choose to do, as long as you do not violate his right to his own life and property. Such a claim would violate your own rights. You are acting morally because of this, but also because the demand for the labourer does not actually, necessarily disappear, speaking economically, as I have outlined above. The best description of this process I have read so far has been written in 1848 in French by Frédéric Bastiat in his wonderful essay series What Is Seen and What Is Not Seen:

James Goodfellow had two francs that he let two workers earn.

But now suppose that he devises an arrangement of ropes and weights that will shorten the work by half.

Then he obtains the same satisfaction, saves a franc, and discharges a worker.

He discharges a worker: that is what is seen.

Seeing only this, people say: "See how misery follows civilization! See how freedom is fatal to equality! The human mind has made a conquest, and immediately another worker has forever fallen into the abyss of poverty. Perhaps James Goodfellow can still continue to have both men work for him, but he cannot give them more than ten sous each, for they will compete with one another and will offer their services at a lower rate. This is how the rich get richer and the poor become poorer. We must remake society."

A fine conclusion, and one worthy of the initial premise!

Fortunately, both premise and conclusion are false, because behind the half of the phenomenon that is seen is the other half that is not seen.

The franc saved by James Goodfellow and the necessary effects of this saving are not seen.

Since, as a result of his own invention, James Goodfellow no longer spends more than one franc for manual labor in the pursuit of a given satisfaction, he has another franc left over.

If, then, there is somewhere an idle worker who offers his labor on the market, there is also somewhere a capitalist who offers his idle franc. These two elements meet and combine.

And it is clear as day that between the supply of and the demand for labor, between the supply of and the demand for wages, the relationship has in no way changed.

The invention and the worker, paid with the first franc, now do the work previously accomplished by two workers.

The second worker, paid with the second franc, performs some new work.

What has then been changed in the world? There is one national satisfaction the more; in other words, the invention is a gratuitous conquest, a gratuitous profit for mankind.

From the form in which I have given my demonstration we could draw this conclusion:

"It is the capitalist who derives all the benefits flowing from the invention of machines. The laboring class, even though it suffers from them only temporarily, never profits from them, since, according to what you yourself say, they reallocate a portion of the nation's industry without diminishing it, it is true, but also without increasing it."

It is not within the province of this essay to answer all objections. Its only object is to combat an ignorant prejudice, very dangerous and extremely widespread. I wished to prove that a new machine, in making a certain number of workers available for jobs, necessarily makes available at the same time the money that pays them. These workers and this money get together eventually to produce something that was impossible to produce before the invention; from which it follows that the final result of the invention is an increase in satisfactions with the same amount of labor.

Who reaps this excess of satisfactions?

Yes, at first it is the capitalist, the inventor, the first one who uses the machine successfully, and this is the reward for his genius and daring. In this case, as we have just seen, he realizes a saving on the costs of production, which, no matter how it is spent (and it always is), gives employment to just as many hands as the machine has made idle.

But soon competition forces him to lower his selling price by the amount of this saving itself.

And then it is no longer the inventor who reaps the benefits of the invention; it is the buyer of the product, the consumer, the public, including the workers—in a word, it is mankind.

And what is not seen is that the saving, thus procured for all the consumers, forms a fund from which wages can be drawn, replacing what the machine has drained off.

Thus (taking up again the foregoing example), James Goodfellow obtains a product by spending two francs for wages.

Thanks to his invention, the manual labor now costs him only one franc.

As long as he sells the product at the same price, there is one worker the fewer employed in making this special product: that is what is seen; but there is one worker the more employed by the franc James Goodfellow has saved: that is what is not seen.

When, in the natural course of events, James Goodfellow is reduced to lowering by one franc the price of the product, he no longer realizes a saving; then he no longer releases a franc for national employment in new production. But whoever acquires it, i.e., mankind, takes his place. Whoever buys the product pays one franc less, saves a franc, and necessarily hands over this saving to the fund for wages; this is again what is not seen.