Pinderkent

It's a mistake to think that unit testing is only about preventing bugs. As such, it's also a mistake to measure the usefulness of writing unit tests in terms of the number of bugs found. Unit tests are a preventative measure, both when initially writing a piece of code for the first time, and for ensuring that future changes have not broken it in some way.

Of course, I'm not the first to point this out. But it's unfortunately a concept that is missed by many in the software development field. Many such developers have difficulty thinking about the "intangible" aspects of automated unit tests. All they're immediately aware of is the time and effort it took to implement the unit tests. But they don't realize how the act of developing the unit tests made them consider to a greater extent how their unit of code would eventually be used. In proper test-driven development, the developers would get a better sense of how their unit's API should be structured. If they're good developers, they would also have put more consideration into how corner cases would be handled. And once their unit tests are implemented, the ability to run them continuously against a changing code base becomes invaluable, especially when regressions are caught rapidly.

Such developers can easily track the number of hours it took them to write the unit tests. They can easily track the number of lines of code making up those tests. But it's harder to quantify the greater familiarity and greater understanding they gain regarding the unit under test. It's also difficult to quantify the time and expense saved by catching regressions as early as possible, often within seconds of some new or modified code being committed to the source code repository. And then there's the software developer's reputation, be that developer an individual or a large company, which can be greatly improved by providing software that is generally bug free.

Often, the benefit brought by the more intangible and abstract aspects of unit testing far outweigh whatever time and effort is put into developing the unit tests initially. Remember, if a unit test that took a few minutes to write catches even one regression, the savings can be enormous. Many times in the past I've seen days upon days of effort, in terms of debugging, patch preparation, patch testing, patch deployment and customer appeasement, needed to fix a bug that could have easily been caught with three or four assertions and perhaps eight to ten lines of unit test code.

Ron Garret's recent publication of his "Why CSS should not be used for layout" article has resulted in there being much discussion about whether CSS or HTML tables should be used for Web page layout.

This post isn't going to argue in favor of one or the other technique. It'll just link to some of the more prominent articles written recently. But if we do try to draw a conclusion from all of this discussion, it would have to be that as is often the case in the computing world, that there is not a single technique that is sufficient for all users.

Thanks to this blog post by Peter Harkins, I was alerted to Michael Meeks' analysis of the recent progress of OpenOffice.org. Both articles bring up some interesting points. Meeks provides various measures of activity relating to the development of OpenOffice.org. While software metrics are often suspect, he uses practical measures such the number and affiliation of contributors, lines of committed code, and so forth. His conclusions suggest that OO.o is "stagnating".

Meeks appears to put a lot of blame on the processes the developers must cope with, as well as the involvement of Sun. Harkins further suggests that the nature of the project doesn't itself towards generating an active developer community.

They're both correct. Unlike many other open source projects, OO.o never really felt open to community involvement. It originated as a commercial development, it was open sourced by one of the largest software and hardware providers, and has been developed using resources and people from a variety of companies. It fell onto the open source community, rather than growing forth from it.

OO.o isn't the only such project to have been in this position. The Mozilla project is similar in many respects. Like OO.o, the initial software was a commercially-developed, closed source product that was eventually open sourced. Netscape and AOL were quite involved with its initial development. And for the first five years or so, we saw stagnation. There were usable releases put forth, but they weren't truly innovative or inspiring.

Things started to change once Phoenix, now known as Firefox, was released. We saw innovation. We saw a more useful piece of software emerging. And best of all, it was a community effort. As such, a healthy developer and user community formed. Since then, we have seen it become a very prominent and widely-used Web browser. The original Mozilla Suite has taken a back seat to Firefox and the Thunderbird email client.

Something similar might be what the OO.o community needs. Namely, an effort from the community itself that aims to tackle many of the problems of OO.o. In a sense, it'd be the OO.o community competing with itself. The best parts of OO.o would be used, while the software develops into a product that satisfies the needs of the users better than OO.o currently does. There would be less focus on competing with other commercial office suites, and instead a focus on providing, for instance, a word processor that best meets the needs of its developers and users.

OO.o might also want to take another page from Firefox, and become more of a host for plugins. It provides the basic functionality of a word process or a spreadsheet application, for instance, but it's the plugins that really make it suitable for a given user. So instead of getting an awkward, poor-performing and memory-intensive integrated jumble of functionality, 95% of which is unused by most users, they would instead get a leaner application where they use the vast majority of the functionality it offers, and use a few plugins here and there to really tailor it to their needs.

