Do you really need to test that?

We all know Kent Beck. The co-creator of JUnit, one of the founding fathers of the Agile Manifesto, author of several eXtreme Programming books, just to highlight a few. Now that Kent has spent a decade telling us all to test everything... now he says, it is ok to skip testing.

I'll let that sink in a bit.

What he is basically saying is that it is ok for the kids to play in the street, if they feel that it is safe. Of course Kent is a big kid, so he will use his experience to determine if it is ok for him to play in the street. But what about the kids that don't know better? You know who they are. They are the kids that climb the tree without thinking about how they are going to get down. They are the kids that lock themselves in the closet without thinking about how they are going to get out.

Kids will be kids. They will make poor decisions if you give them the chance. That is why there are parents. Our job is to make sure that they don't make stupid decisions. Or perhaps we let them make bad decisions to teach them a lesson, just as long as we can control the environment to ensure that nobody gets seriously hurt.

So now is the time to decide if you are a the parent or a the kid. And if you think that you are the parent, half of you are probably wrong. That is the nature of the child, to think they know everything.

One way to measure if you are the parent or the kid is to use the Dreyfus Model of Skill Acquisition. If you follow Andy Hunt, you may have seen him speak and write about this. The model is basically a set of five stages that you progress through from novice to master. It helps explain why novices need lots of rules, and why experts don't think they apply to them.

On the Dreyful Model I often rank myself at a 4 1/2, depending on the subject matter of course. It can be an interesting exercise to rank yourself on the scale, then let your friends rank you to see if you meet your expectations of greatness. Likely you won't, but that is ok, it is in our nature to be overly self-confident.

Now back to testing. Is it really ok to skip testing? Kent thinks so, but I wonder if the followers of the TDD "faith" think the same. In many shops there is no ambiguity, there are only absolutes. You must test they say, but do you? Kent Beck thinks it is a judgment call.

Now I don't have the right answer other than there is no black and white, instead it is all gray. You should acknowledge that, and not immediately attack someone who says that they didn't write a test. Instead ask them their reasoning. Perhaps it is a good reason, perhaps not, but don't come to conclusions.

My Philosophy

Every once in a while some tiny little event crosses your life's path and it becomes a keystone in your being. For me one such event was in the late 1990's when I was working as a web developer at a computer manufacturer.

I recall talking with Phil from the marketing team. He was explaining some idea he had for the company website, probably related to a new customer tool. As usual I listened, made some suggestions, and told him that given some time we could definitely do that. Then he responded...

I like working with you. You never tell me that you can't do something.

That was it! It changed how I deal with development request in a profound way.

I will never say that I can't build something. I might suggest that it isn't worth the effort involved, or there are technical hurdles that I don't have immediate answers to, but I will never say that it can't be done.

In the course of my work I am often involved in discussions of product development. Inevitably someone will eventually say, "we can't do that". These words sound off bells and whistles in my head! I can't help but respond with the words, "why not?"

I think sometimes people like to stick with what they know, which is always the easy way out. But I am not wired that way. By firmly believing that anything can be done I feel empowered and unstoppable. I know that I don't have all of the answers but I can always learn what I don't know.

One RIA Framework to Rule Them All

I took some time on this holiday break to start experimenting with Silverlight and Flex, neither of which I have any experience with. While I was toying around with them I started thinking about the dizzying number of the RIA framework options.

With Silverlight I really liked developing in Visual Studio, it was intuitive and fast. I also liked that fact that I could use XAML to markup the layout, then back it up with C# for the event handling.

Flex looks good too. I especially like the fact that you can mark up your presentation in an XML format (MXML), similar to XAML. I am not a fan of ActionScript though, but I will have to see how east the IDE makes editing the code when I get that far.

Then there is GWT. Well, I liked that so much that I wrote a book about it. I like the fact that I can used my editor of choice (Eclipse), code in Java, and it is open and free.

I once used Ext-JS on a large project, and although it looked great it was extremely painful. When I got done the code was completely unmaintainable.

I have also dealt with Scriptaculous, Prototype, DWR, and other tools over the years, but for smaller projects that probably can't be considered RIAs.

Then there is Wicket, Echo2, blah, blah, blah... so many to choose from!

So which is best? I am partial to GWT, mostly because I know it the best, and it is free and has a great community. On the other hand, I could get used to Silverlight (although the cost can be prohibitive).

If you have an opinion I would like to hear it.

What do you think "great software" means?

I am always looking for new ideas and new ways of doing things. Today I find myself reading Head First Object-Oriented Analysis and Design, and in chapter one it ask you the question, "what do you think great software means?".

Ok, I'll take a stab at that.

Great software does what the customer wanted, and a little bit more. From the user's point of view it should be simple, reliable, and easy to use.

One of my more successful applications was a issue tracking system, similar to Jira, but with less bells and whistles and no admin interface. Internally we also used a monolithic application that was purchased for about $250,000 with another couple hundred thousand spent on training, support, and custom development. It took some time, but in the end the home-brewed application won out, but not because of it's superior feature set. The application gained popularity because it was easy to use (and easy to teach someone to use), did exactly what we needed, and could be customized to fit our exact future needs. That expensive behemoth on the other hand wasn't completely suited for what we needed to do, and could not be customized to do exactly what we needed, but it was as close as we could get. This inability to meet our specific needs meant that it was a source of frustration by the people that used it.

Great software is easy to maintain. By "maintain", I mean that it rarely breaks down and is easy to get running again. By "maintain", I mean that it is easy to customize and extend.

