Random Thoughts on Software

Working on several software development projects, both agile and non-agile, I’ve realized a few things:

- Non-agile teams favor isolated development practices
- Isolated practices are generally pessimistic
- Agile teams favor collaboration
- Higher collaboration seems to (naturally) require more optimism

Non-agile teams favor isolation

Most of the non-agile teams that I’ve worked for (including those who thought they were agile, but really weren’t) have generally favored isolated development practices. For example, developers take on different tasks and develop them in isolation. Developers have ownership of segments of code and take it very personally if somebody critiques or modifies their code. Teams also seem to either favor version control systems that use pessimistic locking or favor developing on isolated branches and then merging for releases (or both).

Isolated practices are generally pessimistic

Non-agile teams tend to use isolation as the solution to the problems of concurrency. If multiple people are touching the same thing, there are two ways to manage the concurrency, optimistically or pessimistically. The non-agile approach seems to favor pessimism by preventing the concurrency all together. But are you really preventing it? No, really what you are doing is delaying it, and in turn delaying the discovery of integration bugs.

Let’s take version control for example. If two people branch seperately from the same code base and develop in isolation, they are eventually going to have to merge. Somebody will have to merge first, and you still have the same potential for integration bugs as you do if the developers were developing on the same branch.

Agile teams favor collaboration

In my opinion, the most fundamental idea with agile processes is that the productivity of the team is more important than the productivity of the individual. This sounds rather socialistic, but we’re not talking about government, we’re talking about business. It doesn’t matter if you develop component A under time and under budget if your product can’t ship without components B and C and they are over time and over budget.

Agile teams seem to favor collaboration in almost every practice. Take Extreme Programming for instance. Pair programming immediately removes the isolation involved in development by having two developers work on the same code and calling for developers to change partners periodically. Collaborative code ownership allows anybody to touch any code. Continuous integration and fanatical unit and acceptance testing allow developers to work on the same branch with great assurance that they will not have integration bugs.

Collaboration naturally requires more optimism

In order to acheive high collaboration, development practices seem to naturally gravitate towards more optimism when dealing with concurrency. Concurrency is not dealt with via isolation, but rather by allowing the concurrency and building practices around it that minimize the liklihood of integration bugs, by forcing them to be visible and dealt with early.

Some other thoughts

Now, I’ve seen both models, and I’ve seen both models work. I’ve seen teams using either model effectively deliver high-quality systems on time. But from my experience, agile teams are more likely to be able to do this repeatedly. There are also some other nice side-effects; though there are no absolutes, when I compare agile and non-agile teams, I notice that agile teams have a tendency to:

- be smaller in size
- have more comprehensive testing
- have more focus
- have more fun
- be able to learn more from one another
- be able to adapt more easily to changing requirements
- have more frequent releases
- involve their customers more throughout releases
- have more uniform coding style, designs, and programming idioms

The agile thought process seems to be gaining ground and I think will eventually be the de facto way that people approach software development.

My name literally means ever-lasting in Farsi.

It is officially pronounced: JAW-veed. The JAW is the strong sound and is pronouned just like the body part, and veed rhymes with weed.

Growing up, American friends / teachers always pronounced it: JAV-id, where JAV sounds like the first part of java and id sounds like the first part of idiom. Growing up, I never really bothered correcting people, and I eventually got used to this pronunciation. This is still how I introduce myself to American people.

There are also about 10 other variations that people have used. For example, my inlaws say: ju-VEED, where ju is the first part of just and VEED is the strong sound. Some of my close friends shorten my name and pronounce it: JAV-ee, which rhymes with Ravi (like Ravi Shankar). I actually like this pronunciation. In general, I acknowledge people as long they get close.

The only one I really dislike is: JAH-vid, where the JAH is like the ‘ja’ in jam and the vid sounds like the first part of video.

In English, my last name is pronounced: juh-MAY, where juh is like the ‘ju’ in just and MAY is pronounced like the month. In Farsi, my last name is pronounced: JAW-me, where JAW is like the body part and me is like the ‘me’ in metal.

I’ve been looking into home theater PC (HTPC) software lately and I’m very impressed with some of the packages available. HTPC software is essentially a digital video recorder (DVR) on steroids. You can use it not only to record live television, but also to provide access to all of your stored media content (mp3s, ‘ripped’ dvds, mpeg, game emulators, etc).

Some HTPC software packages provide RSS aggregators (feed readers). You can use this to read the news through your HTPC, but you can also use it with feeds that provide bittorrent links to audio and video content. This is great if there is a regular TV show that you watch, because you don’t have to program the recording of the show yourself. Somebody else has recorded it and it is now available for download in a widely distributed network of bittorrent users.

When I first started learning about HTPC, I envisioned an ability to tell the software what I wanted to watch and have it (transparently) get that content for me. This seems like a simple concept, and I hope to see it eventually. Here’s how I envisioned it would work:

