2006-12-15

Software is

Software is an encoding medium for ideas. Nothing more and nothing less. That is profound enough by itself. The idea of thoughts existing in an active manner independently from the skull of the thinker is revolutionary enough. What software is, is a fundamental immutable truth: someone must think a thought and encode it.

Ideologies decide whether this means that an idea is property the way a house or car is property or whether ideas cannot be owned. These ideological frameworks allow for commerce around software to operate, make money, and allow people to build careers. It is in the arena of ideology that OpenSource and Proprietary models combat.

This is a simple but important distinction. Software is thought. That is always true. It has all the properties of written thought and some of the properties of active thought. The idea that this form of thought can be bought and sold is part of an ideology. The idea that nobody can own thought is an idea that forms part of another ideology.

No matter what you believe on the subject of intellectual property it is still true that software is a form of expressed thought. That means that how we treat software at least in part informs how we treat expressions of thought and how we treat expressions of thought informs how we treat software. This is not something that I see reflected in modern legislation on the subject of property rights.

2006-12-14

Database Design

Let's say I want a screen that displays a list of MP3s with Genre, Artist, Album, Song Name, Play Length. What would the database table for this look like? Many neophytes would design a table that looked like:

MP3Files
Column
Typedefault
MP3ID
int
auto increment
Genre
varchar(255)NULL
Artist
varchar(255)NULL
Album
varchar(255)
NULL
Song Name
varchar(255)
NULL
Play Length
varchar(255)NULL

... and amazingly never see the problem with this.

2006-12-04

Full Body User Interface

One of my graduate school professors runs the Body Language User Interface project called BLUI for short. It is a unique Human Computer Interaction (HCI) project that allows a user to paint in three dimensions. Projects like BLUI probably inspired the current generation of console controllers on products like the PlayStation3 and the Wii.

The prolonged sedentary use of computers is simply unhealthy. Human bodies were not designed to sit immobile in front of a screen for hours on end. Physical exercise may be important for mental health in general and is completely absent from conventional human-computer interactions.

The computer is arguably the most profound advance of human technology since the advent of the written word. Many of us today live computer-life-styles that would be impossible without these devices. Yet they are slowly killing us.

Wii users are now talking about soreness and fatigue from extended use of the Wii-mote. Repetitive-motion injuries are obviously a concern with any UI and the Wii offers the opportunity for you to experience tennis-elbow caused by a video game. These are just the hazards of owning a body and playing a sport.

And, now we can start to call some video games sports. Perhaps Electronic Sports are on the horizon? All the better. It means that our computers are going to stop being shackles that tie us to the desktop.

Some distant future may even give us a Full Body Interface (FuBI) where the users will dance to communicate with their machines. Dances that control fighter jets. Dances that control robot probes on the surface of Mars. Dances that communicate how to conduct the surgical removal of a tumor.

It's just an idea.

2006-11-30

Bi-Tek

Johnston County in North Carolina has gotten a temporary court order to get Google to remove a page from cache. The page contained the personal information of county residents including social security numbers and cell phone numbers. The news has focused the fact that Google did not respond instantaneously causing Johnston County to seek a court order from an NC judge and not the fact that one of the county's contractors was negligent in its handling of sensitive data.

While it is disturbing that Google doesn't respond faster to requests to clear Personally Identifiable Information from its cache... Johnston county did leave the information languishing on the Internet for six weeks. And, how did this information make it to the web anyhow?

The News and Observer Article states that Bi-Tek creates a file that is posted to the Johnston county website and this file is supposed to contain only names, addresses, and non-private account numbers. Bi-Tek made a mistake that instead posted private data to the Internet.

Earlier this year the VA had its own incident where it potentially exposed the personal information of millions of veterans. Proving that large and small organisations alike have to fight employee ignorance, malice, and indifference regarding sensitive data. The questions that the press should really be asking might be:
  1. What is going to happen to Bi-Tek for this mistake?
  2. What are they going to do at Johnston County to make sure this never happens again?
  3. Will Google be motivated to create a special "Oops! I posted my credit card number on a bulletin board!" call center?
  4. Should software companies that handle sensitive banking, tax, and accounting data have to be certified? And, would an incident like this revoke the license of such a company? Should they ever get it back?
