It takes a while to get the hang of Twitter. For a first time user, it is not obvous how to use Twitter effectively. I have a few friends who are somewhat active on Facebook, but have inactive Twitter accounts. This post is an attempt to compare Facebook and Twitter, show how Twitter is different, and hopefully convince some of my friends to be active Twitter users.

Facebook is a social network with a lot more features than the simple Twitter. Other than that, I see one major difference between the two. On Facebook one can add another user as a friend only with that user’s authorization. The default behavior on Twitter is to let anyone follow anyone else’s updates. This fundamental difference has resulted in me using these two social networks in two different ways. Majority of my friends on Facebook are my existing friends. I have made very few new contacts using Facebook. I use Facebook mainly to keep in touch with my existing friends. The conversation there is casual.

I use Twitter differently. Only a few of the people I follow on Twitter were known to me before.
On Twitter, I follow a lot of people in the software industry. Although I Tweet about personal activities, the focus of my tweets has mainly been on Software Engineering related topics. I find Twitter a great way to learn about software engineering or any other specific topics of interest.

There is a lot of interesting and well-known people on Twitter. Here’s a list of Twitter users worth following:

Well known personalities in the software industry

• Kent Beck
• Martin Fowler
• Ron Jeffries
• Tim O’Reilly
• Ward Cunningham

Other well known Twitter users I follow

• David Allen
• Guy Kawasaki
• Jack Welch
• Stephen Covey
• Tony Robbins

Enrich your Twitter experience using TweetDeck

Although you can always use the simple web interface given by Twitter, you can have a richer experience by using a client like TweetDeck, which is my favorite Twitter client.

TweetDeck is an Adobe Air application and you can install it in a few minutes. It allows you to group tweets. For example you can have a group of favorite users, or have another group with tweets on Twitter that has the words “Unit Testing”. I find this very useful as it’s a great way to know what’s happening right now related to a particular key word.

Follow me on Twitter

I switched from Windows XP on my laptop to the free and open source Ubuntu Linux (vrsion 8.04) about an year ago. Before that I was frustrated with Windows more than once. There were occasional crashings and subsequent loss of data, increased slowness, and vulnerability to viruses. Getting used to Ubuntu was easy, and I could find free and open source software for Ubuntu that met my needs. On Ubnutu, I can do almost everything I did on Windows, and more with less disruptions to my work.

As a beneficiary of “free” and “open source” software, I thought of tracing its history.

Free Software

Let’s try to understand what “free” software is from a layman’s perspective.  In the following video, Stephen Fry presents the argument: if you  own your house, you can improve the plumbing or do any changes you want. Why can’t you do the same to software. Why can’t the community alter and improve software? That is how science works. All knowledge is free all knowledge is shared.