I go onto a channel guide to select a show. This channel guide not only has current shows, but as much past and future scheduling as is possible. I select a show that I want to watch and click go. The HTPC software transparently retrieves that content for me (as fast as possible) and I start watching my show.

If a TV program is in the past and I have a recorded copy on disk, it would immediately start showing the program. If a TV program is in the past and I don’t have a recorded copy, it would start downloading the show for me over P2P.

If a TV program is currently showing and it is not being recorded, it would show the program and simultaneously start downloading it for me in the background through a P2P network, so I would have the ability to rewind to a point before I started recording.

If a show is in the future and I have access to the channel, it would schedule the system to record the program for me, just as it does now. If a show is in the future and I don’t have access to the channel, it would schedule the download over a p2p network. The mechanism for scheduling could be an RSS feed, some type of bittorrent “placeholder”, or something else (as a user, I don’t care because it should be transparent).

Eventually, as bandwidth, users, and recorded content increase, a highly reliable video content retrieval system would exist. You would be able to watch any TV show that you would like, whether you recorded it or not. I can imagine the evolution of a common file format being used for P2P video distribution. If these files have the start time, end time, and channel (including region) embedded, then recorded fragments from different people could be pieced together.

At first glance, this seems like an overtly illegal process, but it doesn’t have to be. People would be willing to pay big bucks for a service where they could watch TV that they didn’t schedule a recording for. A company could charge a service fee, pay all the royalties to the content providers, record as much TV as possible, and seed all of the bittorrents.

I just finished reading a book called Free Culture by Lawrence Lessig. I would highly recommend this book to anyone who wants to gain a good understanding of the debate over copyright and understand how current copyright legislation it is affecting our culture and our ability to innovate. The book is mainly about copyright, but he demonstrates how copyright laws are inhibiting innovation in software. I like the style of the book because he teaches through telling stories about people and events that have been affected by copyright issues. Though Lessig is apparently a little leftist, he effectively shows how the issues affect both sides of the political spectrum.

After reading this book, you may feel the need to become active in the protection of the public domain. A good starting point is to sign this petition. If you live in the U.S., you can then contact your representative(s) in the House and Senate.

In enterprise applications, system failure notification is often mission critical. If an application or a computer system fails to respond, or an application produces an unrecoverable failure, human intervention may be required.

Notification can be accomplished in many ways. An error message can be captured in a log file, e-mailed to an individual or a mailing list, or even sent as a text message to an application support team. These technologies all have advantages and disadvantages. For example, anybody who needs to access a log file could probably get it, but it is difficult to see what error messages have already been viewed and it is easy to forget to regularly check the log file.

Another way to distribute notification of application errors is to syndicate them using an XML-based syndication format such as RSS or Atom. Electronic syndication has become quite popular in the last year or so. Many news sites, Weblogs, and online content providers use syndication to provide people with updates to their content. In order to access the data in an RSS feed, a user needs to use a program that is capable of reading the syndicated feed. These programs are often called news aggregators or feed readers.

I’ve setup a working implementation using log4j and RSS. I created a custom log4j appender named RssAppender that converts the error messages into RSS item elements that are appended to a file. Then, I created an RssPublisher, which runs a background thread that takes the items that the RssAppender outputs, tacks on the necessary XML before and after the items, then publishes the complete feed to a Web server.

What are the benefits of using syndication to notify people of error messages in your application?

* Feeds can be made accessible from anywhere on the Web (or on an Intranet)
* Subscription to a feed is handled by the receiver rather than the sender, thus the subscription process is simpler and nobody needs to maintain a list of subscribers
* Subscribers can choose to use whatever feed-reading software they want
* Depending on the software subscribers use, they can choose their own update frequency
* Errors can be displayed as discrete items, so users can see which errors they have read and which ones they haven’t
* Multiple feeds can be produced to display various levels of error, allowing people to subscribe to the levels that they are interested in
* People can subscribe to several feeds from different applications within their feed aggregator, allowing them to have a combined view of errors across multiple applications
* Syndicated feeds can be integrated with existing content-reading technologies such as e-mail, scrolling news tickers, or sms-messaging systems

Here are some resources you can use to get started:

* Set Up a Simple Syndication Feed Using RSS
* Learn to Consume RSS Using DevX’s New Content Feeds
* RSS Resources
* What is RSS?
* Software keeps track of Weblog, news-site updates
* Log4j

If you’ve ever done a toString on an object that doesn’t override toString(), you’ve probably noticed that it returns something like this.

com.mycode.MyClass@1312311

Now the big question: can two different object instances ever have the same value after the ‘at’ (@) sign?

The answer is yes. If you look at the source for Java’s Object class, the toString() method prints the name of the class, the @, and the value of the hashCode() method. If your class overrides hashCode(), and you create two objects that have the same exact hash code (because all of their values are identical), then you can reproduce this behavior.

I’ve always naively assumed that the number after the @ was always the object’s memory address in the heap.