Yes, writing tests up front is time-consuming and not directly contributory to the final code. But writing the tests is like filling your auto’s tank with gas before starting a long trip. It will save you from the frequent stops you’ll have to take without it.

If you’re using a compiler, you’re likely already using automated testing as they perform static type checking. You have to declare the variable before using it, along with its type specifier. You have to use casts for parameters and assignments when the types don’t conform to the prototypes.

You’re content, for the most part, to use static types in your code because they eliminate an entire class of defects and reduce time you’d have to spend debugging for them.

Unit Tests and Assertions
Don’t use just unit tests to verify the production code works as expected, but also assertions within the production code to verify parameters and environment meet assumptions.

What to test
Interface - can be part of TDD
Parameters
Errors
Results

There are so many excellent items from Mark Mayerson’s site. The ones I’m passing along here are of interest to microISVs and other entrepreneur types, but I recommend you just subscribe because they’re all noteworthy.

Paraphrasing the first item, the heads of large media companies can’t tell what audiences want. So they produce all this content and then try marketing gimmicks and special effects to ram it down your throat.

Here’s the kicker:

They’re stuck having to guess what creative properties will attract that audience. If you can attract your own audience, you’ve beaten the system.

The point for entrepreneurs is not to follow the examples of the big guys, trying to sell another spreadsheet or social networking site, but to sell your own story. Then you won’t need to use pricing, or coupons or marketing gimmicks to win customers.

The last link to Mark’s site I plan to post for a while is a pointer to some really good specific marketing ideas from a guy named Scott Kirsner. Boiling it down, the principles behind his action plans are develop for niche markets and be part of the community you’re marketing to (and market to the community you’re part of).

Mark Mayerson points to a great marketing piece which he argues should be applied to animation studios. But since the strategy is for large companies to create brands to give the impression of being smaller, it is even more likely that niche brands applies to microISVs, which are already small, as well.

Supporting the small, independent craftsman has always been a core value of society. Well, it became a social value after the advent of the Industrial Age because there was no alternative to independent craftsmen beforehand. And now globalization and fears of the rising power of multinational corporations deepen the sense of helplessness when dealing with large, bureaucratic companies. These feelings, combined with idealized, romantic notions of supporting indies, lead buyers to prefer the intimacy inherent in patronizing the little guy.

It’s an important, albeit subtle, reason why the Mac is gaining marketshare, and it can be an important leverage in marketing your products. Combining Long Tail product development (lots of niche products and brands) with the social epidemic of network economies (AKA The Tipping Point) can help independents prosper and remain so.

[Update - 2007/04/19] I found Chris Anderson had written a couple of Long Tail entries regarding software before. They and the comments and trackbacks they contain are a great reminder of the importance of product differentiation and mean a lot more work for the microISV to exploit the advantages being opened up to us.

I found this blog posting through Mark Mayerson’s site.

It applies to any media, whether a blog or Internet site and larger media outlets such as television or magazines, in addition to newspapers.

Know the writer’s outlet and market interest. If it’s an interview, prepare the bios and other info they can incorporate into their article. If it’s a product review, incorporate some background info on your company, the product and the market niche. If it’s a business article, write a list of ways they can save money, make more sales, make people happy or whatever the writer’s audience needs to do to achieve success.

Simplify the writer’s job to where the article “writes itself.” Sadly, that means you’ll have to do most of the writing, but that way you’re more likely to get the press you’re looking for.

Measurements are an integral part of the testing process. In manufacturing processes, they provide an indication of how the final product will turn out. If the temperature is too high, resins will become too fragile. If raw materials are left in the open air too long, the loaves of bread won’t have the right texture.

Note the variation that was acceptable at the most commercially successful, and highest quality, studio at the time. And yet they still measured raw output. Other studios enforced a more inflexible production quota (bean counters!), and their work suffered as a result.

Measurement is an indirect means of testing the velocity and quality of a process, and is as valid for software development as it is for animation.

Ian Baird posted an interesting link in the #macsb channel last night. The author asks why we don’t make use of simulators and design tools when writing software.

There are several reasons why.

Programmers don’t want to change the way they work.
Mythical super-programmer. Cowboy. Lone wolf. We tend to adopt the hubris of our heroes even though we haven’t attained their level of achievement.

Major is Minor. Programmers don’t design software in an architectural sense. There is no grand scheme, no big wall of interaction diagrams used to document how classes and objects interact. We tend to design on a bottom-up basis. The design is embodied in the text we write. The documentation is the code.

