Software Development Process and Industry Analysis by the former Editor of Software Development, Computer Language, and Game Developer Magazines
Archive for June 2006
I take it as a given that every stock touted via spam is, in fact, the subject of some sort of pump-and-dump scheme. That is, someone currently owning significant amounts of the stock (or options) is praising it, with the intent of causing upward motion, at which time they will sell their shares. So stock spam should be a reliable leading indicator of a loss of value. Therefore… Oh, you can’t sell penny stocks short.
Never mind.
“[Wayne Kelly is] pleased to announce the preliminary Beta release of the Gardens Point Ruby.NET compiler. Note: this is not just a Ruby/.NET bridge, nor a Ruby Interpreter implemented on .NET, but a true .NET compiler. The compiler can be used to statically compile a Ruby source file into a verifiable .NET v2.0 assembly or it can be used to directly execute a Ruby source file (compile, load and execute). Our implementation is not yet fully complete, but it is the only Ruby compiler that we know of for either the .NET or JVM platforms that is able to pass all 871 tests in the samples/test.rb installation test suite of Ruby 1.8.2.
Complete source code of our system can be downloaded from: http://plas.fit.qut.edu.au/Ruby.NET/Download.aspx
The blog is too cluttered with marketing-speak, but the accompanying 22-minute video is very good in conveying what “Project Glidepath” is about: guidance (including, but not just code templates) for “MicroISVs” (1-10 person SD teams), integrated into the IDE. Too much “software factory” talk has been very rarified; it’s nice to finally have an instantiation of the concept.
Apropos of yesterday’s blog entries (XML: Unix Pipe or ASM? and WS-* vs. REST/POX: Revenge of Worse is Better): the always interesting Peter Coffee paints a picture of how WS-* approaches to SOA lead to success. Contrast with Brian Marick’s Three Ages of Programming blog entry.
If we’re to have any defense against the zombie hordes, it will be by the innovative work of a generation of master roboticists. This vanguard of humanity will, perhaps, learn their skills using the new Microsoft Robotics Studio, available for free download . The only excuse to not check this out is if you are enrolled in a certified Summer program for ninjas.
I recently talked to a former client for whom I’d architected a system 4-5 years ago. When I left, they had a technical staff of about 10 and 2 clients using the back-end system we developed. Today, they have the same size technical staff and 900 clients using the system for their back-end. Yeah, baby!
I screwed up an online order entry and wrote to customer service, saying that I wanted to affirm that I ordered two instead of one. This was how “Josh” began addressing the issue: “I recognize your concern that you want to affirm that you ordered….” Seems rather Eliza-esque to me.
Fluffernutters banned from schools. Mmmm…. Fluffernutter. Between Fluff, Necco Wafers, Hoodsies, and Drake’s Cakes, my Boston childhood was apparently in line with the “eat locally” value. I wonder where Spaghettios were invented…
Richard Gabriel’s famous essay “The Rise of Worse is Better” (which, incidentally, I still think was originally published by me when I was editing AI Expert) details the “survival characteristics” of two approaches to software design: the “MIT approach” and the “New Jersey approach” (Bell Labs). He proposes these characteristics and values:
| MIT refinement | New Jersey refinement | |
| Simplicity: The design must be simple, both in implementation and interface | It is more important for the interface to be simple than the implementation. | It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in design. |
| Correctness: The design must be correct in all observable aspects. | Incorrectness is simply not allowed. | It is slightly better to be simple than correct. |
| Consistency: | The design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness. | The design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency. |
| Completeness: The design must cover as many important situations as is practical. | All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness. | All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface. |
Gabriel’s greatest leap was to put aside his emotional attachment to the MIT approach and observe that even in the intentionally bad picture presented here, the New Jersey approach (labeled “worse-is-better”) has “better survival characteristics” than the MIT approach.
When considering my previous post on whether XML is the assembly language or UNIX pipe of Web 2.0, I realized that this was yet another battleground for these two philosophies, but ironically, the “usual suspects” seem to have reversed positions: it’s primarily the large vendors who are promoting the MIT-like WS-* stack and the academics / free-thinkers / entrepreneurs who are promoting the simplicity of REST/POX.
Since, as I made it clear in the previous post, I’m a REST/POX proponent, this is somewhat dismaying. Particularly worth deep consideration is the final part of Gabriel’s article, where he discusses how the approaches, once popular, evolve towards reuse and flexibility.
The sharp and capable Clemens Vaster says that “XML is the assembly language of Web 2.0,” drawing a complexity/productivity analogy to higher-level programming languages, which everyone but Steve Gibson thinks are worthwhile tools. The upshot: “[we] have arrived at the point where matters have gotten so complicated that a layer of abstraction over pretty much all things XML has become a necessity for everyone who makes their money building customer solutions.”
Not everyone agrees: James Speer balks andTomas Restrepo says that that Clemens is conflating XML and WS-*.
I disagree even more vehemently. One of my favorite recent quotes was Ray Ozzie’s quip that “RSS is the UNIX pipe of the Web.” In addition to being encouragingly the sort of quote (technical, insightful, engaged with current trends) to encourage Microsoft watchers, I heartily agree with the implicit emphasis on flexibility.
One of the defining characteristics of assembly language is that it is inflexible: it’s hard to write high-abstraction-level code in ASM (possible, but it’s not facilitated by the language). Another characteristic is that it is dominated by implementation idioms. What springs to mind is is XOR AX,AX which a generation of x86 programmers used to set a register to 0 because it was mildly faster than MOV. Because all abstractions leak, all “blackbox” systems are fuzzy and imperfect. No matter how worthwhile the aspirations of the WS-* stack, in practice systems using the stack will gather implementation-specific peculiarities. Perhaps no more than any other framework, but when tools are used to generate significant amounts of code, they inevitably produce low-abstraction code. Look at interface designers and the naive way they align controls: not by using a variable or directly referencing a dominant control, but by generating the same code over and over.
Similarly, if the XML moving between our Web 2.0 services is primarily tool-generated and difficult to comprehend, that will stand in the way of intermediaries adding value, which are an essential part of Web architectures. RSS is successful, not in spite of being “really simple,” but in large part due to being so. The same is true of HTML. The same will be true of the next major innovation in Web 2.0.