If you pay taxes in Johnston County, North Carolina you should be concerned about the security of your tax information and you should be asking questions about Bi-Tek, Johnston County's website, and what they are doing to safe guard your personal information that they have stewardship over.

2006-11-15

Direct Web Remoting

DWR (Direct Web Remoting) is yet another Ajax framework. This one is, however, a Java framework that makes a heck of a lot of sense for java developers. Take a POJO. Register it in the dwr.xml file under WEB-INF in your war... and now you have an object you can call from your webpages.

Yeah. I didn't believe it either. But the 2.0 beta of DWR that I have been working with is really just about that easy. DWR generates the javascript which you just include in a page, then it generates the servlet that the javascript calls. DWR turns a POJO into an Ajax servlet.

See how easy it is to get started with DWR and if I get enough feed back I'll post some code samples of how to do a portlet that has can process actions using that POJO you registered with DWR. Now with some very simple (but smart) scripting you get Ajax features that automatically degrade to universally supported portlet actions.

And that is why DWR is head and shoulders over some very wrong-headed attempts to turn Ajax web development into Swing or pseudo-swing development. The web is the web. Features should degrade gracefully and page designers and artists should be able to work with programmers to create web applications that work well, look nice, and degrade gracefully.

see also: my DWR tag roll on del.icio.us

2006-11-03

Open Source the Inevitable

Anyone who didn't see open source coming was just kidding themselves about what software is fundamentally. Software is speech. Software is the embodiment of ideas. Once an idea is born it spreads.

Patent law used to recognize this truth. After all, an invention is an idea given substance. The limited monopoly power granted by a patent is intended to fade in time. And, after a time the idea behind an invention becomes part of the greater matrix of ideas that create the culture and community of inventors.

Eventually, enough time will pass that the novelty of every software "invention" will fade and the ideas that drive those inventions will become part of the greater fabric of the community of software creators. Open source is one method of speeding up this process. By forcing software to expose its inner working you forcibly populate the world with the thoughts and ideas that were used to create the software.

Closed source software spreads its thoughts and ideas much more slowly. So much more slowly that the thoughts and ideas the pervade the open source community will eventually over power the closed source community's ideas. In this way open source is guaranteed victory over closed mind-sets... But, not necessarily economic victory.

In the arena of "hearts and minds" victory by open source is not revolutionary, it is evolutionary. Victory for open source in this arena is not the destruction of a particular company, it is the change of the company. Open source is just a label for a small part of a grander change coming for humanity.

The expression ideas is slowly becoming divorced from the physical world. In time the only thing that will have value are thoughts and ideas. Ideas have no value or power until they are shared. Open source is about sharing thoughts and ideas. And, our future is more about the power of thoughts and ideas than it is about control of resources.

2006-10-18

Requirements

I usually ask candidates for Software Engineer positions the following questions about their project work:

How do you know when you are done?
How do you know when you have succeeded?

2006-10-16

Server as a Text Pump

So a server gets requests from the network and these come as text. A server gives a response and these are formulated as text. The text is formatted to give it a structure. And, if you use the right formats you get to call your server an XML-RPC server, or a SOAP server, or flavor of the week. Isn't all this just the Unix Philosophy taken to the web and hammered on with an XML hammer?

And, this is the point where I start wondering why the heck so many freakin'' book get written about this. SOA should be the easiest thing in the world. Unix programs have been parsing and spewing forth text for ever why does it suddenly become so much more difficult once you put objects into the mix?

It's the frameworks. Many of these XML frameworks don't make life simpler, they make it more complex. If you're trying to do SOAP or any XML-RPC work in a Java Application Server I encourage you to look at JBoss' EJB3 product. It looks to me like EJB3 in general will save a lot of grief for SOAP-y programmers and the JBossWS API is the first implementation of this that I've found usable.

When I tried some of the WebService tricks on the Sun Application server that comes with NetBeans I sprained a nerve cluster. When I tried the same on Glassfish I lost a lobe. With JBossWS I was so shocked at how easily my EJB3 service went together I couldn't believe it. I've made EJB3 + JBossWS my default development stack for Web Services.

2006-10-11

No job shortage here?

We've been interviewing candidates for an open Software Engineering position for the last year. It averages about one interview a month and so far we can't find qualified candidates. Some of the more frustrating candidates interview well but when you get to technical questions you can't get the feeling that they themselves are comfortable with the technical subject matter. At least once someone passed technical, got hired, and had to be "let go" because it soon became apparent that they had "studied" for the interview but had no practical experience... And had lied on their resume.