Minor is Major. Programmers like to focus in discrete units of code we can parse at once. The smaller the unit we can interact with at once, the smaller the unit of code we write. Functions, or modules, have been shrinking as we’ve moved from punch-cards and printouts to TTYs to GUIs. It isn’t just that we’ve learned that reducing function size and behavior improves comprehension. The fact is the reduced visual workspace requires us to improve code comprehension!

Code operates linearly, or sub-linearly if you compact several statements onto a line or make abundant use of ternary operators. Programmers love to do that because it’s detailed. We love cute little tricks like obfuscation because they’re details. But it isn’t readable, and it isn’t professional.

Programmers are the detail-oriented, step-by-step kinda guys whose focus is on the specifics. We hate ambiguity. We have to understand things before we’ll do anything. This is why any design document on a system’s organization quickly degenerates into the use of linked-lists or DB schema or some such implementation details irrelevant during the planning stage. It’s why programmers argue incessantly over trivial issues and attempt to refute assertions with minutiae. It’s also why debugging involves figuring out the why one part of the system clobbers another: we forget the details of other pieces and how they interact.

This is the main reason why different languages rise to prominence over time: each offers a new level of detail the prior language did not. It introduces some abstraction, paradigm or need that is unmet in the old language and its repertoire of code.

Programmers are afraid to change the way they work.
We already have UML and Nassi-Schneider diagrams and flowcharts. Some programmers might draw one up for a quick back-of-the-envelope idea of how to get the function to work, but they’re not an integral part of the development process. The documentation isn’t kept around. The writing tools used by programmers is little better than the tools used by other writers of fiction. Look at the markings on a printout of code and you’ll realize there’s been little changed from the techniques used from before the time of Shakespeare. Why is this?

Programmers can’t change the way they work.
It’s because programmers are literally oriented. Both literally and figuratively. As our tools are text-based, the persons attracted to the profession are people who think literally, and not visually.

As much as programmers have changed the way other professionals work, there’s been little acceptance for the transformation of our own industry. Text-oriented tools attract text-oriented people who write more text-oriented tools and keep the cycle repeating.

All that is necessary for the triumph of evil is that good men do nothing. — Edmund Burke

Abandoning the blogosphere because of the presence of bullies and criminals only serves to satisfy and embolden them.

Pain is the deterrent to repeated offenses. Whether it’s emotional or physical, the effect of swift and proper punishment is to reduce the likelihood of the offender to carry out unwanted behavior such as this in the future.

But once the punishment has been dealt, drop the issue. Bullying the bullies will, in the long run, serve to justify their actions in their minds and aggravate their behavior.

Just remain vigilant against this behavior in the future and punish again if the individuals continue these despicable actions.

I read about Der Fuehrer’s Face when I was younger.

Later, in high-school, one of my teachers had old radio programs on cassette and I got into Spike Jones . One of his tunes was called Der Fuehrer’s Face that I found hilarious.

Today I found the connection. Wow.

A Tipping Point is a pattern observed in nature in which some property or object slowly grows or is propagated among a population until it reaches some critical point or vector, after which its growth rate experiences a sudden rapid increase within the population.

It must be noted that the Tipping Point isn’t something that exists, but is a phenomena observed in some system as a result of a simple change, or compound changes, in the system.

For the TP phenomena to occur four elements must be present: 1. Some signal, force or influence to be transmitted. This signal may be a virus, an idea, or any creature of nature. 2. Some population or system of connected nodes in which the signal is propogated. 3. Some means of reproducing or propagating signals among the members of the population. 4. A force or effect which inhibits the reproduction of the signal or removes it from members of the population.

Your message, the signal you want to be copied throughout the network, must resonate in some way with a member of the population for it to be repeated to other members. The better tuned it is, the more likely it is to propagated, and even amplified. Often the original message gets distorted, filtered, reshaped, or altered in some other way when passing from one member to another. The change may be what is needed for the essence of the message to find ready adoption throughout the population, both being easier to replicate and circumventing the signal inhibitors in the system.

Sometimes, it isn’t a change in the signal which has the impact, but external factors: temperature changes, prices of commodities, international events that alter the importance of certain signals over others.

When you develop your marketing message, keep these four elements in mind. Test that your message is tuned to your market, is easily propagated and isn’t negatively distorted by the current state of the system.

I said it.

The sacred ritual of XPers is a relic and an obstacle to improving a team’s agility.

By way of explanation, let’s examine the definition of pair programming and its application.

In the first edition of Extreme Programming Explained, Kent Beck, gave this definition for pair programming:

