Random Thoughts on Software

I’ve was going to write something today and I wanted to use the idiom “from a 20,000 foot view”, but I was questioning whether I got the number “20,000″ right. So, I did what any self-respecting geek would do, I Googled it. Well, as I expected, different people view things from different altitudes. I searched for two phrases, “from X feet” and “X foot view”, substituting X in for increments of 10,000. Here are the number of results Google said it had for the different numbers:

So it looks like people are generally looking at things from 30,000 feet (but keep in mind, my analysis is only based on a 10,000 foot view of the statistics).

In July of 2005, I received an e-mail from an editor at Manning Publications Co. regarding some articles that I had written about JBoss. They liked my writing style and wanted to see if I was interested in writing a book on JBoss. I pitched a table of contents for a book that would be in their “In Action” series and they accepted it. Now, nearly two years later I, along with my co-author Peter Johnson, are approaching the production stage for our book, JBoss in Action.

Between the two of us, Peter and I have spent a lot of time on the JBoss forums, teaching JBoss courses, contributing to JBoss projects, and consulting with companies on how to use JBoss. This experience allowed us to provide practical, real-world advice and focus the book on the topics and features that people actually use and ask about frequently. We hope that this book can put our experiences into your hands so that your journey through the world of JBoss is as painless as possible.

JBoss in Action is different from other JBoss books on the market because of several reasons:

• JBoss in Action covers JBoss Application Server (AS) 5.x. All of the other books that are available cover JBoss AS 3.x or JBoss AS 4.x.
• JBoss in Action is not stuffed with complicated explanations and disorganized content that lacks sufficient background. If you’ve spent some digging through the JBoss wiki, the JBoss documentation, or JBoss 4.0 - The Official Guide, you’ll appreciate this.
• JBoss in Action focuses on teaching you about the application server, not Java EE programming. The book JBoss at Work is great for learning how to program Java EE applications for JBoss, but it doesn’t give you enough detail on how to configure and operate the more advanced features of the application server.
• JBoss in Action covers a wide range of topics. The book JBoss: A Developer’s Notebook is very well written and is very practical, but it only gives you enough information to get your feet wet.

The first four chapters of JBoss In Action are currently available through Manning’s early access program. If you order the book through the early access program, you get to preview these chapters now; then, when the book comes out, you get a PDF and/or print version. You can find out more about the early access program by clicking here.

If you decide to purchase the book through the early access program, you can post any questions or comments about the book on the Manning forum set up for the book:

There are two types of standards: de facto standards and de jure standards. A de facto standard is one that is based on widespread use and recognition throughout an industry. A de jure standard is created by a body or committee. These two types of standards are not mutually exclusive, and often, the best standards are those that start as de facto standards then become de jure standards. This is because unproven de jure standards are less likely to be successful. For example, parts of the J2EE standard (a de jure standard) were arguably unsuccessful because they were unproven in the industry (e.g. EJB 2.x entity beans) . But the new Java EE 5 standard has learned and applied things that developers learned from real use in the industry.

I’ve heard that about 45% of features and functions in software go unused. As a developer, I have control over removing unused functions and I do so quite diligently through refactoring and the courage that I have to modify my code through the practice of test-driven development.

But I believe that unused features can have a significantly worse effect on the quality of a software system than unused functions. The more code you have in your system, the more complicated your architecture becomes and the harder it is to maintain. But the dilemma that many developers have is that they are being asked to add features by product owners who might not have a good feel for the repercussions of doing so. In other words, as a developer I can control how many unused functions I have in my code, but I cannot control how many unused features I have.

I have often wondered if product owners should be as diligent with requesting feature removals as they are with feature additions. In order to do this, they would need to have some insight as to which features are being used and which are not. I feel that this is where a separation in responsibilities between the development team and the product owner is necessary. Developers should be responsible for calculating which features are used and at what percentages. Product owners should be provided with that information and make decisions on feature removal.

Of course, it is often hard to justify or rationalize feature removal because it doesn’t seem like progress. But it is progress; progress towards the simplest system that meets the needs of the user. Building simpler systems ultimately costs less money. Product owners have the tricky job of knowing and balancing good business decisions with good software decisions.

I didn’t find one that I liked exactly, so I just thought I’d post an image that represents the flow of the TDD process.

[click on image to enlarge]