I'm really puzzled by the fresh faced BSCS who has never taken data structures. I asked him which university he attended and I have to say that if this is the quality of education at that name-brand university I'll take my employer's business elsewhere. I would expect that BSCS students would either learn theory or learn practical skills to an appreciable degree.

Where are all the qualified candidates that were complaining about jobs going to India? Could you tell me where they are? I can't find them.

2006-09-25

Bit Plumber

It seems that most of my life is spent either waiting for, calling new, or building data transfers. I spend my Monday morning reviewing logs from the previous weekend's data transfers, I start a refresh of my development environment's database, and I work through last week's progress on the web services I created. This weeks project is to design a custom export of data from one database to an XML format and back into a different database. So much of this is repetitive and so much of it is the same from week to week I have to wonder if there isn't a group of tools to automate these tasks.

Let me introduce you to the wonderful world of ETL tools. These are tools that Extract, Transform, and Load data. In short they have the potential to replace an entire stack of SOA tools that currently are written painstakingly entity by entity by your talented Web Service programmers. They do all their by work by pragmatically by-passing the entire ORM process (that then demands you to Serialize the Objects to get XML) and skip directly to the XML.

I expect to see more applications built around these ideas as SOA catches on more. Why can't an ETL be used to generate Ajax messages or SOAP calls? After all aren't many SOAP calls and Ajax calls just loading up data from a database and transforming it into the right message format?

2006-09-06

Velocity versus JSP

I've spent the last few weeks in a new larval stage again. This time I've the been studying the alphabet soup that surrounds web portlets and the JSR168 spec. I'm not talking about learning to make portlets... that's easy... I'm talking about the best way to make portlets.

The fastest way to get working with portlets is to start by creating JSP pages and balling them up into portlets. You end up with function fast. But, if you plan on doing that, why not just go with a PHP based site? About all that JSP will get you in this case would be some props at cocktail parties where you can get an easy 'wow' by tossing around the word Java a few times.

We want MVC and we want to enforce it. So I've decided on velocity for page design. With velocity I can give page designers the ability to work with active page content and remove the possibility that some slack-jaw might muck up my code-base by slapping in some ill concieved SQL. It also means that view policy is utterly divorced from controller mechanisms.

2006-08-17

Programs that write programs

A new generation of software has begun to emerge. These are tools that take UML diagrams and transform them into code. Humans have been creating software now for nearly a generation. This wisdom has begun to distill itself into "Design Patterns" and into a higher order of meta-thinking about systems design.

The idea behind UML to Code tools is simple enough and the progression follows a path something like this:

In the bad old days you had to toggle in programs one bit at a time. Then there were switch boards allowing bytes at a time to be toggled in. Programming involved all sorts of unrelated skills such as knowing how to toggle in code from 3x5 cards. There were no languages beyond binary.

Later the binary got covered over in a veneer of language that could be assembled into binary. Life was better. When higher order languages were introduced that could translate formulas into assembler and then binary there was some resistance. Surely, there was no way that these compilers could produce binary that was as good as the binary created by a talented human programmer? In time this argument was forgotten and the age of Programming Languages dawned on the planet.

After thrashing around for a while on how to best represent programmer thought in programmer language some defacto paradigms started to evolve as the ways that various classifications of human minds work began to be understood. In time we began to see common problem solving patterns. These patterns eventually began to see formalized expression in an implementation independent way.

Just as assembler was more expressive than binary, the programming language more expressive than assembler, wouldn't this meta formalization be even more expressive? And, shouldn't it be possible, once they were formalized, to transform these diagrams into programming language representations that would find their way all the way down to binary?

This is the early dawning of that next phase of software developments evolution. We have had some faltering starts at it. Several commercial products have tried to add a "visual" component to their development tools but these miss the power of the meta-language called UML. Just as it took time for the first compilers to get "good enough" to over come the argument that no "code generator" could do as well as a human programmer, these tools face that problem too.

In time they hold great promise of freeing the programmer from unnecessary minutiae allowing them to build bigger bolder castles in the air.

2006-08-14

Things you never want to hear...

... your doctor say:

What the heck is that?

I didn't even know that was possible.

oops.

Oh well.

I'm thinking Arby's!

2006-08-08

