Could You Pass 8th Grade Math?

You Passed 8th Grade Math

Congratulations, you got 10/10 correct!

Could You Pass 8th Grade Math?

Planarity.net

A way cool game that tests your facility with spacial relationships:

Planarity.net

Are iterations hazardous to your project?

Are iterations hazardous to your project?: "That surprise experience helped open my eyes to why 'iterations' may be hazardous to your project: Danger grows when the results of the iteration are not directly linked to delivering the product to the end user. Without that linkage, iteration results hang in the air just as badly as the old, pre-agile forms of wandering in the wilderness."

This could be filed under the general heading of "Don't let the process become the goal," which is a disease that strikes nearly every organization.

Here is how it happens:

Management wants feedback that the team is making progress towards a particular goal, so they add instrumentation to the process to gather metrics. The team responds by trying to improve those metrics. If management chooses the wrong metrics, the end effect is that they drive the team away from its goals, rather than towards them.

I think that all of Alistair's observations and recommendations are dead-on.

Laziness Driven Design

I have become fanatical about writing unit tests for every method on every class, regardless of how trivial that method first appears. ( "But it's just a getter!" )

This leads to an interesting laziness driven feedback loop. Here's what happens:

I am implementing a feature, and think that the shortest distance between two points, is to add another dependency onto one of my classes, but then I realize that this new dependency would further complicate all of my tests, requiring large changes. Ugh! I don't have time for sweeping changes to my test suite.

So, in my laziness, I skip over the initial, obvious solution, think a little bit harder, and come up with a truly simpler solution.

The PO-STAR Movement

In the past year, I have seen an increasing number of "Plain Old *" abbreviations:

• POJO - Plain Old Java Objects
• POCO - Plain Old CLR (.NET runtime) Objects
• POX - Plain Old XML

At this point, I think it qualifies as a crypto-movement, and the clue to the genesis of this movement is in Andy Smith's "Why Frameworks Suck."

Frameworks hurt sharing. I’d really like to give you this fork Jimmy, but you’re gonna need a knife and plate to use it.

The alternative to PO* is to buy into some framework, which inevitably prevents code reuse as your classes become riddled with framework junk.

You know a library is really a framework when:

• It requires you to derive your classes from some library class.
• It requires you to use their main() function.
• It requires you to use their Application class.
• It requires your classes to depend on some third party library.
• The setup() and teardown() methods of your test suites become really complex.

Nearly every time that I have written framework-like functionality into an application, I have found that I was able to factor it out in favor of simple library classes that are themselves PO* objects.

I Heart Python

I have been playing around with Python at home, developing a simple web application, and I just wanted to say that I think that Python is awesome.

Fear of the Domain Model

Did you ever notice that many programmer's tend to shy away from developing a domain model?

This is a pretty reasonable reaction. We want to exploit our strengths, and leave the domain to the domain experts. We want to continue to improve our knowledge of computer technology, because this translates into a personal asset.

I think that the ability to elicit domain knowledge from a domain expert and convert this into a viable domain model is a more important skill than the knowing the latest technology that your tools vendor is trying to push at your CIO.

A rich domain model is truly fertile ground for developing applications, and building working, valuable applications is way more important than extending one's knowledge of the solution domain.

The Garden

Originally uploaded by Jennifer Dunne.

This is picture of a flower in my wife's garden.

Thoughtless Interfaces

Here is a great write-up on how to not create an interface: IFoo as Foo's interface is evil and should be punished.

It's all about responsibilities, people!

Toothpaste

Originally uploaded by Jennifer Dunne.

My wife took these wonderful pictures of toothpaste, which had quietly extruded itself from the tube in the middle of the night.

Trust is an essential deliverable

From Exploration Through Example:

Sometimes teams are jumping into Agile to avoid the horror of the previous release. The code was too buggy, or too late, or cost too much per feature, or all three. In such a case, the programmer team is probably not trusted by the business people. If so, trust is an essential deliverable. It's not enough to be better; you have to be visibly better soon. Delivering tested, working features at frequent intervals is a key way to get trust back. Another way is close cooperation with a product owner that demonstrates that the team's orientation is toward helping her meet her goals. But more generally, the team should pay active attention to how well they're doing at building trust, not just at building code.

