As software becomes more and more part of revenue generation processes in all industrial domains, and as development cycles shorten significantly, the challenges of producing high reliability and quality as well as adhering to shorter time-to-market requirements have hit the software community. As unsuccessful cases demonstrate, the solution is neither to throw unreliable software on the market prematurely, nor to be late with high quality software. The key seems to be choosing the appropriate development model and using development processes in a goal-driven way. There is a big difference between product and process oriented development models. Which one is appropriate under what circumstances?
Another fascinating dimension to this issue is the effect of brand. If you launch a crappy product early, it harms your brand. But this percpetion can be mitigated by calling the product a "beta"! So instead of thinking of it as time-to-market, think of it as a public product test.
So when we think about all of this what strikes our mind is to come up with a process that takes care of both cases i.e quality and time to market.
Agile Methodologies like SCRUM and XP were formed to address these issues and moreover these processes focus more on the product than the process itself. SCRUM, XP have iterations where each iteration adds value to the product and at the end of every iteration you have working code. This is a product centric approach backed by a process that allows flexibilty.
Agile methodology should not be mistaken for Ad-hoc releases where the developers take last minute changes from the client or the customer in order to keep the customer happy and as a result of that ends up breaking the build somewhere else which in turn leads to long working hours and working on weekends. Simplicity is one of the principles of agile and do only what is required.
I would like to end this by stating that getting a product out in a short time frame is not a challenge but getting a product out in a short time frame which is of good quality and something you can be proud of is a challenge.
A product whose foundation is well built is more likely to succeed.
Friday, November 28, 2008
Building Products the Right Way
How many times has it occured to you when you are developing software that is going to be used by millions of people and that you need to deliver something that does cool stuff, looks good , very stable and 24/7 available especially when you are building a product for a company whose future revenues depend upon the product that you ship out!!
Developers sweat it out day and night, weekends and holidays to get the product out as soon as possible but the downside to this is that the quality of the product degrades everytime this approach is taken. Long hours and over working does not contribute in a positive way to anything let alone product development. A developer does not become a team player only if he contributes more hours to the project. Every developer has his or her own style of working and they know their limitations, beyond which any amount of work is unproductive and inefficient.
Product development is not just about developing the software but also understanding how to manage it properly in such a way that things dont go wrong and the goal is met. Long hours and overworking are not the answers in making a product successful.
Developers sweat it out day and night, weekends and holidays to get the product out as soon as possible but the downside to this is that the quality of the product degrades everytime this approach is taken. Long hours and over working does not contribute in a positive way to anything let alone product development. A developer does not become a team player only if he contributes more hours to the project. Every developer has his or her own style of working and they know their limitations, beyond which any amount of work is unproductive and inefficient.
Product development is not just about developing the software but also understanding how to manage it properly in such a way that things dont go wrong and the goal is met. Long hours and overworking are not the answers in making a product successful.
Thursday, September 25, 2008
Nice Read on Clean Code
Hello readers, I happened to find out a nice article on clean code.
Clean Code
check it out and let me know your thoughts and opnions!!
Clean Code
check it out and let me know your thoughts and opnions!!
Monday, June 16, 2008
Which is the hottest Web Framework?
Hello readers this is a question I always had on my mind and I found a post that addresses this question. Check it out!!
http://www.breakitdownblog.com/which-is-the-hottest-java-web-framework-or-maybe-not-java/
http://www.breakitdownblog.com/which-is-the-hottest-java-web-framework-or-maybe-not-java/
Wednesday, June 11, 2008
Do we need a Business Analyst?
Firstly lets understand the role and responsibilities of a business analyst. A business analyst understands the requirements and give possible solutions to a customer problem. They are critical in changing the way the client business is done. They dictate most of the solution. On the technical front they define the functional requirements for the application which allows the developers to follow these requirements. Testing and quality is sometimes done by these analyst. If they do not pass the software it is not delivered to the client.
They interact with the customer frequently and understand the business problems of the customer and sometimes are referred to as functional champions. Developers often get too technical whereas a business anaylst weighs the business side of things as well as the technical nature of the problem.
BA is definitely crucial and important for a project to make critical business decisions and functional changes. A developer may not have a complete and broad insight into the overall business problem of the customer. A developer in the long run can be groomed into a BA as it always good to have a technical background in order to make well informed decisions.
What do you guys think? Any suggestions or opinions are welcome
They interact with the customer frequently and understand the business problems of the customer and sometimes are referred to as functional champions. Developers often get too technical whereas a business anaylst weighs the business side of things as well as the technical nature of the problem.
BA is definitely crucial and important for a project to make critical business decisions and functional changes. A developer may not have a complete and broad insight into the overall business problem of the customer. A developer in the long run can be groomed into a BA as it always good to have a technical background in order to make well informed decisions.
What do you guys think? Any suggestions or opinions are welcome
Friday, May 30, 2008
How to hire the "right developers"?
A very good and tough question dont you think ? Different organizations have adopted different ways of hiring developers however none of their hiring strategies are foolproof. Somehow developers who are not very productive or effective manage to get in. That brings us to the question of how do we solve this issue? I believe that the key to this answer is to hire smart people who can get the job done.
So how would you define Smart? Well thats a tough question!!! But here is my shot at it. Smart in my definition is anyone who can think practically about a problem in hand and provide a practical solution. Smart and getting the job done go hand in hand in fact they complement each other.
Smart but not productive or effective.
You could have someone who is a Phd who is extremely brilliant but all his solutions are practically impossible. People who are smart but don't get things done often have PhDs and work in big companies where nobody listens to them because they are completely impractical.
Does the job but not in the smartest way
A developer who get things done but are not smart will do stupid things without thinking about them and somebody else will have to clean up their mess later. This is really a pain because not only do they not contribute, but they take up a lot of time of the good developers time. They are the kind of people who copy big chunks of code around rather than writing a subroutine, because it gets the job done, just not in the smartest way.
Sometimes its the guys who interview the candidate, they may not be smart enough to conduct the interview in the first place which ends up in bringing more unproductive developers to the organization. On the other hand the recruitment process itself may not be good enough to find out if the candidate is the right one for the job.
Of all the interviews that I have attended so far in my career I rate Thoughtworks recuritment process very highly. They are very thorough in their recruitment process for a developer and they take their hiring very seriously. Every round in their recruitment process for a developer is justified and thats probably why the guys over there are really smart. I know a couple of them and they really know their stuff and they do their stuff really well. This is the best example I can think of when you want to hire the right developers who are smart and gets things done. However I am not saying that their recruitment process is foolproof but its the best I have seen and experienced so far personally. They have a good hiring process in place which brings in smart people who know their stuff and do it really well to the company and they in turn bring more smart people into the company.
So how would you define Smart? Well thats a tough question!!! But here is my shot at it. Smart in my definition is anyone who can think practically about a problem in hand and provide a practical solution. Smart and getting the job done go hand in hand in fact they complement each other.
Smart but not productive or effective.
You could have someone who is a Phd who is extremely brilliant but all his solutions are practically impossible. People who are smart but don't get things done often have PhDs and work in big companies where nobody listens to them because they are completely impractical.
Does the job but not in the smartest way
A developer who get things done but are not smart will do stupid things without thinking about them and somebody else will have to clean up their mess later. This is really a pain because not only do they not contribute, but they take up a lot of time of the good developers time. They are the kind of people who copy big chunks of code around rather than writing a subroutine, because it gets the job done, just not in the smartest way.
Sometimes its the guys who interview the candidate, they may not be smart enough to conduct the interview in the first place which ends up in bringing more unproductive developers to the organization. On the other hand the recruitment process itself may not be good enough to find out if the candidate is the right one for the job.
Of all the interviews that I have attended so far in my career I rate Thoughtworks recuritment process very highly. They are very thorough in their recruitment process for a developer and they take their hiring very seriously. Every round in their recruitment process for a developer is justified and thats probably why the guys over there are really smart. I know a couple of them and they really know their stuff and they do their stuff really well. This is the best example I can think of when you want to hire the right developers who are smart and gets things done. However I am not saying that their recruitment process is foolproof but its the best I have seen and experienced so far personally. They have a good hiring process in place which brings in smart people who know their stuff and do it really well to the company and they in turn bring more smart people into the company.
Thursday, May 29, 2008
AppFuse - Kick start your webapps
AppFuse is an open-source Java EE web application framework founded by Matt Raible. The main objective behind the AppFuse framework was to allow developers to get started quickly and easily using popular Java open-source technologies like Spring framework, Hibernate and Struts to eliminate the initial "start up" time when building new web applications.
AppFuse in its simplest form is a project skeleton that is very generic which is ready to use as a web application with the most basic requirements of a web application. Developers can change the skeleton or use the same setup to add their business logic. AppFuse 1.x uses Ant to create projects, as well as build/test/deploy it. AppFuse projects contain a number of classes and files from the very beginning. These files are used to implement features, but are also examples when developing your application. By using AppFuse to start new projects, it is possible to eliminate the usual first week or two of development time and this is the USP of this framework.
Configuration of open source frameworks have already been done in the appropriate downloaded versions. The AppFuse project is pre-configured to connect to a database, to be deployed in an application server, and allows you to login. Security features that are a must of any web application today are already integrated and only requires configuration if necessary.
AppFuse supports Hibernate, iBATIS or JPA as persistence frameworks. For the web framework, you can use JSF, Spring MVC, Struts 2 or Tapestry. Some of the features that AppFuse comes out of the box with are the following that most application use today:
Authentication and Authorization
User Management
Remember Me (saving your login information so you don't have to login every time)
Password Reminder
Signup/Registration
SSL Switching
E-Mail
URL rewriting
Skinnability
Page Decoration
Templated Layout
File Upload
Check it out guys!!! AppFuse Rocks!! Cheers to Matt for giving us AppFuse.
For More Information on AppFuse project check out the AppFuse Project Website
AppFuse in its simplest form is a project skeleton that is very generic which is ready to use as a web application with the most basic requirements of a web application. Developers can change the skeleton or use the same setup to add their business logic. AppFuse 1.x uses Ant to create projects, as well as build/test/deploy it. AppFuse projects contain a number of classes and files from the very beginning. These files are used to implement features, but are also examples when developing your application. By using AppFuse to start new projects, it is possible to eliminate the usual first week or two of development time and this is the USP of this framework.
Configuration of open source frameworks have already been done in the appropriate downloaded versions. The AppFuse project is pre-configured to connect to a database, to be deployed in an application server, and allows you to login. Security features that are a must of any web application today are already integrated and only requires configuration if necessary.
AppFuse supports Hibernate, iBATIS or JPA as persistence frameworks. For the web framework, you can use JSF, Spring MVC, Struts 2 or Tapestry. Some of the features that AppFuse comes out of the box with are the following that most application use today:
Authentication and Authorization
User Management
Remember Me (saving your login information so you don't have to login every time)
Password Reminder
Signup/Registration
SSL Switching
URL rewriting
Skinnability
Page Decoration
Templated Layout
File Upload
Check it out guys!!! AppFuse Rocks!! Cheers to Matt for giving us AppFuse.
For More Information on AppFuse project check out the AppFuse Project Website
Subscribe to:
Posts (Atom)