Test

The July 08 (Vol. 30, #7) IEEE Transactions on Pattern Analysis and Machine Intelligence has an incredible paper by Raykar, Duraiswami, and Krishnapuram. A Fast Algorithm for Learning a Ranking Function from Large-Scale Data Sets appears to be a game-changer for an incredibly important problem in machine learning. Basically, they use a "fast multipole method" developed for computational physics to rapidly estimate (to arbitrary precision) the conjugate gradient of an error function. (In other words, they tweak the parameters and "get a little better" the next time through the training data.)

The precise calculation of the conjugate gradient is O(m^2). This estimation algorithm is O(m)! (That's an exclamation point, not a factorial!)

On a first reading, I don't grok how the crucial transform necessarily moves towards an error minimum, but the algorithm looks (surprisingly) easy to implement and their benchmark results are jaw-dropping. Of course, others will have to implement it and analyze it for applicability across different types of data sets, but this is one of the most impressive algorithmic claims I've seen in years.

Once upon a time, I had the great fortune to write a column for a magazine on artificial intelligence and could justify spending huge amounts of time implementing AI algorithms (well, I think I was paid $450 per month for my column, so I'm not really sure that "justified" 80 hours of programming, but I was young). Man, would I love to see how this algorithm works for training a neural network...

CodeGear, the company semi-spun off from Borland's languages division, has been acquired by Embarcadero, the company best known for enterprise-y DB tools such as ER/studio.

The half-measure of announcing the division's sale and then holding on to it was always ugly and even though Embarcadero is probably not the most exciting company in the SD tools marketplace, better a loving step-parent than continuing the cycle of abuse at Borland.

Of course, being an "exciting" company that attempts to redefine the coding playing field may not be smart for a tool company; I always cling to such when I talk about Borland's languages division, which celebrated its 25th anniversary the other day, but it is neither the only nor perhaps the smartest strategy.

In the Summer and Fall of 1999, at the peak of the dot-com boom, there was incredible competition for software developers. Starting pay for developers with no experience had already climbed to $60K and then, in the course of maybe 3 months, it went from $60K to $75K to $90K. And that was actual money, not soon-to-be-toilet-paper stock options.

A guy as American as apple pie came in, fresh out of college, applying as a Java developer. He didn't know the difference between a class and an instance and didn't know what inheritance was. So, just as incompetent as anything I'm seeing today. I started to explain to him that software development was a wonderful profession and that if he wanted to learn it, the traditional way would be to apply as a junior tester, and ... He cut me off, told me he had 5 other interviews lined up that week and made it clear that he expected to be hired at one of them. And I don't doubt that he did.

But I doubt that he's still incompetent and employed as a software developer and especially not as a freelance coder. I think he either:

• was weeded out of programming (perhaps by going into management), or
• got a clue

I complained the other day about an incompetent applicant from South American so I'll use as an example another guy on the team who lives in South America, "gets it" as far as software development goes and charges $24 an hour. He lives in a beautiful house on, like, 10 acres or something, owns several horses, and I get the impression that he's considered quite the young go-getter.

So when people think the moral of my story is "cheap employer...you get what you pay for" I think they're entirely off-base. If you're willing to create a distributed team (the wisdom of which is a whole question in and of itself), you might find yourself in the enviable position of being able to give a smart person a high standard of living and contributing to a developing economy tra-la-la-la-la all while paying less than an American median wage. It's hard for me to see the argument that that is immoral.

It's not the nationality of incompetence that's depressing me, nor is it necessarily the scope of the incompetence embodied in a single person, it's how common it is that I encounter people who have no respect for this activity that I love. I feel that I'm seeing it more often than I used to, and while I may be imagining that ("When we were kids we hiked 7 miles through the snow to the data center..."), I think it's a real phenomenon.

Some people suggested that the language involved might have something to do with it, and others suggested that it might have to do with the increasing amount of hand-holding in modern development environments. I still tend towards my feeling that global commodification has something to do with it; more and more people applying for jobs in the field of software development did not enter that field due to a love of computers or software, they entered it because there's demand.

There have always been developers for whom programming is "just a job." Back when I was Editor of Computer Language, it was common-place to refer to the statistic that "the average programmer has less than 1 book on software development." But it was easy for me to ignore that, because those weren't the people who read magazines and attended conferences and swapped stories on Compuserve's CLMFORUM. So maybe I am just being an old codger. Except instead of CLMFORUM, when I look for reaction to my thoughts I find griefers on reddit making ad hominem attacks. Progress.

I'm trying to hire a couple developers. One guy sent a resume that looked great -- degree in CS, C++ experience, a year with Ruby in Rails. So I sent him a simple programming exercise. I sent him the testcases.

He shoots back an answer. I open a command-line, type ruby TestCases.rb and see this:

9 tests, 0 assertions, 0 failures, 9 errors

He didn't even get to the freakin' assertions! His "solution" didn't treat the argument as an array.

Once upon a time, I programmed by sliding cards in a box under a window and returning 15 minutes later for the results. Once upon a time, I programmed by writing object files that could take anywhere from a few minutes to overnight to link together. If we still lived in those times, I could understand submitting some text and saying "I think this is a solution." We don't live in those times anymore.

This guy was from South America. A lot of the guys I'm dealing with lately have been from outside the United States -- we're a distributed team and, all things being equal, a guy with a CS degree, C++ experience, and a year with Ruby on Rails who's asking $20 an hour is going to be more appealing than a guy with the same background asking $60 an hour.

I don't know if it's a cultural thing or a "younger programmer" thing, but I have to say that I'm getting really freaking tired of experiencing this level of incompetence, even for the thirty seconds it took me to see that and respond "Nope. Not even close" to HR. It's actively depressing to me to experience this crap.

To be clear, this has nothing to do with this guy's innate talent or intelligence. What it has to do with is this ... mindset .... that seems to be entirely at odds with my conception of the activity of software development. I'm not talking about an ignorance of, much less disagreement with, my particular biases and judgments about the niceties of methodology and process. I'm talking about people who don't seem to "get" that programming is, at the very least, about making programs that run.

And, accuse me of jingoism if you will, but I have to say that it's depressing that it's virtually impossible for an American to make a median wage being a freelance coder because their resumes probably look worse than that of these people with CS degrees who don't freaking bother to see if their programs run.

Of course intelligence is distributed evenly throughout the world, but this level of incompetence has largely been weeded out of the American freelance programming community. If you're making a living and you have to charge twice what a person in South America or Asia charges, you pretty much have to "get it." And it is sad to consider a bunch of people who "get it" slowly being weeded out of the workforce because we are unable to clearly and concisely demonstrate value to potential employers.

Update: I've removed the name of the fellow's country, which is one I've always wanted to visit and which I'm sure has many fine developers. It's not relevant, other than to make the point that it's not just one country in Asia where there are freelance developers looking for work and charging significantly less than their American or European counterparts.

https://portal.acm.org/poplogin.cfm? .... etc ... (I can't post the whole URL since it's linked to my account)

I recently wrote an encomium to ResolverOne, the IronPython-based spreadsheet:

[T]heir use of pair programming and test-driven development has delivered high productivity; of the 140,000 lines of code, 110,000 are tests....ResolverOne has been in development for roughly two years, is written in a language without explicit type declarations, and is on an implementation that itself is in active development. It’s been brought to beta in a credible (if not downright impressive) amount of time despite being developed by pairs of programmers writing far more lines of test than application. Yet no one can credibly dismiss the complexity of 30,000 lines of application logic or spreadsheet functionality, much less the truly innovative spreadsheet-program features.

ResolverOne is easily the most compelling data point I’ve heard for the practices of Extreme Programming.

[Extreme Program, SD Times]

Allen Holub sees the glass as half-empty, writing:

I want to take exception to the notion that Python is adequate for a real programming project. The fact that 30K lines of code took 110K lines of tests is a real indictment of the language. My guess is that a significant portion of those tests are addressing potential errors that the compiler would have found in C# or Java. Moreover, all of those unnecessary tests take a lot of time to write, time that could have been spent working on the application.

I was taken aback by this, perhaps because it's been a good while since I've heard someone characterize tests as evidence of trouble as opposed to evidence of quality.

There are (at least) two ways of looking at tests:

1. Tools for discovering errors, or
2. Quality gates (they're one way -- are they quality diodes?)

There's no doubt that the software development tradition has favored the former view (once you've typed a line, everything you do next is "debugging"). However, the past decade has seen a ... wait for it ... paradigm shift.

The Agile Paradigm views change over time as a central issue; if it were still the 90s, I would undoubtedly refer to it as Change-Oriented Programming (COP). Tests are the measure of change -- not lines of code, not cyclomatic complexity, not object hierarchies, not even deployments.

(Perhaps "User stories" or scenarios are the "yard-stick" of change, tests are the "inch-stick" of change, and deployments are the "milestone" of change.)

So from within the Agile Paradigm / COP, a new test is written that fails, some new code is written, the test passes -- a one-way gate has been passed through, progress has been made, and credit accrues. From outside the paradigm, a test is seen as indicative of a problem that ought not to exist in the first place. The passing of the test is not seen as the salient point, the "need" for (i.e., existence of) the test is seen as evidence of low quality.

In true test-driven development, every pass fails at least once, because the tests are written before the code. What is perhaps not appreciated by those outside the Agile Paradigm, however, is that tests are written that one expects to run from the moment the relevant code is created. For instance, if one had fields for sub-total, taxes, and total, one would certainly write a test that confirmed that total = sub-total + taxes. One would also certainly expect that test to pass as soon as the code had been written.

As is often the case with paradigms, often just realizing that there are different mental models / worldviews in play is crucial to communication.

Update: This relates to Martin Fowler's recent post on Schools of Software Development.

It's been quite a year for Python, and Google App Engine provides the dynamic language a very high profile indeed. GAE is a cloud platform that is competitive with Amazon's S3 (much like Stratos, on the planet Ardana might compete with Cloud City on Bespin ). GAE provides Django and other major Python frameworks, but I imagine that the real appeal is (a) the free hosting and (b) the CPU budget.

From Miguel de Icaza comes word of Igor Moochnick's open source implementation of Powershell, the excellent (if frustratingly verbose in its default configuration) shell from Microsoft

Hmm.... this post advocating Collective Code Ownership as "the most important principle of XP" has a link to my comment on "bad programmers are not good programmers who are slow"

The implication is that either:

1. Counter-productive programmers are a myth and a scapegoat at all times, or
2. CCO is a cure for counter-productive programmers

If (1), I'll restate that what little evidence we have about programmer productivity points to a productivity distribution that's skewed with a long tail of incompetence.

So, (2) CCO is a cure for low- or counter-productive programmers. I don't see that at all. For one thing, I don't see any mechanism by which CCO improves the talents of the worst programmers. It exposes them to higher-quality code than they write, true, but bad programmers don't learn by example (I'm tempted to say their lack of self-educational initiative is their defining characteristic).

From a managerial perspective, CCO can actually hide poor programming, in that a poor programmer does a "works on my machine" or "works for the default scenario" piece of crud, and a good programmer comes through and refactors the work before the poor programming is exposed. The good programmer is disgusted and frustrated and slowed, but management sees Bob The Poor and Gwen the Great as both finishing one task.

With version control logs, Bob's role in the poor work is not hidden to Gwen either, so it's not the case that the communal nature of CCO tempers her resentment.

I'm 100% for CCO, but I don't see it as having anything to do with incompetent programmers. (Clarification: I'm 100% for CCO, but that doesn't mean it can't 'hide poor programming' as discussed above. Nothing's perfect.)

Andrew Binstock says:

Ever-dependable O'Reilly just released Ruby Programming Language, which is without a doubt the definitive Ruby reference. Not only is it co-authored by Yukihiro "Matz" Matusmoto, the inventor of Ruby, but it is superbly well edited, so that every page is full of useful information presented clearly. And at more than 400 pages, that's a lot of information. Couple this book with The Ruby Cookbook, which I reviewed on this blog, and you have probably the best 1-2 combination for learning and using Ruby.

I haven't seen the book myself, but I trust Andrew's judgment. I certainly agree on the value of The Ruby Cookbook.

OK, time to reset:

Attention is a finite resource...

StartKey will be a technology that allows you to carry your Windows logon around on a USB keychain. Early reaction is mixed as to the value of this, but I loved something similar when I worked for a company developing software for Sun JavaStation network computers.

With JavaStation's, you had a smartcard that you plugged in and, after 10 seconds or so, up would come your desktop. Since most of the time you work at your desk, most of the time this was not particularly valuable. But let me tell you -- it was fantastic for meetings and presentations. No messing around with cables and display settings, no hand-waving when trying to describe an issue you were talking about when you happened to be on the other side of the office.

The difference is that the JavaStations were uniform hardware, too, and all your software lived on the server (which, it turned out at 7AM the morning of a major trade show, is a single point of failure). While you might have a good experience assuming that a random machine has Office on it (a smile creeps across Microsoft's face), there would presumably have to be a solution for specialist software such as Visual Studio or Photoshop that could not be assumed to be local.

I would think the problem with that is that although memory sticks are probably getting capacious enough, the bus connection between the memory sticks and the main computer are going to be bottlenecks.

Tor.com is giving away eBooks of apparently-well-known authors. It's been a long time since I've followed SF, but "free eBook + Kindle" is too good to pass up. So far, I've received:

• Old Man's War by John Scalzi -- I'm reading this now; it's kind of like an updated Starship Troopers with a sense of humor.
• Spin by Robert Charles Wilson
• The Outstretched Shadow by Merces Lackey and James Mallory

Ted Leung has joined Sun to help support Python "in a similar fashion" to the JRuby project.

This is not just about Python on on the JVM. Sun will try to make its platforms, OpenSolaris and the JVM, the best place to develop and deploy Python applications.

But it's mostly about Python on the JVM. With IronPython approaching "fully baked" status, Python book sales up 31% over last year (http://radar.oreilly.com/Language_all.jpg), and applications like ResolverOne, Python is stealing some of the dynamic language thunder from Ruby.

The relative pace of Jython/JRuby and IronPython / IronRuby ought to provide plenty of ammunition for undoubtedly-overly-broad conclusions about the technical merits of the managed platforms and corporate cultures.

Let's assume you're a pretty good programmer (and good looking to boot!). It's Monday morning and you're looking at a task that has some solid complexity to it -- it's going to take you 40 hours of effort to get through. Or you have the option of delegating components to 2, 3, or even 4 competent-but-not-exceptional developers. For these guys to deliver, you're going to have to:

• Decompose the task significantly
• Write a precise spec, at least for the initial subtasks (because if you get off on the wrong expectation of data structures, there's no way you're going to catch the problem, refactor it, and re-distribute the tasks)
• Engage in course correction (when facing ambiguity, "problem solving" for these guys is going to be asking you for clarification)
• Do some refactoring (let's face it, there's going to be a couple things that will be easier to fix than re-specify)
• Spend (at least) one afternoon on interactive testing and integration

(For "decompose" and "write a spec" feel free to interpret however you wish, so long as it's a concrete deliverable that acknowledges that if you're delegating and "fanning out" tasks, you have to pay an upfront cost thinking through scenarios that are still somewhat hazy and contingent.)

So here's my question: how many hours do you think you can shave off the 40 hours it would take you to "just do it" yourself? 8, 16, 32?

There are (at least) 2 points that strike me as relevant : one is that even in such a fine-grained, seemingly controlled, context you face significant "mythical man-month" issues of communication overhead, risk, etc. and so you discover, if you time it, that you don't save nearly as much time as you'd hope.

The second point that I think might be even more interesting is that your perception is likely to be even worse than what the clock says. If you are in this role, you will rarely or never get into a high-productivity "flow" state, a familiarity with which, I would submit, is why you're a pretty good programmer.

http://barrkel.blogspot.com/2008/02/langnet-symposium-videos-are-up-in-wmv.html

Recommendations :

http://langnetsymposium.com/talks/Videos/1-05 - Lively Kernel - Dan Ingalls - Sun.wmv

http://langnetsymposium.com/talks/Videos/2-01 - Newspeak - Gilad Braha - Cadence.wmv

http://langnetsymposium.com/talks/Videos/3-08 - Cobra - Chuck Esterbrook.wmv http://langnetsymposium.com/talks/Videos/3-09 - Intentional - Magnus Christerson.wmv

http://langnetsymposium.com/talks/Videos/3-00 - IronRuby - John Lam.wmv

http://langnetsymposium.com/talks/Videos/3-03 - Parsing Expression Grammars in FSharp - Harry Pierson.wmv

LINQ seems to be an overwhelming success (I've been having a hard time finding anyone with bad things to say about it), but what most people are talking about is the nice Object-Relational mapping tools. The ultimate goal of LINQ, though, includes uniting not only objects and relational data but XML. The current LINQ for XML does not support schemas, which is a significant limitation if you're trying to really unify a model; for instance, I have a client who needs to integrate two relational models, a middle-tier object model, and an XML data store. Today, we spend significant time batting back and forth XPaths and tracking them in and out of the relational model. As for reporting, the less said the better.

LINQ to XSD is the necessary next step: a set of tools for LINQ that understand the type information expressed in W3C Schemas.

There were next-to-zero technical books available for the Kindle shortly after its launch. I was delighted to discover 4 of the 12 books that were finalists for Jolt Awards this year are now available in Kindle form:

• Geekonomics
• Outside In Software Development
• WPF Unleashed
• xUnit Test Patterns

(follow image link to Zazzle store...)