30K + 110K = success or failure?
Stories Columns Opinions Resources
Sun extends Groovy, PHP support to NetBeans
Version 6.5 of the IDE will see complete support for those two languages along with comple...
|
Sun reorganizes its software production infrastructure
Facing economic hardships, lost revenue and loss of employees, Sun has split its software ...
|
Adobe steers Flash toward RIA implementation
At this year's Adobe MAX Conference, the focus was on Flash, this time making Flash more o...
|
BigLever builds a bridge to SCM with Gears
The Gears Universal Configuration Management Bridge allows CM systems to integrate with Ge...
|
SOA Watch: New economic realities
In the current economic downturn, agile programming and SOA are attractive options that bu...
|
Integration Watch: A new twist on threads
The key to raising the efficiency of multiprocessors is to shrink the overall workload by ...
|
Integration Watch: The Return of NetRexx?
Java scripting languages are seeing a surge in popularity, with NetRexx looking particular...
|
Windows & .NET Watch: Transaction crowd gets a boost
With multicore chips becoming the standard for processors, the need for a flexible, usable...
|
From the Editors: Election should shake up JCP
Rod Johnson has the right ideas for opening up the Java Community Process, and he may be a...
|
Letters to the Editor: Sun gives REST, SOAP choice
A reader takes issue with a headline on our story about Sun working with REST along with S...
|
Guest View: Be smart and lazy
The optimal solution for problems is the simplest one, so always aim to streamline your ap...
|
Zeichick's Take: From EXEC to EXEC 2 to REXX to NetRexx
Andrew Binstock's column last week, "The Return of NetRexx," brought back some fond memori...
|
Practical tips for saving money on code maintenance
If software design is expensive, well, code maintenance is even more so. When you look...
|
Transform your app-dev quality by involving the whole community in testing
As the saying goes, the more eyes you have on software, the shallower the bugs. That’...
|
Build your dev and test labs for less – a lot less – with virtualization
You don’t have the budget to equip developers and software test teams with all the har...
|
Software Common Hacks and Counterattacks: A Guide to Protecting Software Products against the Top 7 Piracy Threats
Software piracy continues to be a growing epidemic. This white paper examines prevalen...
|
By Larry O'Brien
May 15, 2008 —
My recent column on Resolver System’s ResolverOne spreadsheet (March 15, page 32) drew numerous comments, including one from former SD Times columnist, Allen Holub. Allen’s thesis: “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 addressing potential errors that the compiler would have found in C# or Java in turn triggered a flurry of Web postings on sites such as reddit.com and Hacker News on ycombinator.com.”
Allen’s opinion is one I respect, but this position took me aback. It seemed to me self-evident that bringing a commercial application to market in two years counted as a success and that credit should be given to the tactics used, whatever they might be. As for Resolver One being a “real” programming project, I thought that was self-evident, too. Even putting aside its exposure of Python to the end user, it’s a fully functional spreadsheet. Although not directly comparable at the feature level, Steve McConnell recently quoted the 1989-1990 development of Lotus 123 version 3 and Excel 3 at 400K and 649K lines of code with staff efforts of 260 and 50 staff years respectively (tinyurl.com/353svp).
Allen’s own newsletter (regrettably infrequent) quotes a mean level of productivity at 26 LOC/day/person. Personally, I primarily work with corporate teams and it seems to me that primary application sizes of 10-50K lines of code are typical of applications developed in the past decade. All of which seems to count towards the idea that Resolver One is worthy of attention as a programming task. (On the other hand, Chandler Desktop, the Python-based PIM whose rocky development was documented by Scott Rosenberg in “Dreaming in Code” appears to weigh in at more than 500K non-blank, non-comment lines.)
It’s clear, though, that Allen is not alone in thinking that something is amiss. The most common criticism in online discussions of the issue seemed to be the assertion that test-driven development is slower, first for the obvious reason that the time spent writing a test function is time that could be used on application code, and the less obvious (but I think more substantial) observation that test code itself will have incorrect assumptions, be misleading and require maintenance. In other words, it’s code, and it shares the non-accidental characteristics of all code.
In response, some suggested that some form of meta-testing should be used to lower the volume of test code (I’m wary of test suites with high abstraction— www.sdtimes.com/content/article.aspx?ArticleID=31101). Predictably, many commenters squabbled over the distinction between type safety and explicit type declarations, a kerfuffle that shows no sign of abating in the four years since I lamented it as a distraction in this column (www.sdtimes.com/content/article.aspx?ArticleID=27644).
To me, the online discussion drove home the existence of a rift in development mindsets. This rift is reminiscent of, and I believe as substantive as, the rift that developed in the early 1990s between proponents of object-orientation and skeptics. At the time, there was much discussion of the “paradigm shift” required by object-oriented programming. This shift is a wide-ranging mental readjustment of concerns and attentions and, on either side, it becomes very easy to talk right past each other. Too often this devolves into “they just don’t get it” thinking. In the case of extensive unit testing, I think what’s at play are two fundamentally different ways of viewing tests.
There are at least two ways of viewing tests: as tools for discovering errors, or as gates measuring quality. There’s no doubt that the software development tradition has favored the former view (after typing a line of code, everything that follows is “debugging”). This view is evident when people talk of the “need” for a test—a test is “needed” to discover something. But the Agile Paradigm sees change over time as a central issue; if it were still the 1990s, we would undoubtedly call it Change-Oriented Programming. A test is written, not to discover behavior, but to validate progress. In true test-driven programming, the tests are written before the code, so they always fail once. But many tests are written that are expected to pass the first time they are addressed. For instance, if one had a field that calculated a sub-total and its taxes, one would certainly test the addition, even though one would expect it to work from the get-go.
From within the Agile Paradigm, a new test is written that fails, some new code is written, the test passes—a one-way gate has been passed, 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.
As is often the case with communication, just recognizing the existence of an impasse can be the critical step to making a change.
Larry O’Brien is a technology consultant, analyst and writer. Read his blog at www.knowing.net.
Related Search Term(s): QA Testing
Share this link: http://sdtimes.com/link/32059