Now let’s look at a more formal definition of free software by Richard Stallman, the president of the Free Software Foundation (http://www.fsf.org/)

Note, the word “free” here means “free” as in free speech, “free” not as in free beer.

Stallman lists the following freedoms that software should have:

• Freedom 0 - Freedom to run the program however you wish
• Freedom 1 - Freedom to study source code and change it to do what you wish
• Freedom 2 - Freedom to distribute copies of the program as you wish
• Freedom 3 - Freedom to distribute modified copies as you wish

According to Stallman, if one of the freedoms is missing, it’s proprietary software; it should not exist; we should reject proprietary software, and replace its unjust social system with the ethical social system of free software.

Is proprietary software really evil and should we reject them?

The argument is that knowledge (like science) should be shared. Good scientists share knowledge, and all knowledge is open and free.

However, software is also a business. Had it not been a business, software may not have advanced to where it is now. Let’s for a moment look at the analogy of buying a car. What if the buyer could replicate the car and freely distribute clones. If it were possible, the auto industry would collapse. Therefore, if we allow the sharing of software, the business model of selling or renting software would fail. The ability to easily replicate software mandates this restriction of freedom.

Could there be a better software business model that allows freedom, as well as generates revenue. Yes. The commercial value in the software industry has started to move from the product to related services like technical support, trainings, customizations of the product.

“…  software itself is no longer the primary locus of value in the computer industry. The commoditization of software drives value to services enabled by that software. New business models are required. “ - Open Source Paradigm Shift

In my view, in the coming years, we will see a competion between these two business models. In some cases, proprietary software would find it difficult to compete with free and open source software with large developer communities, and service based business models, while in some other cases community based open source software that fail to attract large developer communities could lag behind proprietary software. My view is that free and open source software and proprietary software could co-exisit to provide maximum value to consumers.

Open Source

Now let’s look at how the term “Open Source” originated.

“The Open Source Initiative is a marketing program for free software. It’s a pitch for “free software” on solid pragmatic grounds rather than ideological tub-thumping. The winning substance has not changed, the losing attitude and symbolism have.” - Producing Open Source Software , Karl Fogel (http://producingoss.com/)

The difficulty to market “Free” software in the business world resulted in the origination of the term “Open Source”.  However it has resulted in some friction between the Free Software movement and the Open Source movement.

The following videos discuss the switch to open source.

Related videos: Revolution OS

Follow me on Twitter

Test Driven Development (TDD) is great. When I started unit testing and TDD with JUnit about six years ago, it was a relatively new concept. I was impressed by the way it helped development, and led to developing better code. However, it’s only now that I realize how little I knew about unit testing back then.

I can remember an XP project where we developed an enterprise application which had two layers of session beans, and entity beans that got persisted in an Oracle database. We used to have unit tests (that’s what we called them) testing all layers, accessing the session beans and propagating all the way down to the entity beans and to the database. As a result of testing all layers, running the whole suite of tests took us about one and a half hours. We were not convinced that our so called unit tests added any value to the project as it took us so much time to use them properly. So we ended up running only groups of tests together, and not the whole suite.

Recently I stumbled upon an article by Michael Feathers that literally describes the same issue we faced. He lays down the following rules:

A test is not a unit test if:
1.It talks to the database
2.It communicates across the network
3.It touches the file system
4.It can’t run at the same time as any of your other unit tests
5.You have to do special things to your environment (such as editing config files) to run it.

The main takeway from this is that the purpose of a unit test is to test the functionality of a particular unit of code. It need not test all the layers of functionality upon which the class being tested depends (e.g. entity beans, databases etc.). In our case, we could have used mock objects to separate the business logic from the underlying persistence layers. This should have allowed us to simply test the business logic of our classes using unit tests without effectively writing comprehensive but bulky functional tests. We could have defined our classes with dependency injection in mind. Dependency injection is the practice of writing testable code by separating code for object creation and business logic, and passing all dependent objects through the constructors of objects.

The Google tech-talk below provides a great explanation of this concept:

So, just because you use an xUnit framework and write automated tests for your classes, they don’t necessarily become unit tests.

A topic which often surfaces in discussions about XP is, whether Stories in XP are the same as Use Cases under a different name. Apparently, they seem to be the same. However, if you analyze a little deeper it’s possible to identify subtle differences between the 2 approaches.

In my view, the main difference is their purpose of existence. The main purpose of a user story in XP is to identify the scope of the project as early as possible and to track project progress. While a use case tries to capture requirements at the required level of detail. The XP approach is to have the story defined in simple words and to get more details from the customer before development starts.

User Stories in XP

1. Purpose: Estimation, identification of scope early, and tracking progress.
2. Characteristics: Simple; any customer visible functionality.
3. Approach: Meet customer face-to-face and get details before implementing.
4. Suitability: Projects that need early implementation.

Use Cases as used in the Unified Process

1. Purpose: Describe all tasks that users will need to perform with the system.
2. Characteristics: Can be scaled to have many details; functional and behavioral requirements.
3. Approach: Gathered mainly initially (inception & elaboration phases).
4. Suitability: complex large projects.

Slipping deadlines by months and sometimes by years, exceeding estimated cost by many times, defects in production, and projects that never complete are common issues in the software industry.

In my view this is due to the softness of software. One definition of “Softness” is: Easily molded, cut, or worked1. Software can be easily changed; it’s not like changing the design of a house after it’s built. If that’s what you think, think twice. Is it really easy to change software?

Changing current code of software does not make a mess like tearing down a section of a house does. However, changing software takes time, and that means it costs to change software. If the one who changes the code is not the original writer, it may take more time to understand the logic of the previous code before doing any changes. What’s more, changing code could introduce new issues that may or may not get caught before shipping the product. If caught, these would require more re-work until all issues are fixed. Sometimes, this becomes a never ending cycle of fixing-introducing more issues - fixing.

Therefore, is the softness of software just an illusion caused by the apparent cleanliness of the demolition and rework of software? What if software was not soft, but once it’s coded, it can’t be changed? Would this have resulted in more rigorous ways of perfecting initial requirements, or betters ways of modeling software? If software was not soft, it would have meant that once the product gets out of development, if it does not pass quality control, it would be rejected, and not sent back to developers for bug fixes, resulting in developers having to re-build the product or parts from scratch. Would this have resulted in more disciplined development methods that ensure what’s released from developers are of production quality?

I don’t have answers to these questions. However, thinking of software as “not soft” may open up new avenues for perfecting software engineering.

1. softness. Dictionary.com. The American Heritage® Dictionary of the English Language, Fourth Edition. Houghton Mifflin Company, 2004. http://dictionary.reference.com/browse/softness (accessed: November 14, 2008).

Chapter 10 of Dreaming in Code is titled: “Engineers and Artists”. This chapter discusses the age old debate about whether building software is an engineering discipline or whether it’s more like a creative process similar to producing art.

In my view it’s both an engineering discipline as well as a creative process. However, building software should primarily be an engineering discipline. I use the word “should” as in practice, this has not been true. This is both based on my personal experience as well as what is discussed in the book. The following quote from the book is a good way to put it.

“If builders built houses the way programmers build programs, the first woodpecker to come along would destroy civilization - Gerald Weinberg”

My argument that building software should primarily be treated as an engineering discipline is based on the comparison of impact of faulty software and not so good art. Although artistic creativity is important, if the software does not perform as intended, there could be serious consequences.

The impacts of 20 famous software disasters range from lives lost and endangered to millions of dollars lost. Although the impact of failure of all software would not be as catastrophic as this, all software failures would affect lives of people one way or the other. Therefore, it is paramount that building software is treated primarily as an engineering discipline.

The challenge is to perfect building software as an engineering discipline, which is not as mature as other engineering disciplines.

Images taken from en.wikipedia.org

Related Posts: Dreaming in Code, Don’t Worry be Crappy , In Search of an Ideal Personal Productivity Tool