Castles in the Air

If the poet creates castles in the air then the programmer creates castles in the air made of air. The programmer works in a rarefied space where the interplay of thought and language are the only limitations.

2006-07-27

Too Abstract

Most days I get the feeling that nobody understands what I'm talking about.

This is the problem with being too abstract. Many people have difficulty with abstract models of behavior and being a person that spends nearly all my time working with abstract models I sometimes find myself in the position of speaking Greek to a Latin audience. The Greek is appreciated by the Latins but not really all that well understood.

When we as programmers communicate software designs or the impact of new technologies we often will get those blank stares. The way to help mitigate those blank stares is to use concrete stories. Stories with people's names that contain actions that people really need to perform. If you can say: "Now when Joe wants to check his mail he can do so from anywhere that has an internet connection." instead of "This is a web enabled mail client." That's more words but easier for lay-users to understand.

For example instead of "This Ajax mail client will allow our end users to use mash-ups of corporate data in email." you could say, "Now when you check your mail and hover over an order number with your mouse a little bubble will show the order details. You can click in the bubble to get other data on that order." The second example is wordy but hopefully easier to get people's minds around.

When we teach sales people we teach them to put emphasis on benefits not features. In our example the "Ajax Mash-up" is a feature but the "hover over an Order number for quicker access to details" is a benefit. Sometimes our jobs as technologists are more about sales than about technology. Instead of booking orders we are trying to buy mind-share for our thoughts and ideas.

Model Driven Architecture

When building software a software engineer or other system design expert creates a shared mental model of the problem space. Boxes and stick-figures or intricate flow diagrams detailing the space to be explored find their way into documentation. Descriptions made for implementation people to work out finer details.

What if the documentation was the software?

In theory the process of creating software is all design. Design progresses from large sketches to finer and finer detail. The finest of details yielding code that is finally compiled into machine language. Each refinement is fueled by human effort. Each finer detail of documentation yielding an artifact that exists merely to be consumed by the next stage in the chain.

Model Driven Architecture is an attempt to skip many of these steps and skip as closely as possible to the code that is ready to be transformed. UML diagrams drive a series of transformation engines to "compile" drawings into code. The resultant code may or may not be ready for use but it is a many great steps down the chain to complete. All of this hinging on the pretext that the programmer builds a mental model that is then transformed into code.

2006-07-20

Who can program?

A there is a paper written at the School of Computing at Middlesex University in the UK that addresses the issue of programming aptitude. The authors of this paper (Dehnadi and Bornat) have devised a test that they claim can separate out who may learn to program well and who will not. This fits well with my earlier observation that: "Anyone can program, only some people will learn to program well."

The working title "The camel has two humps" refers to a phenomenon that even I have noticed when teaching programming. One group will do well, and the other will do poorly, each group will have their own bell producing a two humped grade curve. The break through for this paper is creating a test that separates out who is part of which group. You can then reliably plot two independent bell curves based on results.

The differentiating factor between our two populations of programmers? Mental models.

The tests devised by Dehnadi and Bornat determine who is creating mental models and using them. It turns out that it is not nearly so important that the student use a correct mental model as that they know how to create and use a mental model at all. So I have to ask, how does one learn to use mental models? Why do some people use them well and others do not?

2006-07-18

What makes a good programmer?

Anyone can program, but, only some people will learn to program well. Some people learn to program well very quickly. These fast learners find ways to work with the concepts that build the systems of thought that software is. What causes one person to "get it" and another to "miss it" entirely?

There is an art to programming. You've got to keep it DRY, you've got to be terse but not too terse, you've got to be lazy in the right way. Some people get it in a short time while others never seem to understand programming. What magic formula of personality, intelligence, and determination makes the difference between those who learn to program and those who learn to program well?

What makes good software? What makes a good programmer?

I contend that Software is the encoding of thought and if I stick to my resolution then I must also contend with the implication that good software constitutes thought that is also "good" in some way. The idea of a "good" programmer therefore is anchored in the idea of "good" thought and that means that a "good" programmer must also be a "good" thinker and a "good" communicator.

Whatever "good" in this context means. Albeit the idea of "good" thought is a little subjective. The idea of a "good" communicator is also subjective. Some people would find Jeff Foxworthy a "good" communicator others no so much. Some would prefer me to use Lou Dobbs as an example of a communicator. Others would prefer Jesse Jackson. All three of these people I've deliberately chosen because they communicate well to each of their respective audiences.

