It was a sign of status, a symbol that I was one of the heavies at the firm.

A former boss even strolled in, checked the room out, and said "wow, nice pad." Unsaid was that it was better than his.

Good, right?

No!

Offices put barriers -- real and imagined -- to communication with the rest of the department. In the just 5 days I've been in the isolation chamber called an office there have been a handful of incidents that just would not have happend had I been sitting on the floor. My favorite is when a colleague sent me an IM asking if he could come in and ask a question!

Feedburner founder Dick Costolo remarks why an open floor plan (without offices) is preferred. Agilists like their software team to be seated in a common area where people can comingle and communicate without barriers.

I wholeheartedly agree. I'm an Agilist, and will leave the office for the team area.

Tests marked as ignored are very useful: they remind you of work you need to do and allow you to check in work-in-progress without breaking the build.

The number of ignored tests is directly proportional to your code volatility. The greater the amount of work being done on your codebase the greater number of ignored tests are to be expected.

This implies that as you approach the end of your project ignroed tests should decrease. After the system is feature complete there should be very few ignored tests. Before going into production all tests should be enabled.

Long-Ignored Tests Are A Smell

Tests that have been ignored for more than a few days are a smell. Obsolete tests, unclear requirements, or just bad code hygene will lead to long-ignored tests.

To combat this I put the date on which I ignored the tests in the Ignore attribute and give precidence to those tests that have been left alone the longest.

[Test]
[Ignore("Garrett: 20 Dec. waiting for requirements on final file format")]
public void ValidateOutputFileFormat() ...

Too Many Ignored Tests Are A Smell

If a large refactoring or requirements change requires a huge number of tests to be ignored it is typically a sign of either two things: tests which test the implementation rather than the contract of a class (behavioral mocking is a big culprit here) or tests which are not fine-grained enough.

The most effective thing I've found, though, is leaving a broken test.

It's simple and effective if you're test-driving code. For example, let's say I'm writing a class that encapsulates whether a password meets a password policy. I'm hungry, tired and want to go home in time to go for a run:

[Test]
public void ValidPasswordMustHaveANumber()
{
    Password password = new Password( "PasswordWithNoNumber" );

    Assert.IsFalse( validator.IsValid( password ), "passwords without a number are invalid" );

}

When I come in the next morning I'll run the tests and see:
Assertion failed: passwords without a number are invalid.

Then I'll remember where I left the previous day.

“Please find attached the document that you requested…”

This phrase is verbose, passive, and imprecise. Strunk and White cringe every time it is used.

It is imprecise: Who attached the document? You? Me? The Document Fairy? The phrase doesn't convey the actor.

It is verbose: The alternative, “I’ve attached,” is shorter.

It is passive: It uses third person passive voice.

Don’t use this phrase. Replace it with the straightforward and concise “I’ve attached the document…” It should be included in chapter 5 of the next edition of Elements of Style.

The goal of any project team is delivering business functionality with high quality and low cost. The manner in which you achieve these goals varies depending on the people you have on the team, the company's management structure and style, and the project's goals.

Just because the team is pair programming, adaptively planning, and driving development with tests does not mean it will achieve the business goal. If the team is programming solo and doing big up front design it does not mean the team will fail.

I advocate Agile practices; they are generally a better way to get software written.

Too often, however, Agile zealots insist that their ideas on how a project should be run must be unquestionably followed. They disregard the client's wishes, processes and management style. They do not consider the team members' abilities and wishes.

These zealots end up damaging the project more than they help. They strain relationships with the client and are too quick to change project practices.

Remember, you must always ask yourself: is this practice I am suggesting going to allow us to deliver more business value faster, cheaper, and with better quality? If the answer is yes, then talk to your teammates about making the change.

If they aren't appropriate, don't advocate the practice just because "it is Agile."

During one series of talks with Microsoft, Facebook executives told their Microsoft peers they couldn't do an 8 a.m. conference call because the company's 22-year-old founder and chief executive, Harvard dropout Mark Zuckerberg, wouldn't be awake, says a person familiar with the talks. Microsoft executives were incredulous.

Mono is, succinctly, a solution that is searching for a commercial problem to solve.

The features that differentiate Mono from Microsoft .NET are being cross-platform, being free (as in beer), and being open. Java beats Mono handily in the first two categories. For the third, Java is open source but not free software. Few care about that distinction.

If an organization is looking for a cross-platform development environment they're going to go with Java. The tool set is more mature, language better supported, and the accompanying documentation far more extensive.

