Archive for the ‘Technology’ Category
This is old news for most, but posting it here to point people at, when I hear another passionate conversation about productivity and programming languages.
In 2000, Lutz Prechelt compared several programming languages in a reasonably rigorous experimental structure, and came to the conclusion that
In general, the differences between languages tend to be smaller than the typical differences due to different programmers within the same language.
This is not to say that fundamental innovation in programming languages is not possible (think garbage collection). There is also not denying the fact that languages have substantial differences, in tooling, in the culture of their communities, certainly in people’s personal preferences, and in the sweet spots of their use cases. However, it is certain that most discussion on this topic is superficial, emotional rather than evidence based, and woefully ignorant of experimental results in this area.
Joe Morrison talks about branching and merging in his latest post. I was about to comment on his blog, but my response became so long that it probably deserves a post on its own, so here goes.
Many established (old school/expensive? 🙂 ) SCM systems (Clearcase, Continuus/Synergy etc) are built around making carefree branching easy, and indeed desirable. However, they also are heavily centralised systems, and thus I feel a slight sense of irony around the current hype on distributed version control, which are really all about having your own private branch(es).
The primary use-case for git in the Linux kernel development is the patch workflow: the ability to create, maintain, verify and apply individual patches. The lack of a centralised server is really an optional extra, a nice side effect.
Which brings me to my central point — I think what branching strategy to use should really be a function of your release planning methodology. Ask yourself this: Are your releases on a timed schedule, or on a feature schedule? Do you have multiple teams working on features with differing time to market, or is everybody working on a the same schedule? Are your feature sets held constant during development, or are they constantly shuffled? How often do you find yourself slipping planned features from one release to another? These and other such questions should determine your branching strategy.
A good way to think about these issues is shown in a great presentation by Laura Wingerd (that I found linked via Joe’s post), which talks about the concepts of ‘Convergent Branching‘ vs ‘Divergent Branching‘
There is one other consideration that matters – integration environments. For a self contained project, there is no cost to have a multitude of integration environments. However, for more integration oriented projects, even if your SCM enables you to create private branches easily, you’ll need to worry about how to test each branch. How far do you trust your unit tests to go before you’ll want to do integration testing against real backends? Do you need an integration environment for every private branch, or can you get by with integration testing after a merge into mainline?
It is unfortunate that a developer population weaned on CVS and SVN (myself included) are trained to consider merging a pain, and thus force themselves to reduce branch usage. Rather, try and get the tool to follow your requirements, and not the the other way around.
Mark Pilgrim has started writing Dive Into HTML5, and has the first chapter on Canvas online now. It addition to interesting content, its beautifully typeset, in a very “retro” style. If you aren’t seeing the fonts as in the screenshot below, get a better browser.
HTML5 is a quite a revolutionary upgrade to the browser, but the key outstanding question is tooling support/framework support. I’m sure it’ll come, but not sure when, and whether it will be too late. The Register has more thoughts on that here.
Tom DeMarco has an interesting article in this month’s IEEE Software, where he wonders if Software Engineering is an idea whose time has come and gone.
Reflecting on his early book on software metrics, he suggests that software projects could do with less control and more management.
I’m gradually coming to the conclusion that software engineering is an idea whose time has come and gone. I still believe it makes excellent sense to engineer software. But that isn’t exactly what software engineering has come to mean. The term encompasses a specific set of disciplines including defined process, inspections and walkthroughs, requirements engineering, traceability matrices, metrics, precise quality control, rigorous planning and tracking, and coding and documentation standards. All these strive for consistency of practice and predictability.
Consistency and predictability are still desirable, but they haven’t ever been the most important things. For the past 40 years, for example, we’ve tortured ourselves over our inability to finish a software project on time and on budget. But as I hinted earlier, this never should have been the supreme goal. The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business. We’ve been rather successful at transformation, often while operating outside our control envelope. Software development is and always will be somewhat experimental. The actual software construction isn’t necessarily experimental, but its conception is. And this is where our focus ought to be. It’s where our focus always ought to have been.
Scaling and maturation are not the obvious processes they appear to be because they take so much time that the accumulated effort is easy to overlook. To be successful, they must also be very carefully guided by people who can envision the end result, but that makes it appear to many as if it merely “happens”. Take a good idea out of its infancy, let it age without guidance so it does not mature, and it generally goes bad.
I think the only evidence of good ‘design’ in in how software ages. The rest is noise.
As Morgan Stanley Matrix is released to clients, its groundbreaking nature is being finally revealed. A new and bespoke internet trading platform with this amount of complex interactivity is a fascinating design and architecture problem, from the usual suspects, to some unique challenges. Leading our team to architect and deliver the services for Matrix has been, and continues to be, a challenging exercise in solving issues of integration, scalability, stability and asynchronicity.
Talking of visualisations, came accross this new forex visualisation from FinViz. While we’ve seen and done better, this looks pretty nifty for being pure html. It ‘s performance is quite snappy as well.
Came accross an old series of articles by Julian Browne on Space Based Architectures. A nice exposition if you are interested in the topic. Gelernter’s original paper on Tuple spaces and Linda is a good read, if only to understand the history of the idea.
While the technology is easy to pick up for a reasonable competent programmer, the difficulty in doing something like this is, i think, in ensuring that the solution architecture is appropriate for the problem domain. In those situations, these kinds of tuple based solutions provide order of magnitude reduction in complexity when building large and resilient systems.
Google Native Client is a technology for running native x86 code in web browsers. “What!” I hear you exclaim, “why does the world deserve another instance of the ActiveX disaster?”
Not so fast. Building on the idea of Wahbe et al from the early 90’s, its basic idea is to build a verifier for a slightly constrained x86 binary. The folks at Matasano Chargen have a good analysis of the security issues in this architecture.
However, given the current prevalence of managed programming environments as browser plugins (in Flex and Silverlight), one wonders if there is a large user base for writing native applications for the browser. Games are of course one obvious candidate (the NaCl demos contain a Quake port.) In any case, this is something worth watching over the next couple of years.