Jared's Weblog

Main Page - Books - Links - Resources - About - Contact Me - RSS

Jared Richardson Most Popular
Help! I've Inherited Legacy Code
Testing Untestable Code
Continuous Integration... Why Bother?
Mock Client Testing
The Art of Work
Technical Idiot Savants
Targetted Skills Aquition vs Free Range Chickens
The Habits of Highly Effective Developers

Blog Archive

Thu, 08 Dec 2005

Humane Interfaces versus Minimal Interfaces

There's been quite a fuss about Martin Fowler's post on Humane Interfaces. If I summarize his post for the sake of brevity, a larger, more humanly readable API is preferable to a smaller, more cryptic API.

The discussion seems to be falling into two camps. One side says that if you are a ~real~ developer, you'll invest the time to learn the API. Then, as a skilled user, you'll apply that skill and build something.

The other camp seems to feel that with a human readable API, you just skip the "invest the time to learn the API" and move straight to building something.


Spend time learning Yet Another Unique API... or write code.

Spend time bulding a smaller, tighter, cleaner, more cryptic API... or make it easier to understand ~and~ use?

In my experience a team writing an API will spend a minimal amount of time adding these additional API calls. But the performance increase I've seen on the teams using this technique is substantion.

Remeber, the API developers wrote the API code. They know it better than anyone. For them, adding a first() and last() routine will take 30 seconds. Literally. The other option is to force your end users to learn the API well enough to know if the last() call should be list.indexOf(list.size() -1 ) or list.indexOf(list.size()). These bits of arcane, useless trivia should not be force fed to your users. It's just inefficient.

What was the argument again?


posted at: 23:54 | path: | permanent link to this entry

Testing Untestable Code

This blog entry is a reprint from Ship it! A Practical Guide to Successful Software Projects. This section comes from the last chapter of the book, Common Problems and How to Fix Them (also known as the FAQ).

Obligatory legalese: The Following text is Copyright 2005 The Pragmatic Programmers LLC. All rights reserved.

Testing Untestable Code

If you are a developer or tester trying to get an automated test suite set up for your product, you may find yourself in the uncomfortable position of trying to test a product that doesn't have good "hooks" for your test rigs. It's not impossible to test "untestable" code, but the effort involved in test creation and maintenance usually cancels out the benefit of the automation.

For instance, you might be trying to test an HTML page that has a lot of unnamed fields. So instead of using the "name" or "id" tags to locate a field, you count the items on the page and check the value in the fifth item. This is very difficult for someone else to understand and maintain, but the test is also very fragile. Often, changes to the page will break your test.

What's the solution? Tell your manager you want to start test driven refactoring. You want to start adding the simple hooks to your application that make it possible (or feasible) to do good automated testing.

First, create (or borrow) a test plan for the product. Keep the plan simple at first. Don't try to make it perfect on your first attempt. Shoot for a simple pass that exercises basic functionality.

Second, write an automated test. Make the test go as far as you can. When you get stuck, what's the least amount you can add to the product's code to get the test running? Is it just a return code to an existing API or an "id" tag for an HTML field?

Don't try to fix every problem with your first pass. Don't try to add "id" tags to every page in your product; shoot for the one page you need to get the test passing. If your test plan hits a roadblock, don't stop. Remove the part of the test plan you can't test and move on. Remember that you can also add the hard part to your next test plan.

The goal here is incremental improvement and momentum. As you make small improvements, your developers will start learning how to create testable products. As you write automated tests, you'll start learning tricks too. You'll be surprised at how much support you'll get once you've got a basic automation suite in place.

The Tip?
Use test driven refactoring to clean up untestable code

Related blog entries: Test Driven Refactoring and One Test per Feature

posted at: 23:22 | path: | permanent link to this entry

Targetted Skills Acquisition Versus Free Range Chickens