If a company wants .NET they'll use Microsoft's implementation. Microsoft has a 2-3 year lead in development. Mono is incomplete and buggy.

Both Java and .NET enjoy the support of large corporations, whereas Mono gets only ancillary support from Novell.

This leaves Mono as little more than a research project for developers. I'm sure many small organizations use Mono.
They probably selected Mono because the techie-in-chief thought it would be cool or as a anti-Microsoft gesture.

Indeed, Mono admits as much on its Web site:

Question: Aren't you just copying someone else's work?
Answer: We are interested in providing the best tools for programmers to develop applications for Free Operating Systems.

In the commercial world Mono would have been correctly abandoned a long time ago in favor of a product that actually serves an unmet need. In the open source world we have a solution to very few people's problems.

1. Is project progress measured by the delivery of working software?
2. Does the software have extensive automated unit test coverage?
3. Are there multiple integration builds per day that include compilation, unit testing, functional testing and deployment steps?
4. Is there a high degree of direct involvement by the business during the development process?
5. Is the development effort driven by acceptance tests?
6. Do developers spend most of their time collaborating?
7. Are planning, analysis, architecture, development, and QA all performed continuously?
8. Is there a recently built running system available at all times?
9. Is development work delivered in fine-grained units of no more than one month?

An agile project should answer "yes" to almost every question.

Thanks to Derek Walsh and the Australian ThoughtWorkers for the questions; I've edited their original version.

Valuation of many things: homes, companies, even things as simple as jewelry, is difficult. It can be summarized in one simple axiom, though: something is worth exactly what someone else is willing to pay. It's isn't worth any more.

If you can't find a buyer for something at its appraised value then that appraised value is wrong.

So -- to pick on a random blog -- RandomURL is listed as being worth $20,888. Is it really worth 21 grand?

Probably not. Someone would have to be willing to part with a new car's worth of cash for this valuation to be accurate.

The research behind the blog valuation is based on the $25 million purchase of Weblogs, Inc., and appears to extrapolate down based on links within blogs.

The best appraisals are based on comparable sales. In real estate, for example, if you can find a house similar to yours its recent sale price is a good estimate of your home. Restated generally, two parties just exchanged something very similar to yours. You can probably find a buyer for a similar price. (The new site Zillow will value your home using this method.)

In this case, the study's author is comparing a $25 million sale of a corporation with a (usually) one-man Web site whose actual worth is on the order of, at best, thousands of dollars. The values are widely divergent and the two entities are different. It means the study is fatally flawed.

A better appraisal would be based on someone's one-man blog being bought for cash. Does anyone know of such a transaction? If you do, post a comment or email me.

Finally, it's very difficult to transfer the value of a blog because a blog's worth is dependent on the author's ability to continue to attract an audience. If the site is sold, why would the author continue to write? They no longer own the site. If a blog author wanted to get cash from their site they would be best off advertising.

Michael Jordan had just been drafted into the NBA; everyone knew he would be a big player. He had signed a shoe endorsement contract with Nike.

Strom Thurmond, the deeply reactionary Senator from South Carolina was up for reelection. Jordan grew up and went to school in neighboring North Carolina.

A reporter asked Jordan why he didn't use his fame and speak out for Thurmond's opponent, whose politics were more in line with Jordan's. Mike replied:

"Republicans buy shoes too."

He didn't want to lose fans because of his taking controversial issues public.

The moral of the story is that you alienate customers by expressing partisan sentiment versus being demure.

I'm not sure why. I suspect it is because that XML is standardized and because of the prevalent attitude that all things with a W3C standard are good.

However, there are many times XML is selected to represent data or (worse) behavior where that selection is a poor decision. The best examples of this mistake are programming languages that are XML: Ant, NAnt, XSLT, and VoiceXML, for a few.

XML is verbose and puts awkward constraints on syntax. The strained syntax in VoiceXML is an illustration. Writing VoiceXML -- something I've spent much time doing -- is tedious and error prone. If you want a simple if/then/else construct, you need to type <if> … <elseif /> ... <else /> ... </if>. The result looks more like hieroglyphics than readable code.

The VoiceXML creators could have delivered all the same features by just making it an extension of an existing language. Developers wouldn’t have to learn a new syntax and wouldn’t give themselves Carpal Tunnel syndrome from typing all those <, >, and / characters.

Another particularly odious example is passing complex data structures as method parameters. I've now run into several organizations that have as a corporate standard architecture that you create an XML document to pass to another logical layer.