A Perfect Recipe for a SOA Failure

From SOA is a Business-Driven Architectural Style:

"It means that for SOA to be successful, it must be a 'top-down' approach. And top-down, means problem to architecture to solution. It does not mean, working from what we have and just wrapping it with new technologies just because we can. This bottom-up approach is quite natural and easy and is the perfect recipe for a SOA failure. "

I will go a bit further and say that any architecture that isn't bent on solving a particular problem is a recipe for failure.

Searching Google for Books

I had heard about Google Print a while back.

I hadn't realized that the Google Library project would mean that public domain books, like Huckleberry Finn, would now be searchable via Google.

You just enter "book" followed by the book title in Google.

Yahoo has acquired Flickr

Thoughts on Flickr and Yahoo (by Jeremy Zawodny)

I hope they don't mess it up. :-)

Being Careful Is Not The Solution

Sometimes, when you touch a piece of code, or a build script, or a configuration file, you might feel the urge to be very careful, because your change might break the overnight build, or result in a subtle bug.

Being careful is not the solution. You cannot be careful all the time. Sooner or later, you will let you guard down and make a mistake. It is inevitable. If you are lucky, this mistake will occur when you have loads of time to diagnose it. If you are unlucky, you'll get a bad build at the 11th hour.

When you find that you need to be careful, you should ask yourself, how can I change this situation so that mistakes are either impossible to make or discovered immediately after making them?

If you think about it, you probably already know a few strategies for achieving this right now:

• Unit tests insure that your classes behave as you expect them to.
• Asserts (Design by Contract) achieve the same thing from a different direction.
• Code generation eliminates duplication, so that you only have to make a change in one place.
• Static type checking catches mistakes at compile time.

Jellyfish

Jellyfish
Originally uploaded by JohnDunne.

This is a jellyfish that we saw while poking around the aquarium at the Mandalay Bay hotel in Las Vegas.

Tips for Google Maps

Some neat tips from Mike Clark

Need Driven Development

In "Mock Roles, Not Objects" [1], Freeman, Pryce, Mackinnon, and Walnes say:

A core principle of Lean Development is that value should be pulled into existence from demand, rather than pushed from implementation: The effect of ‘pull’ is that production is not based on forecast; commitment is delayed until demand is present to indicate what the customer really wants.

This is the flow of programming with Mock Objects. By testing an object in isolation, the programmer is forced to consider an object’s interactions with its collaborators in the abstract, possibly before those collaborators exist. TDD with Mock Objects guides interface design by the services that an object requires, not just those it provides. This process results in a system of narrow interfaces each of which defines a role in an interaction between objects, rather than wide interfaces that describe all the features provided by a class. We call this approach Need-Driven Development.

I recently experienced the opposite of this approach. I had done some initial design, and come up with a list of classes and their responsibilities. I picked the most important class and started implementing it.

So how did I mess up?

You need to start at the edge of the system, from the external interfaces and work your way in. My "important class" was not nearly as important as I thought it was, and certainly was not more or less important than any of my other business objects.

When I finally got around to implementing my external interface, which was a messaging layer, I found that some of my earlier assumptions did not hold true. I had over-implemented some of the business objects. It is easy to fall into this trap with TDD, because you can implement your objects before anyone actually needs them.

If I were to do it over again, I would not forgo that initial design, because it certainly helped the process along, but I would always start my implementation with the classes that are closest to the business requirements.

[1] http://joe.truemesh.com/MockRoles.pdf

We’ll ship when the product is ready.

From the Internet Explorer team:

I’ve gotten questions about the ship date. Yes, we have a date in mind. I’ll talk about the date after we get feedback from customers and partners. We’re going to release a beta and listen, then refresh the beta and listen some more. We’ll ship when the product is ready.

This is a refreshing point of view, that you don't hear too often. I imagine that the IE team is under a certain amount of pressure, due to Firefox's increasing marketshare.

This is my brain in....

del.icio.us

You can map your del.icio.us tags with this handy tool.