Martin Fowlers discusses the term Technical Debt as what is introduced into your code when you take a quick, yet messy approach to developing something. Another way to think about technical debt is as the inverse of quality; in other words:

technical debt = 1 / quality

A word that I’ve often heard used to describe the action of incurring technical debt is sprinting (not to be confused with a sprint in Scrum). This is an analogy to sprint running (in the track-and-field sense) where developers are rushing to write code, often at the expense of quality, testing, documentation, and their own sanity.

I’ve had development managers ask me to have teams sprint in order to increase velocity and thus meet a deadline. The usual “recommendation” is to skip refactoring or testing in order to accomplish this goal. In response, I’ve drawn the following graph several times to communicate the effects of doing this, so I thought I’d document it.

[click on image to see full size]

The 1/Q line represents the inverse of quality (or technical debt). When you are continually refactoring, as shown in the first part of the 1/Q line, the quality stays within a reasonable range. The velocity also stays within a reasonable range. When you start sprinting your quality goes down (technical debt increases). As seen on the graph, the velocity increases as the sprint begins. Unfortunately, the poor quality will eventually catch up with you, making it difficult to add new features or fix bugs, thus the dip in velocity right before the 1/Q line levels off. If the sprint continues for too long, you can likely get to the point where adding more functionality is just too difficult without recovering some of your debt.

But here’s the kicker, even if you did no development and focused just on refactoring (hence the drop to 0 velocity on the graph), it would take quite a bit of effort to get to the level of quality that you used to have. If you don’t recover from the technical debt, you shouldn’t expect to return to your previous velocity.

Refactoring helps you maintain a consistent level of quality in your code. You should try to avoid sprinting as much as possible, but if you do it, don’t do it for too long.

I’ve often felt that there should be an etiquette guide for pair programming. Here is a first stab. I’ll update this list as I think of more.

Navigator:

• Wait until the test is passing to nitpick on coding standards.
• Ask nicely for the keyboard to “show” what you mean.
• After “showing” what you mean, offer the keyboard back.
• If they don’t take your advice, let them finish doing the task their way and then show them after they’re done.
• It is good to inform the driver of keyboard shortcuts and refactorings but don’t interrupt the programming flow too much with advice that is not directly related to the programming task.

Driver:

• Don’t ignore or get frustrated when your pair tells you a better way to do something.
• Auto-format so your navigator can read your code easier.
• Don’t be stubborn about giving up the keyboard when your navigator seems to know what they’re talking about.
• If the navigator is confused by what you’re doing, talk them through it by having a whiteboard conversation.

I somehow got suckered into going to a multi-level-marketing (MLM) meeting not too long ago. No, not Amway… BurnLounge. Burnlounge is an MLM scheme where you pay around $500 to start your own music store in order to sell to your friends and family. Burnlounge allows you to customize your own front page and provides you with a URL like:

http://burnlounge.com/yourMusicStoreNameGoesHere

When your friends and family go to your Website, they can buy music from you for the great price of…. drumroll… $0.99 a pop. The music selection and prices are all controlled by Burnlounge, so what is the rationale behind your friends and family buying from you rather than from iTunes or any other site that sells music for the same price? Because they’re family and family would rather buy music from you than Steve Jobs. Yes, until they get sick of you and your cousin and your sister all competing to try and sell them music, at which time they’ll just go to AllOfMP3.com and buy music for 1/5 of the price anyways.

But they quickly moved away from the conversation about price, because they want you to believe that the competitive aspects of the business (price, services, selection, etc.) are inconsequential. Like any other MLM scheme, the focus isn’t on selling the product (music in this case), it is on building a self-sustaining network of people who are selling to their friends and family and building their own networks. This is called a pyramid. But they don’t call it that, they want you to naively believe that “a series of concentric circles” is something different than a pyramid.

I sat through 2 hours of listening to one speaker after another attempt to appeal to the human affect/emotion rather than the human intellect/logic. If you’ve ever been to a MLM meeting you’ve heard the ridiculously stupid rhetoric before: “This isn’t for everybody. Some people get it and others don’t. Those of us who get it will become successful.” And unbelievably, tons of people were suckered in by this inane form of reverse psychology. Or better yet, “Look at all these rich and famous people who are involved. They’re all doing it, so it must make sense.” As if rich and famous people never jump on the bandwagon or make horrifically stupid business decisions. A quick look through a list of common logical fallacies would show that they violate almost every single one. There is almost nothing logical about they way they present their business model.

