Paul M. Jones

I remain unconvinced of the benefits of test-first and test-driven development (TDD) because I think the underlying principles of TDD are lacking, not because of the way TDD adherents talk about those principles. I believe I understand the test-first adherents very well, and I disagree with them.

I agree with Travis that many TDD and test-first devotees suffer from what Travis calls “expertise syndrome”. I think almost anyone who has a great deal of sophisticated and nuanced knowledge on a particular topic must actively look out for and modify the kind of behavior Travis describes.

But neither the “expertise syndrome” nor the sometimes religious zeal of many TDDers are the cause of my ambivalent feelings about test-first. Instead, I simply fail to see that TDD is really so useful as its adherents anecdotally proclaim. This is not because their communication skills are lacking in some way, but because I find the idea of TDD itself to be lacking.

I have various reasons for thinking test-first is not the fantastic solution its devotees claim. Chief among my reasons is this: a programmer not already familiar with the domain of a non-trivial problem generally doesn’t know enough to write meaningful tests in advance. The act of writing the code as a solution will train the programmer in the domain. He can write more useful tests afterwards to make sure future changes to the code do not break existing behaviors.

The Map Is Not The Territory

I think test-first is not likely to help most programmers understand the problem any better — test-first is only going to tell the programmer if his code works the way he thinks it should, not if it solves the problem he is addressing.

This is because the the map is not the territory. That is, a “paper abstract” map of the problem is not the same as the “physical concrete” territory of the problem. The map may provide useful hints, but until you have explored the territory, your understanding of reality is severely handicapped regardless of how smart, intelligent, or clever you think you are.

Test-first assumes the map of the problem is sufficient. In reality, unexplored assumptions and unexpected interactions abound. Test-later depends on you having explored the territory of the problem, becoming familiar with the reality of the situation by working through it yourself and gaining personal experience with it. Your solutions will be all the better for it, and your tests will then reflect the real territory, not the abstract map.

Thus, I believe test-later is more accurate and more useful, as well as a more effective use of your limited time when checking solutions in code, because it is based on practical experiment, not hypotheticals.

Testing Is Useful

Testing is useful and necessary. Unit, system, and integration testing are a great tool to help find, remove, and prevent new errors in working code. I do not think that test-first is any better than test-later, especially for programmers who have good self-management and self-discipline.

David Sklar has said in regards to testing that “tools are secondary, discipline is primary” (see slide 40). I heartily agree. In this sense, I think for programmers who have good discipline, test-first might well be a good tool. But test-later is just as good a tool, and perhaps a better one.

Similarly, with programmers who have mediocre or poor self-discipline, test-first and TDD may help them produce better code … but the quality of that code will still be lower than that generated by good programmers who take the time to explore the problem domain.

It appears that at least one bit of research supports my otherwise unproven assertions in this regard. Or, rather, the debunking of one bit of research.

• The control group (non-TDD or “Test Last”) had higher quality in every dimension"”they had higher floor, ceiling, mean, and median quality.

• The control group produced higher quality with consistently fewer tests.

• Quality was better correlated to number of tests for the TDD group (an interesting point of differentiation that I'm not sure the authors caught).

• The control group's productivity was highly predictable as a function of number of tests and had a stronger correlation than the TDD group.

So TDD's relationship to quality is problematic at best.

…

Having a big clump in that upper left quadrant is troubling enough but then having the “Test Last” group almost double your “Test First” group in the over 90% quality range is something that should be noticed and highlighted.

While correlation doesn't equal causation, the lack of correlation pretty much requires a lack of causation.

Read the whole article for yourself, as well as the original report, and draw your own conclusions.

... that means it's probably a **good** idea.

http://blog.thepimp.net/index.php/post/2008/01/24/Say-NO-to-CLA-in-PHP

</snark> ;-)

This guyHasin Hayder has finally realized that there's no need for Smarty's template language any more (even after writing a book about Smarty).

Harry Fuecks and Brian Lozier made the same conclusion four years ago, and based on those articles, so did I. It turns out that Smarty tries to solve (mostly) the wrong problem