I've had this floating around in my head for a while. It all got started after someone told me that they though conferences were a waste of time. In this person's opinion you never come away learning enough to be useful. The learning is only skin deep and you learn things you shouldn't try to integrate at your day job anyway. If the course is on Spring and your company is using Struts, you've just split the mindshare and possible diverted your project.

This point of view is what I call Targetted Skills Acquisition. Learn only what you need to get through next week. When you need to learn Hibernate, go learn it then. Buy a book, go to a class, or just download something and get to work.

On the other side of the fence, we find Free Range Chickens. A free range chicken tends to browse around, learning a bit over here and a bit over there. They do tend to waste an lot of time learning things that they don't need to know. Most of the tools and technologies chickens learn are never used.

When a problem is encountered, who can solve it the quickest? The chicken can. Someone who browses a wide variety of technologies will immediately know what category of technology can be used to solve a problem. A targetted personality will have to research the problem before they understand how to attack it. However, the chicken has been "wasting" time all along, learning lots of other bits they never use.

When solving a computational intensive problem, a chicken might look to a grid or a distributed solution because they've read about grids and are familiar with the concepts even though they've never used them before.

The targetted skills person isn't familiar with ideas like grids, so they spend a lot of time trying to tune their code to run as fast as it can on a single machine. It's a very traditional approach that prevents the application from scaling to a true enterprise solution.

Another factor to consider is that a chicken who learns about both Struts and Spring is more qualified to evaulate both and understand which one solves their problem better. If you are ignorant of the strengths of alternatives, you can't make an educated choice about the technology. This is why targetted skill types so often pick the wrong technology for a problem. It drives a good chicken crazy just watching it happening.

What is the correct approach?

I am a Free Range Chicken through and through, but I work with some very smart and effective people who are completely Targetted Skills Acquisition.

|'ve seen times in my life when I wonder if a more focused approach wouldn't have served my employer better. Would we have turned out product faster if I had been more targetted? I don't know.

But I also have seen many targetted skills people completely miss the boat with their technology choices. Their lack of broad exposure causes them to re-invent the wheel poorly instead of using a simple, existing solution. They are ignorant of industry best practices so they don't use them.

A few years ago I spoke to an "industry veteran" at the top of his game. This person had more than a decade of software experience but had never heard of MVC. He wasn't dumb- in fact, just the opposite. He understood the concept and it's benefits immediately when I showed it to him. He just hadn't been exposed to it before. He's a very smart person, but extremely targetted. And no, he wasn't coding assembly or device drivers. He was able to use the idea to do his job better.

It's not that a Free Range Chicken type is any smarter than a Targetted Skills Acquisition person. It's that they are more broadly educated.

So, what's the balance? How do we both stay educated and effective?

How much do you strive for targetted learning versus browsing across the free range? The fact that you are reading a blog tells me that you have chicken tendencies. :)

How, as a company, do we encourage both ideas? I'm thinking this is something that Google's policy of letting everyone spend 20% of their time on an independent project might address.

I'm struggle with this topic every day. I wonder what types of solutions others have found?


posted at: 21:30 | path: | permanent link to this entry

Java Code Coverage Tool Cobertura Released

The open source toolkit Cobertura released a new version this week. They made some major additions, including support for AspectJ compiled code. Cobertura continues to improve with every release.

It's adoption is increasing as well. The SourceForge statistics page says Cobertura's had over 7,000 downloads and more than 400,000 hits on the web site.

Are you using code coverage? A coverage tool will tell you what parts of your source code are being exercised by your test code and what parts aren't. It's the only effective way to knowing what code is completely untested. It formats this information in XML files or, if you prefer, a nice report to make it easy to digest.

Here's a quote from the release notes:

We've just released Cobertura 1.7. We fixed the problems with the merge task, as well as a few other bugs. The full list of changes is below.

If you've never used code coverage, head over to SourceForge and download the latest version of Cobertura. The introduction page will show you exactly how to use it.



posted at: 21:10 | path: | permanent link to this entry