Software development methodologies have been around for quite some time. In the 1980s, the buzz around computer aided system engineering (CASE) tools was huge. Companies invested millions of dollars in CASE tools that promised organized and efficient ways to manage the complete software development life cycle, including code generation and much more. Well-known industry figures such as Peter Coad, Edward Yourdon, Grady Booch, James Rumbaugh, and James Martin have also shared their wisdom on managing software development projects successfully.
Technologies such as JavaServer Pages and servlets, Enterprise JavaBeans, XML, architecture and design patterns, application servers, integrated development environments (IDEs), and related technologies keep pushing rapid application development as far as it will go; to some extent, this drive renders traditional methodologies obsolete. People want instant gratification, and long, drawn-out software development approaches no longer work. Nowadays, software development iterations are sometimes discussed in terms of weeks, not months.
RUP and XP
During the past couple of years, the two most popular methodologies to emerge are the Rational Unified Process (RUP) and Extreme Programming (XP). RUP, according to many developers, is too cumbersome, and XP isn't suitable for serious projects. Some people would go so far as to say that XP is for hackers and RUP is for humongous projects and not realistic for average-sized project teams (i.e., four to six developers). There are also companies that employ a blend of the two, with RUP cycles and phases, and XP pair programming and testing.
In addition to RUP and XP, several other methodologies are used in the industry, such as ADM Scrum and Agile Modeling. Of course, many project-based IT services companies have homegrown methodologies of their own. Either way, IT services companies (e.g., solutions integrators, consultants) have done well financially helping clients adopt some form of methodology.
The problem with methodologies, processes, and CASE tools to date is that they are too rigid and bureaucratic, and simply do not factor in key aspects of the development process, such as personnel issues. It never ceases to amaze me how many projects fail even after large amounts of money, time, and resources are pumped in to make them successful. Often, after a project has completed, companies realize that they ignored many common sense issues, which led to the project's failure.
At the other extreme, I have seen both small and large companies follow absolutely no process beyond considering such basics as development tools, a source code controls system, and separate environments for development and production. While I have never been a fan of bureaucratic processes, I have always believed that the entire development team needs at least a simple framework or road map to follow. These days, a simple framework or checklist is about all you can expect people to absorb given the lack of time, energy, or talent available.
Is there a clear solution?
Why do so many projects still operate in a chaotic fashion or fail even after well-defined processes are established and implemented? In my opinion, there are several key reasons.
First, one of the most obvious problems is lack of communication with the customer. I strongly believe that frequent verbal and written communication with the customer is essential to keep everyone in the loop at all times.
Second, many projects do not follow the iterative development approaches advocated by methodologies such as RUP and XP. These approaches emphasize smaller deliverables that constantly update customers on their projects' progress and help keep them on track.
Third, members of a development team often lose sight of the company vision and the key problem the software project is trying to solve for the company. In my opinion, the fundamental principle behind information technology is that it should be "technology for managing information." In other words, it all boils down to moving data from point A to point B. The data starts with people (e.g., data entry) and at some point will end up with people (e.g., queries/reports), regardless of how many systems the data will travel through or how much it is manipulated along with the way.
Here are some questions I would like you to consider:
- Which methodology, if any, do you follow?
- What are your thoughts on RUP?
- What do you think is needed for software development projects these days?
- Do you believe a distilled version of RUP (or another methodology), in the form of a checklist and templates, is the answer?
- Would add-ins for specific technologies (e.g., Java 2 Enterprise Edition) be helpful?
- Is there a need for patterns in methodology (similar to architecture and design patterns)?
Discuss your thoughts in the iSavvix Soapbox forum for this column.
Please remember this is a "soapbox" column; that is, this column is not intended to answer all questions but rather open a dialogue on issues described in each column and get feedback from readers.
Learn more about this topic
- ADM Scrum
- Agile Modeling
- Extreme Programming
- Headstrong (formerly James Martin et al.)
- Rational Unified Process
- ThoughtWorks Methodology
- "Are Smart Coders the Enemy?" JavaWorld forum members voice their doubts about XP, (JavaWorld, April 2001)
- An index of Anil Hemrajani's Soapbox columns
- Browse the JavaWorld Topical Index
- Sign up for JavaWorld's free weekly email newsletters
- You'll find a wealth of IT-related articles from our sister publications at IDG.net