A programming technique where two people program with one keyboard, one mouse, and one monitor. In XP the pairs typically change a couple of times a day.

(It used to be preached by the XP true believer that the pair must be physically present in the same location with one keyboard and one monitor to be effective, but this is no longer considered sacrosanct.)

The People, Projects and Patterns wiki gives an elaborated definition:

An ExtremeProgrammingPractice in which two engineers participate in one development effort at one workstation. Each member performs the action the other is not currently doing: While one types in UnitTests the other thinks about the class that will satisfy the test, for example. A single, unsubstantiated, unscientific, undergraduate’s survey has shown that, after training for the “PeopleSkills” involved, two programmers are more than twice as productive as one for a given task.

In this practice, the programmer operating the keyboard is often called the “driver” while the programmer considering a larger context for the code is “navigating” (as someone who follows maps and charts).

The key value-add of pair programming for agile development is communication: the ability for both programmers to share skills, domain- and system-knowledge and receive immediate feedback on the direction of their work. The state of the system is advanced as the skills and knowledge of the pair are raised.

All is Not Rosy in the Land of XP
Let’s examine the speed barrier posed by having both programmers being mindful of the development effort they’ve been assigned. As one programmer is driving the other is navigating, focusing on the code within the context of a greater part of the system. If he’s thinking about the bigger picture he isn’t focused on reviewing the keystroke-by-keystroke typing of his partner. So how often must he take the time to review the code written by his partner? Every other second? Every minute? Every half hour?

Sometimes, “Trust me.” is a suitable non-maskable interrupt, effective for a few minutes of coding while the navigator doesn’t know what’s being done. Those few minutes should be hours and days of which that programmer should drive his own stories and trust the tests and reviews and the training the other programmer has and the process itself will keep itself defective code in check.

Why Pair Programming Slows You Down

More People Requires More Communication
The fact you have at least one pair of programmers means they’re going to have to communicate. This is the key problem pair programming solves, but this method of communication is the bottleneck to doing it well. Since they don’t communicate via documentation, they’re going to have to sit in on each other’s work time. This adds some overhead of communication time to the work time.

Interruptions Hamper Productivity
When you are focused on one task, certain details are of more importance than others. As your mind ignores the details which aren’t essential to the primary objective you begin to function in the “flow” or “zone”. If you have to perform a mental context-switch to focus on the details of something other than your primary objective you can lose the intensity of that flow. This becomes far more frequent when paired with someone who is focusing on another aspect of the code or system.

Entropy and the Law of Diminishing Returns
As team members become more acquainted with the workings of the system, there is greater overlap of skills and knowledge and less insight to be gained from working on one development effort. This results in less productive use of each programmers’ time. It would be better to have each programmer work on different stories or different tasks for a given story.

Limited Scalability
With pair programming’s emphasis on communication, it readily becomes apparent that information will be slow to disseminate throughout a project when limited primarily to this practice. In addition, the more ambitious a project is, the less an organization is able to operate in an agile manner when constrained by pair programming. No matter how many experienced XPers you throw at a project, when you’re required to divvy them up into pairs you’ve locked your programmers into limited gains. Two is the bottleneck for communication and productivity gains rather than five or eight.

Insecurities, Arrogance and Disrespect Breed Competitive Friction
An antagonistic partner will undermine the effectiveness of what should be a cooperative endeavor. However, this point should only be considered a temporary issue for teams which are adapting to agile practices, or for members who should be considered temporary team members.

So Pair Programming is Evil?

Definitely not! It is a practice used by many fields, including software development, with great success. It should be common in every team as it has distinctive benefits for every development effort. In fact, XP uses pairing on occasions other than just for coding. A programmer will pair with a customer when writing stories. And a customer will pair with a tester to write acceptance tests. But pairing has limitations in benefits and effectiveness.

Pair programming is most effective:

• When the skills of both programmers are slightly to moderately dissimilar.
• When knowledge of the system between the two programmers is highly dissimilar.
• When the story being coded hasn’t already been scripted, (i.e., the pair is designing on the fly).
• When the team isn’t agile enough to break down assignments by functionality (e.g., test cases, coding, reviews).

Given that there are times when pair programming is effective, and times when it isn’t, it should seem reasonable to most to pair when it is more effective than programming alone, and not to when it isn’t. Because the key to agile development is being that: agile. The problem is when you fail to exercise common sense when using any practice, even ones enshrined in holy scriptures.

With whom should you pair? How often should you pair? and how long should a pairing session be?

“Begin at the beginning”, the King said, gravely, “and go till you come to the end; then stop. ”
— Lewis Carroll