It has been shown in study after study that the cost of maintenance is a huge part of the total cost of a software package. Maintenance includes both keeping the application running and enhancing it. If an application is a "success", you will spend most of your time enhancing the product. If it is a "failure", you will be just trying to keep it running. Happy users want more features, unhappy users just want to use a different application.

Great software is easy to read. A developer can jump right into the code without ever seeing it before and not run away screaming.

If you write an application for your company and you are the only one capable of understanding how it works, then that application is a failure. It may give you a sense of job security, but when you leave the company they may find it cheaper to replace the application you wrote than to try to understand it. I always take the time to look for ways to simplify the code, make the code shorter, make it easy to read and understand. The best code can be easily understood without comments or documentation.

Are web apps moving to the Desktop?

I saw an article on Ajaxian yesterday noting that Google was now allowing you to use their APIs in non-Ajax applications. For instance, you can now use their translation API from the server, or in a Flash application, or perhaps even from a VB application.

This combined with the release of Adobe AIR, a platform form running "web applications" on the client, makes me wonder if the future of "Web 2.0" applications is not in the browser, but on your desktop.

If you look at AIR, the attraction seems to be that it allows you to utilize resources on the client PC, going beyond the capabilities of JavaScript in the browser. On the other hand, don't count out the browser.

At the heart of the Firefox browser is XUL Runner, an engine that allows you to build applications on top of the XUL markup language and JavaScript, along with the ability to use resources on the local PC. A more recent tool is the Google Gears browser plugin, which essentially puts a SQL Lite database engine in the browser.

So what is all of this mean for the future of the industry? It seems obvious that the push is to turn the web application of old into a desktop application. These applications will go beyond Ajax, allowing the application to use resources on the client PC such as databases, access to the file system, and will in general be runnable even when no Internet connection is present.

I embrace this future, but I question its popularity. Yes, I expect that GMail will have off-line access for most of their apps by utilizing Google Gears. I am sure AIR will be a success as companies roll out "desktop" apps using the platform. And I expect that there will be others... a lot of others.

I think this is where the problem lies. When the term "Ajax" was coined, it was available almost everywhere, support for it was ubiquitous. This I believe led to its immediate adoption and the state of the web today. But for off-line web applications the story is different. There are too many tools out there, and in all cases the user needs to download and install software on their computer.

My hope is that all of these tools can get along, but the reality is that this is unlikely to occur. As a user of these applications you will be faced with a choice. You can user install the Google tools for Google apps, Microsoft tools for their apps, and Yahoo tools for their apps... or you just won't use them.

.NET is leapfrogging Java and fairies just stole my underpants

I received an email from Manning along with a link to their forum that caused me to pause. It was titled "Has .NET Leapfrogged Java?".

It seems that an anonymous author had three facts that made this true.

1. .NET has LINQ
2. C# had generics/foreach before Java.
3. .NET has Python, Ruby, F# and others.

These "facts" seemed a little light to me, and I said as much.

If you have an opinion on the matter of Java vs. C#, you might want to check this out.

Some Thoughts on Commercial GWT Components

Recently a message was posted to the GWT developers forum seeking advise on distributing commercial GWT components. The poster explained that his commercial product included an advanced GWT component along with a sophisticated server-side piece to it. His concern was protecting his intellectual property by obfuscating or otherwise hiding his code from his users. I have a few thoughts on that.

Is this a good business plan?

In my day-to-day work I do a lot of Java development, and sometimes I will be working with a commercial Java library for which the source is not provided. Often this causes delays in development because it makes it harder to work with the library. To combat this I simply installed a JAD (Java decompiler) plug-in into Eclipse, and now it only takes a single key stroke to see the source of the compiled classes.

From a customer service point of view it is frustrating to me, the customer, that I need to go out of my way to see the source. I own the product, so why can't I use it? Also note that not distributing the source didn't stop me from looking at it.

This is similar to what the record industry is doing. They want to add DRM to all of their music so that you can't "steal" it. In reality it gets stolen anyway, so all the DRM really does is stop the paying customers from using the music they bought in the manner that they want.

Personally, I feel that if you need to hide the source code from your customers, you are likely taking the wrong route. You will end up making your customers unhappy, and the code will be stolen anyway.

Is piracy good for business?

Did you know that in China it is a good thing to have your music pirated? If it is pirated, then it means that people like it, and the free marketing of piracy is what gets you to the top.

It has been said that Adobe Photoshop at one time wasn't the only product out there for professional image manipulation, but it was the easiest to pirate. I have heard it said that piracy is what made Photoshop the standard.

Microsoft Windows is perhaps the most pirated application that I know of. The part that is interesting about it is that it hasn't stopped them from becoming the most successful software company in the world. The question is, are they as successful because their operating system was pirated, or in spite of it?

The bottom line

In my opinion, if your business plan requires that you protect your intellectual property through the use of DRM or obfuscation, then I think that it is a bad plan.

If you take a look around you will find that many companies have become successful by purposely following a different route. Magnatune sells their music without DRM, and has the tagline "we are not evil". eMusic, also DRM free, it the second largest (I believe) music seller on the Internet. JBoss provides the source of their application server for free, and still makes money. OpenNMS, a monitoring tool, does the same. Add to this Interface 21 (think Spring), and many others.

The bottom line is that you should provide value to your customers, and don't inhibit their use of the product they bought.

I look forward to hearing any thoughts on this.