I'm not talking about using Web Services or passing data across process boundaries -- I'm talking about passing, say, three strings in an XML document -– doSomething( Document document ) -- rather than declaring a method doSomething( string foo, string bar, string baz ). Onyx's CRM platform uses this antipattern as their integration framework.

This is such a bad idea I don't know where to start. For one, when you encode things in XML, you lose type. You need to write logic that encodes your parameters in XML and then more to unencode the parameters from within the target method. The extra statements obscure your code.

All this for no benefit that I can percieve.

XML is chosen for two main reasons, one good and one dubious.

The first reason -- and a good one -- is that there are numerous stable XML parsers. Free, readily available tool support is a good reason to select a technology, but it doesn't override all other concerns.

The dubious reason people select XML is because it is standard and allegedly non-proprietary. XML is so weakly typed and amorphous that its ultimate definition is proprietary. Microsoft Visio saves diagrams to XML, but that specific format is proprietary. It is solely owned and controlled by Microsoft.

To sum things up, here are some general rules on when and when not to use XML:

• If you're representing logical statements -- a programming language -- never use XML.
• If you need only simple, non-hierarchical data representation, don't use XML.
• If you need complex data represented externally to your program (to a human or another unrelated system), consider XML. If you do select XML, unit test the logic that persists and retrieves it well.
• If you need complex data represented only internally to your system, bias your decision away from XML. In Java and .NET, for example, you can binary serialize your object graph. Performance is better and you don’t have to write as much code.
• Finally, if you're looking at some other application I haven't mentioned above, carefully consider the pros and cons of using XML. In general, the positives of XML are too strongly weighted and the negatives overlooked.

A strong signal in that noise is Intentional Software's blog, which contains items by Charles Simonyi and his colleagues on computer science. Simonyi is the former Microsoft Chief Architect, a title which Bill Gates now holds.

The blog is insightful, well written, and delightfully low traffic.

Credit goes to Jonathan Rasmusson.

"A village in Texas is missing it's idiot."

Is it asking too much to use correct spelling and grammar when calling someone else an idiot?

There are many manifestations of this bias, but none more aggravating to me than to whom the credit for Ajax goes. For example, in Lee Gomes' much discussed Wall Street Journal article on programming languages, he says:

"Both Ruby on Rails and Ajax were developed by small software-consulting companies eager to let the world know about their skills."

This is simply wrong about Ajax.

There is also this quotation from Mitchell Baker, the Mozilla chief, in The Economist. The context of the statment is Firefox's contribution to Ajax innovation.

"Web 2.0 could have happneded a lot earlier, if Microsoft had not had a monopoly for a decade."

What chutzpah!

Microsoft invented Ajax in 1999. It just took the rest of the software world 6 years to catch up. I've developed a brief timeline at the end of this post.

The two key technologies for Ajax – the ability to modify HTML on the client side and the ability to initiate and capture an asynchronous HTTP request – were introduced in Internet Explorer in 1997 and 1999, respectively. Outlook Web Access was the first product that I know of to use both heavily.

It took about 5 years for Safari 1.2 and 6 years for Opera 8 to implement XMLHttpRequest or a XMLHttpRequest-like API. Firefox didn't have a production release until 2002.

Once the non-IE browsers caught up developers could now use asynchronous requests to spruce up their Web apps and still have it work in multiple browsers. Ajax development became more affordable, and, therefore, more popular. Prominent and very well-designed sites like Google Maps and GMail made users and developers aware of what is possible.

Finally -- 6 years later -- Jesse James Garrett of Adaptive Path coined a catchy phrase: the term Ajax was born.

Ajax is popular now because using asynchronous requests in Web apps is affordable and well-known sites use it. Libraries like Prototype smooth over the browser-specific API wrinkles even further to make life easier.

Make no bones about it: the fundamental innovation behind Ajax was created by Microsoft. Let’s give credit where credit is due.

Ajax Timeline:

• 1997 – IE 4.0 introduces ability to modify the UI via the DOM and client-side script


• 1998, 2000, and 2004 – W3C releases or updates standards on the DOM


• 1999 – Internet Explorer includes XMLHttpRequest


• 2002 – First production Firefox release


• 2004 – Safari 1.2 released with XMLHttpRequest support.


• 2004 – Google Maps, GMail, and other popular Web apps demonstrate great UI design with AJAX


• 2005 – Opera 8 released with XMLHttpRequest support


• 2005 – Adaptive Path coins the term AJAX and makes it popular

Sources: Wikipedia, Adaptive Path, MSDN