The definition of the "good communicator" is dependent on the audience that the communicator is communicating with. Each of the three examples I've picked communicate with a group that each has their own definition of "good" thought.

The definition of a "good" programmer is probably just as changing depending on the three audiences that a programmer communicates with: the computer, other programmers, and the end-user. These three groups are radically different for different kinds of programming projects. Know your audience.

Just as Jesse Jackson's jokes won't play well on Lou Dobb's audience... and Jeff Foxworthy would not play well to an audience gathered for Jesse Jackson. However I am confident that all three of these men could prepare and change up audiences if they wanted to. They could each entertain the other's audience in a way that avoided real catastrophe... because all three of them are good communicators and know how to pick a message to suit an audience. It would be harrowing but I think any one of those men could pull it off.

With programming your device driver, database developer, and web designer don't play well against each other's audiences. A good programmer can learn the audience and play to it well. Because the good programmer is a good communicator.

2006-07-06

Terseness is good

Your head can only hold so much. Even very simple problems can flood your mind and escape your ability to follow them if they carry on long enough. For example addition is quite simple but if you are asked to keep a running sum for hours upon hours you are likely to begin making mistakes at some point.

Programmers face similar problems with software. Many seemingly simple things can be made unnecessarily complex by allowing a block to run-on without bound. The non-technical analogy might run something like this:

Which response to a query is preferable?

It is most assuredly true.

Yes.

2006-06-29

Lingua XML

How do you represent data? How do you exchange data on heterogeneous networks? How do you share representations of data between systems?

Since the dawn of modern computing (somewhere back around timestamp 0000000001 at the dawn of the epoch) we've had different methods for representing essentially the same data. Whether it was little-endian versus big-endian or variations on floating point numbers we haven't had a single common way to represent data.

This was a problem that has been attacked from several different angles. One was standards such as the IEEE floating point standard. CORBA was developed to create Interface Definitions that were mapped to platform specific implementations across machines and networks. Another approach was to declare plain old text as a standard and process it.

The plain old text approach had problems, one of which was not endian issues. The plain old text approach lacked structure. Without structure interpreting the text between programs became a chore. The parsers were brittle breaking each time a slight change occurred in one program's output. So structured text was introduced... And after a few iterations of this we get XML. The real power of XML is its ubiquity.

Obviously, ubiquity isn't something a computing standard gets automatically. People have to agree to use it. For example in the world of international languages French was once "lingua Franca" an expression meaning universal language but literally meaning language of the Francs. There was an attempt to create a new universal language but Esperanto is little more than a curiosity in practice. It isn't universal if people don't use it universally.

Just because a project uses XML doesn't make it better. You can do terrible things with an elegant tool. XML just gives us a universal tool to work with. It may not even be optimal for some tasks. Things such as JSON work better than XML for the specific task of asynchronous server to browser communication. XML, however, will probably win in this arena just because its power is its universality.

2006-06-27

Competing Mental Models: Object-Relational

In order to deal with complex issues, humans create models. The models we make deliberately ignore certain aspects of a real-world "thing" we deem as irrelevant. In this way we simplify a more complex problem enough to deal with it.

For example, when you try and solve the classic "If train A leaves city 1 at 8 am traveling 60 mph and train B leaves city 2 traveling at 40 mph at 8:30 am and the cities are 100 miles apart, when will the trains pass each other?" You ignore many facts about the trains, the cities, and train travel. How big are the trains? Was it raining? Did the passengers enjoy the ride?

In mathematics we have various models of the universe (sometimes called maths). Each new type of math has its own symbols and rules. Different kinds of math we find our selves using in computer science include graph theory and set theory. These different views of the world have generated different paradigms of computing that can compete with each other in the mind of the programmer.

In particular, I deal with (on nearly a daily basis) the competition between the non-complimentary techniques used in modeling data for Relational Databases and Object Oriented Programming languages. The term for this mental conflict is called the Object-Relational impedance mismatch.

I've observed this mismatch to yield some pretty strange ideas in the heads of my peers. I've seen designs that match one table per object with inheritance declared illegal because you can't model it "properly" in a database. I've seen developers completely ditch the concept of a database in favor of "pure" object designs that persist data in either serialized files or XML. And, I've even heard of doing away with Objects entirely in favor of "Data Oriented" designs.

