Key to successful Software Development

One fine day when I was quite bored with my regular work, I went across to my colleague - Niraj Khatmode’s desk and was discussing about the paper that he was going to present in one of the conferences, later I was distracted by a book that he was reading on his PC before I got there. I asked what this book is all about and as he explained it fascinated me to read it. The book was "Extreme programming explained" authored by Kent Beck. As a programmer its title really impressed me.
I am a programmer since 7 years now and all these years I have been evolving as a software developer; in this evolution I have gone through some good, bad and worse phases of a software development life cycle. All these experiences have thought me certain elements about software development life cycle (SDLC). A chapter from the book “Four variables” talks about those elements.
The elements are very straight forward and are very much dependent on each other. Right dose of each of these elements will lead to successful and satisfied software development.

• Cost
• Time
• Quality
• Scope

When I retrospect and relate these elements with my past projects, I can imagine the reasons behind the good, bad and worse situation that have happened. Software development is a collaborative work between the customer, manager and the executing team and usually the customer and the manager are the forces that manipulate the above elements; however it’s difficult to control all the four elements together because if one increases or decreases the other element has an adverse effect, which means customers, managers get to control any three of the elements while the development team will have to deal with the resultant value of the fourth element. To prove this, let’s consider customer, manager try to control all the four elements by deciding that "you are going to get all these requirements done by the first of next month with exactly this team with a quality that is up to the usual standard”. When this happens, quality always goes down since nobody does good work under too much stress. Also likely to go out of control is time. At the end what you get is crappy software late.
The solution is to make these four elements visible to everyone (customer, manager, and team). This way all can decide and can consciously choose which three elements to control. If they don't like the result implied for the fourth element, they can always change the combination of these elements.
There is not a simple relationship between the four elements. For example, you can't just get software faster by spending more money. As the saying goes, "Nine women cannot make a baby in one month." and on the contrary, eighteen women still can't make a baby in one month.
In many ways, cost is the most constrained variable. You can't just spend your way to quality, or scope, or short release cycles. In fact, at the beginning of a project, you can't spend much at all. The investment has to start small and grow over time. After a while, you can productively spend more and more money. The time element is often out of the hands of the project manager and in the hands of the customer. Quality is another strange element. Often, by insisting on better quality you can get projects done sooner, or you can get more done in a given amount of time. There is a human effect from quality. Everybody wants to do a good job, and they work much better if they feel they are doing good work.
Now I have started believing that the one element that drives the control over cost, time and quality is the scope. As a software developer, I should give more importance to the scope element because If I change/eliminate/manage the scope the managers and customers will get better control over cost, quality and time. It has been fairly observed that developers complain about the requirement not been clear and there is a discrepancy between what we gave them and what they actually wanted, this is an absolute truth of software development. On the contrary as a software developer if you start thinking from the side of a customer you would agree that development of a piece of software, changes its own requirements, as when the customers see the first release they learn what they want in the second release or what they wanted in the first. It’s a learning curve and it’s a valuable learning because it couldn't have possibly taken place based on speculation. It is learning that can only come from experience. But customers can't get there alone. They need people, who can program, not as guides, but as companions
What if as a software developer I see the "softness" of requirements as an opportunity, not a problem?  Then I can choose to see scope as the easiest of the four elements to control because, I can shape it, a little this way, a little that way. If time gets tight toward a release date, there is always something that can be deferred to the next release.
All these controlling elements would make up-to great software and I believe all this can be possible through the agile way of development.

Portal Development Basics Part 1

Portal Development Basics Part 1

If you have been part of application development or even if you are application user for a quite long time now, then you must have sensed that heart of any application is “content”.  As things advanced we realized that “user experience” is important as well. The lack of a standard approach and technology to address user-experience requirements, such as personalization, customization, and content aggregation in web applications, led to ad hoc ways of implementing these features. The result was maintenance nightmares, lost developer productivity, and longer turnaround time for incorporating new features.

With evolving Java portlet technology it allows us to quickly develop a web application providing service orchestration. Java portlet technology it isn’t standalone technique to achieve development, it uses traditional JSPs and servlets to build application along with portlet. On top of that there is MVC frameworks like Spring MVC portlets allows you to develop individual portlets in the Spring technology. This blog shall aid you understand fundamental need of portal development and getting familiar with different aspects of it. Next blog will talk more technically about different standards of Java portlet technology JSR 168 (Java Portlet Specification V1.0), JSR 286 (Java Portlet Specification V2.0).

Portal Overview

A portal is a web based application that comprises of many small web applications called “portlets”. Primary goal of a portal system is to facilitate personalization, authentication, and content aggregation from different sources and hosts the presentation layer of information systems. Aggregation is the action of integrating content from different sources within a web page. A portal may have sophisticated personalization features to provide customized content to users.

To get a feel for portals, you can visit the iGoogle portal (http://www.google.com/ig).  In the iGoogle portal you can see portlets showing emails from Gmail, headlines from CNN, content from YouTube, and so on.

Portlets are not widgets

While looking at iGoogle example you might start wondering what makes portlet different than web widgets as we know today. A developer can quickly develop widgets having some knowledge of Javascript and XML, however Java portlet concepts require deep learning curve to understand its fundamentals. Portlets are well suited for medium to complex application requirements as found in enterprise applications.  

Why use portal?

Quick answer is when you want to develop service oriented architecture. As portlets represent services and are pluggable components, you can get plug and play behavior using portlets. Because portlets can interact with each other at the user interface layer (a process referred to as inter-portlet communication), they play a major role in developing SOA applications. The portlet container is responsible for handling the communication between portlets.

The portal infrastructure, which includes a portlet container and portal server, provides portlet instance lifecycle management, instance pooling, content caching, security, a consistent look and feel, and single sign-on features to your web portal.

Let’s take example of iGoogle portal we talked about. As a user you need to frequently check your emails, browse videos on YouTube, take glimpse of news from news articles and keep updated on technology trends. All of these web applications have their own business requirement and data sources which you will need to browse individually. If we have a single point of entry using a single sign-on feature to allow access to all of these applications then that would be better solution.

Let’s say that as an employee of an organization you need to frequently access organization-specific business-to-employee (B2E) applications (like time card, help desk, knowledge management, and service request applications) so you can keep track of missing time cards, recently published articles, closed help desk tickets, and so on. These different web applications have their own data sources, and you’d usually need to go to each of these different applications to access this information. Certainly this isn’t an optimal way of accessing information and services, because you need to go to different web applications and authenticate each time. An intranet site that provides a single sign-on feature and access to all these different applications would be a better solution.

By providing the single sign-on feature, if the service provider has provided easy access to the B2E applications, but you still need to filter the information that interests. Like if you interested to know more about Java technology trends only. You will have to search for Java articles in primary application. Individual application will have some level of user preference managed as personalization. But ideal scenario for user to have unified view of all services is in single application itself. This is achieved using portal development as seen in iGoogle today.

The portlets can be personalized by users to change the number of emails displayed in the portlet, the number of CNN headlines they want to view, the location they want to receive RSS feeds from, and so on. Users can drag and drop these portlet windows on the portal page to customize the way.

Where portal doesn’t work?

Portals aren’t the answer to every business requirement; organizations should consider carefully whether there is a business case for developing a portal. If the requirement doesn’t require gathering content from distinct information systems to loosely integrate disparate systems, the business should consider developing independent web applications to meet the business requirement. The personalization and customization features of portals are important from the user’s perspective. From the business’s perspective, the most important requirement to consider is content aggregation.

Reference

Portlet In Action