You may have heard that you need to keep your PHP and HTML separated, but that's not quite the case. Instead, what you need is to keep your "business logic" separate from your "presentation logic", and that's a different thing entirely.

Thus, all that's required is a way to keep your views and controllers separated, and perhaps provide helpers for common view tasks. Then you can use plain PHP in your view scripts (templates), without needing a whole new language.

That line of thinking led me to write Savant first in 2004 (and versions 2 and 3 later), along with its more-recent ideological descendants Zend_View and Solar_View. Even the Cake and Symfony guys got the point early on (and -- dare I say it? -- the Rails crowd as well with eRB templates).

It's so funny to see the comments in Hasin's article; all the same old tired arguments come up. Here's the deal: if you think you need to protect your business logic from your graphic designer, you don't have a technical problem, you have a hiring/management/training problem.

Update (2008-01-11): Apparently some readers thought "this guy" in the first paragraph meant me; changed it to "Hasin Hayder" to be more explicit. (I'm looking at you, Kimsal.)

The last time I wrote about Dirk Karkles, we learned that "do your best" is not a managerial plan of action.

Dirk Karkles thinks he can pay attention to more than one thing at a time. For example, he thinks he can write a report and carry on a phone conversation (or an IM/IRC session) at the same time. "I'm multi-tasking!" he says, sometimes with pride.

To this I say: There is no such thing as multi-tasking, there is only attention-switching.

You cannot perform two or more non-trivial tasks at the same time; at best, you pay attention to one and mostly ignore the other, then you switch your attention to the other and dismiss the first one temporarily, and then you switch your attention back to the first again. This is far less effective than completing the first task, then moving on to the second task, because of the time and mental effort it takes to switch between tasks.

Attention-switching is particularly bad when you are in real-time or near-real-time conversation. If you are doing other things while talking with someone else by voice or IM/IRC, you're telling the other person they are not worth your full attention. If they're not worth your attention, why are you worth theirs? ("I'm the boss" and "I'm paying them" and variations thereupon are not valid arguments -- try again.) You are wasting your time, and theirs, by not being a full participant in the conversation.

Now, there are times when you must give your attention to multiple tasks. Be aware that you are not multi-tasking, you are attention-switching, and take this into account when you switch your attention to another task. At the very least, you will need to take time to "catch up" on the task before you perform some new action related to it. For example, in an IM/IRC conversation that you are taking active part in, you will need to read and comprehend the backlog of messages before you you can even think about writing a meaningful response. Among other things, this means that attention-switching is not a net time saver, it is a net time spender -- but sometimes you have no other option.

So, the next time some tells you "I'm multi-tasking!" you know that person is not paying full attention to anything he's doing right then. Similarly, if you find yourself attention-switching in live conversation, have the common courtesy to excuse yourself and pick back up again later, when you can give it your full attention. "Multi-tasking" is something to apologize for, not to be proud of.

Quick note to say I'm moving my blog from Pair.com to my new WebFaction space. Layouts, etc. will be different until I copy over themes and other images.

Without having done actual research, and depending on my personal experience alone, I would assert that in PHP userland ...

• There are maybe 20 or more general-purpose CMSes.
• There are perhaps 50 or more public frameworks (of varying quality and approach).
• There are easily 100 or more templating libraries (even if most of them can be grouped under 4 or 5 approaches).
• There appear to be only 5 unit-test systems: PhpUnit, SimpleTest, Solar_Test, PHPT, and Lime.

Dispute the specific numbers all you like; they're not the point. The point is that CMSes, frameworks, template systems, etc. seem to be a very common artifact among PHP developers, but writing (and then publishing) unit-test systems does not seem anywhere near as common an obsession.

What does this say, if anything, about the attention given to unit-testing among PHP developers?

Note that this is an *off-the-cuff opinion* and a *request for comment*, and nothing else. (Some folks get testy about testing; please remember to be nice while commenting. ;-)

Update: And there are only 3 or 4 documentation systems: PhpDocumentor, Doxygen, and Solar_Docs, along with the various combinations of DocBook tools that Zend, PEAR, and PHP are using. I wonder how that enters into it, if at all.

Those of you who know me well, know that I am not much of a TV watcher. What little I do watch is boring to most normal people; by way of example, note that my 10-year-old 25" RCA tube has the C-SPAN logo burned into the bottom right corner.

So for me, this article feels like vindication:

How Dumping TV Allowed Me To Quit My Job...

Not that I'm rich by any means, but you get the point -- TV is usually a soporific time-waster. Watch less TV, get more "real" stuff done.

After more months of breaks, changes, additions, and refactoring, I'm (finallly) at the point where I'm ready to call the Solar framework for PHP 5 feature-complete. The first of this feature-complete series is the new Solar-1.0.0alpha1 release as of Sunday, 11 Nov, 2007. We now have at least 80% of everything you would need to build web-based and cli-based applications. This is a big milestone for the project.

The change notes, of course, are gigantically long, so they're on a separate page.

Read on for more highlights, especially about the new ORM system replacing the previous Solar_Sql_Table series.

Highlights

• The new Solar_Controller_Console and Solar_Controller_Command classes are analagous to front and page controllers, respectively, for the command line. This means you can build CLI commands in Solar much the same as you build web apps.

• The new Solar_Filter class combines validating and sanitizing. It uses a helper structure identical to Solar_View so you can add your own filter helper classes. It also comes with a filter-chain system for applying filters to arrays or structs of user input.

• We've moved a lot of the core functions of the Solar arch-class to their own static classes: Solar_File, Solar_Dir, and Solar_Registry.

• Lots of changes in the Solar_Sql package related to database portability. There are two removals here: we don't ship with Oracle or MS-SQL any more, only MySQL, PostgreSQL, and SQLite. These are not permanent removals; as soon as I can get systems to test on, I'll put Oracle and MS-SQL back in place with all the new SQL portability goodness.

New ORM System

The biggest set of changes, though, are that the venerable Solar_Sql_Table and its companions have been removed in favor of some new hotness: Solar_Sql_Model. The new model class is still table-based, but it now recognizes related tables using has-one, belongs-to, and has-many relationships. (Strictly speaking, we don't have "has-and-belongs-to-many"; we use "has-many-through" instead.) It features single-table inheritance, built-in filtering, automatic table creation, automatic form-processor generation, and lots of other goodies.

Along with the table-based model class, we also have Solar_Sql_Model_Record and Solar_Sql_Model_Collection classes to represent, respectively, individual records and collections of records. The record class allows you to add business logic on the individual rows and related rows returned by the model, so technically the record class is an ActiveRecord pattern implementation. (Note that this is not a Rails ActiveRecord.) Similarly, the collection class allows you to add logic on a set of records.

Oscar Merida has added a getting-started page about Solar_Sql_Model on the community wiki here: http://solarphp.org/wiki/tutorials/SettingUpModels.

Next Steps

The Model class is almost where I want it to be for a full stable release, but it still needs a bit of tweaking. Other than that, the only things left for Solar are building a more-complete suite of unit tests, and writing more narrative documentation. As the tests fill out and we get more user feedback, I'll be able to move to a beta, then quickly to an official stable release.

Many thanks to all the people who have helped with this release in one way or another (and in no particular order): Clay Loveless, Rodrigo Moraes, Antti Holvikari, Chris Cornutt, Jeff Surgeson, Robert Gonzalez, and all the others on the mailing lists and the IRC channel and who are noted in the change logs but whose names escape me now. Thanks guys!

I'm back from the Microsoft conference, and I'll do a short writeup on that later. In other news, I'm going to OmniTI world headquarters next week.

While I'm there I'll attend the DCPHP conference to give a presentation: framework and application benchmarking (Wed, 7 Nov, 10:30 am). Woohoo! :-)

UPDATE (2007-12-07): A PDF of the slides (for an earlier version) can be found here.

I'm spending today and tomorrow in Redmond, at the invitation of Microsoft, with a bunch of other movers-and-shakers in the PHP world. Microsoft says they want to get our feedback on their offerings, and find out how to better interoperate with PHP. This should be fun and interesting. :-)