Are we likely to see this happen? It's somewhat doubtful. I'm not sure if the open source community really needs an office suite as badly as, for example, Firefox was needed. For instance, many developers I know will just use plaintext files, HTML or LaTeX when they need to create a document. But if the OO.o project were to stagnate further, perhaps that would actually help generate the grassroots initiative needed for OO.o to experience its own Firefox-style revitalization.

Users of of dynamic languages such as Python, Perl and PHP, are often faced with the additional task of ensuring that type-related errors do not occur in their programs at runtime. Some authors [1, 2] claim that this can be done effectively by the use of extensive automated unit tests. However, practice has shown this to just not be the case.

Automated unit tests have their place. But they should not be used to check for typing errors. Software typechecking is a mechanical task, and thus is just the sort of thing that should be delegated to a computer. And this has been done for quite some time now, in the form of statically typed programming languages. Users of such languages, such as Haskell, OCaml and Standard ML are freed from having to worry about such menial and tedious tasks. The rigorous nature of the compilers for those languages often do a far better job at checking for type errors than a human typically could.

Proponents of dynamic languages often suggest that such languages bring an increase in developer productivity. But if the developer ends up spending so much time writing unit tests to perform a task that is readily done automatically, we really don't see the supposed productivity boost. And if the developer doesn't write such unit tests, the chances of a runtime type error crashing the application are far greater. So now the developer must choose between his or her software crashing and disrupting the users' work, or spending a lot of time to write unit tests. None of the choices are reasonable, let alone optimal.

Static typing is clearly the answer. Not only does the compiler take care of the tedious task of type checking, but any inconsistencies are detected at compile-time, rather than runtime. Thus it is the developer who deals with such errors, rather than the user. Furthermore, the developer is now freed up from writing automated unit tests to check for type errors, and can instead put more emphasis on unit testing the functionality and integration of his or her code. Clearly, static typing is the only sensible, and the most efficient, route to take.

Thanks to the Agile Ajax blog, I've learned about Remember The Milk. Essentially, it's an online service for managing a to-do list. It apparently integrates with a variety of other services, including Gmail, ICQ, MSN, Skype, AIM, and more. It claims to also allow for task lists to be published and shared with others.

I have to say, it looks like a major over-complication of what should be a relatively simple thing to keep track of. Over the years I've worked with many managers and co-workers who've deemed it necessary to use some little digital doodad to manage their tasks and time. And I don't think I've ever seen such devices prove to be useful. If anything, they've more often than not been a hindrance to getting things done.

Even getting information into the things seems to be a challenge. Some I've seen have used a stylus. But those often require you to learn a new writing style that the device can interpet. Others have an on-screen keyboard, where you poke the keys with the stylus. Yet other devices have small keyboards built in. And I've seen other devices that come with separate, nearly full-sized keyboards that can fold up. Nevertheless, none of those methods ends up being very efficient.

Of course, then there's also a need to power these devices. Some use normal AAA batteries. Others have specialized power cells. And others need to be charged using some sort of an adapter. The power sources of these devices always seem to run out at the most inopportune time. Trying to get your to-do list off of one of these devices when it's unpowered is pretty much futile!

What I tend to see happen is that these people end up spending a huge amount of time with these devices. They struggle to input data. They struggle to find the data they've inputted. It ends up being a situation of task over-management. What was supposed to make their lives more organized, and thus increase their productivity, has instead rendered them useless for a greater portion of the day.

Most of the successful people I've worked with have just written stuff down on paper. They carry a pen or pencil with them, and each day they fold up a new sheet of paper, and put it in their pocket. Others have used a tiny organizer booklet that contains a calendar and contact list. Along with the wristwatch they typically wear, they're all set to manage their time wisely and effectively.

If something comes up that requires their attention, they write down a brief note. If they have an appointment, they write down the time. These people tend to check their watches often, and have more than a one-second memory, so missing an appointment is rarely a problem. Best of all, these papers can be filed quite easily, for future reference. There's no digging around on some device for old records that often end up deleted by accident, or trying to synchronize it with a PC somewhere.

So while the idea of Remember The Milk may seem novel, I really don't see how it's that beneficial. A pencil, a piece of paper and a wristwatch render it nearly useless. While somebody is still sitting there inputting their reminder note one keypress at a time on a handheld device, the person with the paper and pen has written down his or her note, and has moved on to doing something useful.