Get Motivated!

Read these interesting series of motivational thoughts, I would keep updating this post as I stumble upon others

If I am good I could add years to my life
I would rather add some life to my years
And life is really what you make it they say
I can’t even make my mind up today
- Spiritualized,

Bob Parson’s founder of Go Daddy!

Wireless Connection Keeps Dropping on Ubuntu 9.04

If you have been like eagerly installed the latest distribution of Ubuntu which was available a couple of days back then welcome to the party of misbehaving wireless connections.

The Ubuntu version 9.04 was released publically on April 23rd and is called the Jaunty Jackalope. Given the cool features it was a high priority on my update list.

After I updated my wireless connection started dropping at frequent intervals of 5-10 minutes and this was enough to frustrate me. At first I thought it was due to a heavy download that I had initiated but the problem persisted even when i paused the download.

Next step was to explore the Internet to see how many other people were facing the issue. Not many but some. But, none is close to the problem that I am facing.

So this is what I did,

I changed the grub order of menu.lst to load an earlier version of the kernel to see if the problem went away. First, I loaded the

title        Ubuntu 9.04, kernel 2.6.24-16-generic version by changing the default boot order to 8

i.e in the menu.lst look at the following section and change the highlighted portion

# Set the default entry to the entry number NUM. Numbering starts from 0, and
# the entry number 0 is the default if the command is not used.
#
# You can specify ’saved’ instead of a number. In this case, the default entry
# is the entry saved with the command ’savedefault’.
# WARNING: If you are using dmraid do not use ’savedefault’ or your
# array will desync and will not let you boot your system.
default        8

Non Functional Requirements: The Usual Suspects

In Part-I of this series we looked at what non-functional requirements were and how different people react to non-functional requirements.

Ask any team what do we mean by NFRs and most probable answer would be the following and most probably in the order mentioned below

• Performance
• Scalability
• Availability
• Security
• Maintainability
• Reliability

If you come up with a different list on your first pass when asked about NFRs, let me know.

The NFRs which would generally give the biggest bang for your buck are Performance, Scalability, Reliability and Availability. Once you have taken care of these I would recommend looking at the others like Security, maintainability, re-usability, usability etc.

So lets us look at them one by one

Non-Functional Requirements : The Art of Capturing, Analyzing, Developing and Validating

WikiPedia defines the NFRs as

A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions.

In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are “constraints“, “quality attributes”, “quality goals” and “quality of service requirements”. Qualities, that is, non-functional requirements, can be divided into two main categories:

1. Execution qualities, such as security and usability, which are observable at run time.
2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system.

Many people would turn their head in anguish on the mention of Non Functional Requirements primarily because of 2 reasons

What is the Optimal Agile Team Size?

This is one of the frequent questions asked in Agile adoption. I have worked on a project with 135 developers and as expected it was not going anywhere until someone thought that it was death march to proceed in that way. The team was downsized to 60. The process was changed to Scrum. 6 teams of 10 people each were individual scrum teams. But again within this team of 60 people dispersed across 4 geographic locations coordination and communication was still a challenge.

The “silverish bullet” came in the form of dividing the 6 scrum teams to collocated teams of smaller sizes. So the teams were distributed further with each team now having between 5-8 people. The crux was collocated on the same geography. Of course team communication cannot be ruled out hence one member from each team also met in a Scrum of Scrums fashion. Though the teams were drinking from the same backlog, however the sprint backlog for the teams was decided during the sprint planning meeting. The Sprint backlog were kept as much mutually exclusive as possible, but again SoS (Scrum of Scrums) helped for the rest.

So far it has been working for us. But still, what is the ideal team size? People would mention anything between 3-20! Some Agilists argue that the team size should be FIVE. This is the common denominator number based on various studies and falls on the intersection point of these studies. Want to read more about this magic # 5. Refer my post on InfoQ.

What have been the team sizes that have worked for you and how has that environment been any different from any other environment?

The Holy Grail of Iteration Length

One of the frequent questions in Agile adoption is related to the ideal iteration length. Teams usually gravitate between iteration lengths ranging from a week to two months. Choosing the right iteration length is an important decision and the success of Agile adoption depends a lot on the right iteration size.

Read more about the factors on which the iteration length should be decided. My post on InfoQ.