Development Process Illustrated

December 11th, 2005

The Website Development Process at pingmag.jp describes an iterative product development life cycle through a presentation that is “fun to look at.” The presentation focuses on the interaction between a web design firm and a client, but the interaction can be generalized to cover all product development efforts. This is a useful resource for introducing the development process to clients. It can also serve as a guide for developers who might need a refresher on the basics.

Women Business Leaders

December 10th, 2005
Posted in - blah - | 1 Comment

Jeff Wuorio’s 4 Ways Businesswomen Can Combat Bias discusses ways to fight detrimental views on female company representatives. Although it may be needed for a small company to fight these preconceptions through deception as Gini Dietrich of Arment Dietrich does, making a fictitious male entity the leader of a company that is headed by a woman simply reproduces discrimination against women in business interaction. Living in a time where widespread lack of progressive thinking makes notions of a female US president remarkable is unfortunate. Dietrich’s actions support the status quo. If potential clients are sensitive to doing business with a female business leader, then the performance of the business leader should be used to steer the prospect away from their preconceptions and persuade prospects into becoming clients. Supporting and increasing the success of businesses that discriminate against female business leaders helps discrimination persist in business settings. Female business leaders should use the talented knowledge workers that they have accumulated to help, through their business’s services, companies that are more interested in becoming more profitable and less fixated on extending sexual discrimination.

read more | digg story

On the Cost of HA

December 9th, 2005

A blog entry adds more insight to Jeremy Wright’s Web 2.0 Companies Need to Scale. As an IT administrator, I worry about the availability of Internet applications that run on the servers that I maintain. Perfection is something that I strive for personally, and I continually think about robust methods that will bring the availability of Web applications closer to 100%.

Although it would be ideal to deploy a high availability configuration, the cost of providing HA might be greater than what can be afforded by small companies. The benefit for small companies is most likely less than what would be gained from larger companies. The move to increase availability should be made after some analyses in a similar fashion that other business decisions should be made. A minimal analysis includes the costs incurred by adopting the move, the costs resulting from outages due to delaying the move, and the amount of change in the expected downtime of a service after the move is committed. Deploying high availability is an investment like any other. The potential gains from these investments should be evaluated before an investment is made.

The idea of waiting to deploy HA until the cost of deployment is less than the loss resulting for service outages is acceptable, but I disagree with the suggestion to wait for high availability to become an issue before giving it consideration. Unless it is cheaper to reimplement an application, scalability is something that must be considered early in the software development process. Although a highly available infrastructure might not be available at the same time that an application is deployed, the application should be engineered for easy introduction into a high availability configuration. Availability is a concern for all successful Internet applications. Developers, with their highly optimistic nature, should plan on their applications becoming successful.

read more | digg story

Polymorphism in PHP

December 8th, 2005

While thinking about a programming language deficiency, I rediscovered polymorphism. Overloading a function allows a function call to behave differently when passed variables of different type. I was trying to devise a method of simulating function overloading, because PHP does not support it. I considered implementing a function with an if-else statement ladder that tests the type of the actual argument and executes statements that correspond to the argument’s type. This technique may ultimately result in a monolithic function or a function implementation that is too knowledgeable of multiple class hierarchies. Rethinking a problem that I was hoping to solve with function overloading allowed me to accept the lack of this language feature and think of other techniques.

There are two problems that arise from the if-else statement ladder approach. The implementation of such a function would require the function to have knowledge of every data type to be used with it. This problem can be extended to knowing class hierarchies, if subclassing is involved. This means that an introduction of a new data type to be processed by the function would require the function to be modified, which creates the possibility that the modification will break other existing code that relies on the function. The second problem is having the function’s maintainer think about how the function should operate on the different data types that can be passed to it. This responsibility is better placed on the people who maintain the different data types.

One solution that deals with the problems in the if-else statement ladder is polymorphism. Polymorphism allows a set of heterogeneous elements to be treated identically. It is achieved through inheritance. In PHP, interface inheritance and implementation inheritance can be written explicitly through the use of interfaces and class extensions, respectively. Interfaces specify a class interface without providing an implementation. Classes from different class hierarchies can implement an interface, and in this way, it can be seen as different from abstract classes. When a class is defined to implement an interface, the language enforces a rule that the class implements all features of the interface. A method that operates on an interface will accept an object of any class that implements the interface, and it will function correctly.

Here is a toy example of interface inheritance, polymorphism, and PHP type hinting:

<?
	interface HasArea
	{
		public function area();
		public function areaUnit();
	}
	
	abstract class Shape
	{
		private $color;
		
		public function __construct( $color )
		{
			$this->color = $color;
		}
		
		public function getColor()
		{
			return $this->color;
		}
	}
	
	class Rectangle extends Shape implements HasArea
	{
		private $w;
		private $h;
	
		public function __construct( $color, $w, $h )
		{
			parent::__construct($color);
			$this->w = $w;
			$this->h = $h;
		}
	
		public function area()
		{
			return ($this->w * $this->h);
		}
		
		public function areaUnit()
		{

			if( $this->area() > 1 )
				return "square meters";
			else
				return "square meter";
		}
	}
	
	class Territory implements HasArea
	{
		private $name;
	
		public function __construct( $name )
		{
			$this->name = $name;
			/* not used in this example... */
		}
	
		public function area()
		{
			return 5;
		}
		
		public function areaUnit()
		{
			return "cities";
		}
	}
	
	function outputArea( HasArea $ha )
	{
		echo "The area is:  "
		 . " {$ha->area()} {$ha->areaUnit()}\n";
	}
	
	$HAs = array(
		new Rectangle("red",2,3),
		new Territory( "somename" )
	);

	foreach( $HAs as $HA )
	{
		outputArea( $HA );
	}
?>

Type hints help the PHP interpreter enforce the restriction that outputArea() operates only on objects of data types that implement the HasArea interface. Rectangle and Territory are from unrelated class hierarchies. outputArea() can operate on these classes, since these classes implement the HasArea interface.

The explored method accomplishes only some of the features offered by function overloading. In the above example, outputArea() was restricted to one argument. In some programming languages, a function can be overloaded on the number of arguments along with the types of those arguments and the order that those types appear in the argument list. This method, however, was useful in a problem I considered solving with function overloading.

Forming and Maintaining Knowledge Workers

December 6th, 2005

A piece in Newsweek by Google’s Schmidt and Varian discusses ten guidelines to hiring and maintaining good knowledge workers. Several guidelines, such as catering to the every need of knowledge workers, are feasible only in thriving companies, but there are a couple of points in the article that are applicable to all companies and have been continually iterated in project management literature. Some of these points are reiterated here.

One of the guidelines discusses the acceptance of a potential knowledge worker into a development team. It seems that Schmidt and Varian promote a series of interviews between a candidate and different members of a team. Interviewers that represent the company should include management, project managers, and potential team members. I have had excellent interview experiences with both Heavy Iron Studios and Amazon.com. I met with project managers and the people with whom I would be working closely. At Amazon, I was able to meet software developers with varying levels of tenure at the company. Allowing a candidate to meet with several people of a company provides more information that a candidate can use to evaluate the company, and it gives the company more opportunities to market itself to the candidate. It is important to remember that job interviews are intended not only for the company to evaluate a candidate, but for a candidate to evaluate the potential employer. More interviews between a candidate and company provide more information that can be useful for both parties in reaching an employment decision.

Another point worthy of mention is the advice to “pack them in.” Effective use of office space is the underlying principle that this guideline promotes. Many people of the traditional mindset are well aware that assigning an office to an individual is a way to grant elevated status to the individual. It makes the company’s appreciation for a worker more visible, and due to its effect on the worker’s morale, it has the potential of increasing the worker’s productivity.

In opposition to traditional office arrangements, Schmidt and Varian suggest that a team work closely together instead of separating team members with office walls. This increases productivity for the entire team by minimizing the cost of communication. This worked pretty well for the quality assurance teams at THQ. QA teams worked in a small area and were able to communicate effectively with each other. This reduced the amount of duplicated work, and it fostered team identity. Office spaces and partitions are most effective when they are used to group people with a common objective and separate groups of people who are working on different projects.

I strongly believe that development team leaders should share the same office space as the rest of the team. There are some gains to such an arrangement as long as it does not degenerate into command style management, where the team leaders are constantly monitoring the activity of each team member. The team will recognize the team leaders more as a member of the team and less of a disconnected authoritative figure. It encourages team members to communicate with their team leads. It also allows team leads to passively monitor their team’s progress. Physical placement of exceptional team leaders within the team will bolster respect from the team members for the leads, and under the direction of respected team leaders as “aggregator of viewpoints,” the team will excel.

As software projects scale to meet growing business needs, the unit of production changes from individual software developers to software development teams. Consideration in forming and utilizing development teams is important to companies, particularly to those that develop applications that are used by people outside of these companies.

read more | digg story