If the model makes for more complexity than it solves... isn't it a bad model? At the end of a long day, it appears to me that the problem isn't in our heads it's in our languages. What our languages can communicate molds in part what our minds can model.

2006-06-23

Programmer = Communicator

I think it was Mitch Roth whom I first heard say,
"A good programmer is a good communicator."
I took MIPS assembly from Dr. Roth and he would grade our assembly not only on coding content but also on the grammar and spelling in our comments. Whenever students would complain about how this wasn't an English class but an assembly language class he would repeat the above quote. "A good programmer is a good communicator" was a common mantra at my university.

The programmer communicates their thoughts and ideas to both the machine and the other programmers who read their code. If your comments and notes don't leave a clear picture of what your code does and what it was intended to do, then you have failed as a communicator. If you are clear about your intentions and vision then you are more likely to have success.

2006-06-22

Lingua

If the language you speak in part constrains your thoughts, then isn't the same true for languages you code? If the language you speak can facilitate certain modes of thought, then isn't the same true for programming languages? Are there thoughts impossible to think in English that you can think in a programming language?

The computer is the first technology to act upon thought outside of a human mind. These thoughts are not the same as what the "analog" thinker thinks. The act of learning to program is transformational and forever alters the way that the student thinks about things. The thinker becomes a digital thinker.

2006-06-21

Software Engineer

Somewhere along the line we created the position of "Software Engineer" and distinguished it from other software roles such as Programmer, Developer, and Architect. Somewhere along the line we got the idea that software should be engineered.

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.
-- Frederick P. Brooks Jr.

This seems to me that the Software Engineer is an engineer unlike any other. Instead of having a physical world which will respond as expected or clearly not the Software Engineer must shape thought itself into a disciplined structure. The material that is to be formed, welded, shaped, beaten on, or engineered is the minds of all the people interacting with the software.

What is a Website? A Torrent? A Blog? Or an Instant Messege? How are they different? Why do we care? These ideas are the stuff of the Software Engineer, the raw materials of the builder of castles in the air made of air.

2006-05-30

Software is worthless

What is the value of software? The expense of software is easy to see, you must spend money on labor to produce software, to test it, and to maintain it. Where is the value?

Certainly, you spend money on software when it comes in cardboard boxes. Does this imply the value of software? No, that is only what you are willing to pay for software. What about software that lives on a website that you use, does that have value?

Software costs us to create it, but it is without intrinsic value. Why do we make such a thing then? The value of software is in its utility. As long as a task can be completed using a piece of software then the software has utility. The value of the utility is completely independent of the cost of creation for the software.

Some companies have traditionally tied the value of software to its production cost. These companies will estimate the number of boxes with software in it they can sell and amortize the cost of the production of the software across the projected sales. This leads to amazing profits when sales exceeded the projections.

The realization that software is itself worthless prompted other companies to adopt a subscription model. These models rely on some consumable that must become obsolete in a predictable time frame. The concept of a digital consumable is clearly counter the infinitely reproducible nature of the digital world.

With the maturation of the internet software companies have begun to sell the utility of their software components as services. Data is transmitted out to a service, transformed at the service, and received back by the client application. The elements that are charged for are now the transmission, reception and the processing. This is more at ease with the natural order of digital systems but it still is suffers from some ambiguities.

The processing of the data at the service end represents two elements of value. Firstly we have the utility of the software that performs the mathematical, linguistic, or heuristic transformation and this is the value of software. We also have the problem of the computation. The service executes on a computational strata and this strata has a utilitarian value independent of the utilitarian value of the software. When paying for the service is the user paying for the software or the computation? Is there an important distinction?

Software is worthless when it sits on a medium inactive. The software possesses potential utility and the value of this utility is independent of the value of the computational device that might execute it. The software's utility can be actualized on any compatible device and that property divorces its value from the value of the device.

The computational device certainly has a value independent of the software. The hardware can actualize a variety of software utilities and therefore has a value in that function. Along with the wonderful distinction of actually being a physical object and therefore being imbued with all the properties of a real object.

The problem with the application service provider model or software billing is the not quite unnatural coupling of the computational utility and the software's utility. This leads to a class of problems dealing with security, privacy, and continuity of service. The client of the application service provider now requires assurances about the security of their data in transit, the privacy or confidentiality of the data at the service end, and the continuity of the service over time.

