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-29
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.
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,
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.
"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.
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.
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.
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.
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.
Subscribe to:
Posts (Atom)