And I am so glad that I’m a tech geek, because I could hardly believe the horrifically misleading or patently false information they were feeding this crowd of unsuspecting, non-technical folk. For example, they promote the fact that their music is available in WMA format, and fail to mention that this will only play in Windows Media Player. They also fail to mention that their music will not (as far as I could tell) play on an iPod. Ya, let’s just ignore the fact that the iPod has about 80% of the market share in portable MP3 technology, and fail to inform prospective store owners of that.

Then they were pitching DRM as a benefit to their consumers!! DRM is a technology designed to limit the product owner’s rights (you know, they one who paid for the product) in order to protect the intellectual property rights of the artist. That’s like saying that Toyota added technology to their cars that would prevent you from changing the paint color, tuning your engine, or adding aftermarket parts, and then touting that as an advantage for the customer.

Or better yet, they appeal to common practice by saying that McDonalds is successful because they have thousands of stores not just one; so, logically it must make sense to have thousands of music stores online. Hmm, last time I checked Amazon, Ebay, Circuit City, and Gap all have a single online store. Wow, how do they succeed!?!? Could it have anything to do with the fact that McDonalds sells a tangible product and must have multiple stores to position itself in different geographies in order to distribute their tangible product? An intangible product, such as a copy of a song, can be distributed globally with a single distribution channel. How could people fall for this ridiculously illogical argument.

The bottom line is that if you’re going to get involved in a business your focus should be on selling your product not on building a network of salesmen. You should be thinking of ways to compete against your competitors. And honestly, its not “your business” unless you can directly control the competitive nature of your business. Can you add new services? Can you change your prices? If not, then you are just a sales person for somebody else’s business.

I just read that Universal Music is suing MySpace.com over copyright violation, saying that MySpace encourages its users to illegally distribute copyrighted materials. Universal is arguing that:

“Our music and videos play a key role in building the communities that have created hundreds of millions of dollars of value for the owners of MySpace,” the company said in a statement. “Our goal is not to inhibit the creation of these communities, but to ensure that our rights and those of our artists are recognized.”

Yes, and MySpace, through its “copyright violation” has played a key role in creating hundreds of millions of dollars of value for the owners of Universal. Call me crazy, but how does Universal not realize that MySpace is a massive marketing engine that is promoting their music.

People post songs on their profiles and their friends can listen to those songs when they visit. This is called “sampling” and it promotes Universal’s music. Sampling of this sort is going to be one of the most significant ways that digital content will become popular in the next 5-10 years. People share music and music becomes popular because of it. When music becomes popular, musicians sell more music, concert tickets, t-shirts, etc.

The record companies have got to take off their blinders and realize that they need to help promote this, not fight it. These types of lawsuits and lobbying hurt technological innovation and damage our culture.

Since Java adopted annotations, I’ve heard a lot of discussion around whether to prefer annotations over external configuration files (often XML) and vice versa.

I think the decision boils down to two criteria:

1) Can annotations simplify the metadata?
2) Can changes to the metadata break behavior in your application?

If annotations do not reduce the amount of metadata that you have to provide (in most cases they do), then you shouldn’t use annotation.

I think the more important thing to considered is whether a configuration change could break behavior or not. If not, then you can feel comfortable applying the change while the system is running in production. External config files are the best place for the metadata in this case because you don’t want to have to recompile your code to make the change.

However, if a metadata change could break behavior then you’ll want to test the change by going through a full release cycle (change code, build, test, deploy). If you’re going to go through a full release cycle there is practically no benefit to not recompiling besides the 5-10 seconds you save in compile time. The more important thing to consider is which method of metadata definition is simpler.

For example, Hibernate mappings are often in XML, but annotations often provide the ability to specify the same mappings with significantly less metadata. Any changes you make to your mappings (whether in XML or annotations) could potentially be behavior breaking. You’re not going to change your mappings dynamically at runtime, are you? So, annotations seem like a much better choice.

[Note: I might consider using XML metadata for Hibernate when mapping to a legacy database because the annotations can often become bulky. Also, you are forced to use XML if you want to map the classes against two different databases with different schemas. I haven’t heard of a way to specify two mutually exclusive sets of Hibernate annotations on my classes. Even if this did exist it would be complex, which violates my first criterion for selecting annotations over XML.]