To date the application service provider model provides one of the best matches between utility and value in software systems. We can spot some ambiguity in this model and a few invented problems, but, it is still a much better fit than the shrink wrapped box model. To get a better fit than this we might consider something very radical.

If we didn't charge for the software at all there would be no disconnect between the utility and value of the software. No charges, however, means no profit. No profits means no next generation of software. To overcome this problem we introduce profit back into the software business by introducing support services.

The free software and pay-per-trouble-call services means that you don't make money of the value or utility of the software anymore. The software becomes a platform for building a service company on top of. If the utility of the software matches demand then there will be call for services. The problem is that there is an great deal of force on the software provider to make certain that there must be a call for services.

The disparity of demanded utility versus the need for service calls can cause a software vendor to develop a product that while not flawed is unwieldy. The drive for simplicity of administration is removed from the software. The impulse to create easy to administer systems found in the shrink wrapped model of software business is there because in that model service calls are a drain on profits. In this model they are revenue. The company walks a knife edge too good and you don't get called enough, not good enough and you don't get used and then you don't get called. Fortunately, most of the energy of start-ups in this model is spent on getting good enough to get used.

There must be another model out there. One that gets the developer paid for finding the way to fill the utility that people want. There must be a way to fill utility and get paid for filling that utility without charging for shrink wrapped boxes or rented computational power. I'm not sure what that model is yet.

2006-05-23

Information Technology

Information Technology has existed ever since humans began writing things down.

2006-05-21

The word

The word is a powerful invention. With the word it is possible to refer to a thing without the physicality of the thing. So powerful is this ability to refer to things in the abstract that it leads to another form of existence for whatever it is we are talking about.

Imagine a world without words. In this world you can only point to an object. You can only learn by example. This is a short lived world. Each generation must learn over the lessons of the past generations. But if you have words, things are different.

When an idea is attached to a word, the idea's own existence is liberated from the single mind which created it. The idea can now be spread to another mind. This transfer of knowledge between minds is the birth of society because now knowledge need not die with the individual.

The better we construct words and build languages the more powerful and complex the ideas that we can transmit. Eventually, humans sought a method to store information outside of the speaker's mind in a way that would persist even if nobody could remember what the speaker had said. We invented the written word.

The written word had the power of the spoken word and it did not die on the wind. The written word could persist and could be replicated with exacting precision because it had a true atom. The written word could be replicated with such accuracy because it was composed of "digital" components called characters. Generations upon generations could copy the written word exactly without alteration as long as they adhered to the same character set.

As humanity built upon its ever more complex heritage of thoughts and ideas it built for itself mental devices to help organize ritual games of thought we might call mathematics. We found ourselves faced with describing things that were extremely abstract and yet very real in their own right. Mathematics enjoyed a time where it was seen as much as religion and spirituality as it was a tool to understand the more complex limits of human understanding.

In time we formalized these mental devices, augmented them with physical devices such as the abacus and mechanical calculators. And, finally, in the last few hundred years we have built for ourselves machines that could encompass in their behaviors all the rules of some systems of theory. We built for ourselves machines that we could speak to, machines that would react to what we spoke to them, and would follow whatever rules we laid out for them in a pantomime of human thought.

We created the computer, a machine we speak to, a machine that holds ideas.

Currently, the pinnacle of human achievement the computer can only now mimic the thoughts of the persons who speak their specialized languages. These languages are devised in layers to compile or break down from a human readable language to a machine language. In the same way a written word can be reconstituted to form a spoken word and become a thought in a new mind.

In the way that the spoken word gave birth to society, the written word gave birth to civilization, the computerized word will give birth to something equally profound. The spoken word allowed a person to communicate a thought to another person. The written word allowed a person to persist a thought beyond the immediately living sending that thought through time. The computerized word allows a person to communicate a thought outside themselves, through time, and think it inside the machine.


The word is the vessel of ideas. The written word is the preservation of ideas. The computerized word is the execution of ideas. Idea become reality independent of the thinker.

2006-05-19

There has never been anything like Software

I am not the first to note that there has never been anything quite like Software before. I may be one of the few that would contend that the advent of software is as significant to human history as the advent of the written word. I believe that we are only just beginning to see the impact of what software is on human society.

This blog will be about my personal journey with software.