Software maintenance is an important part of the software development activity, but it is also the less discussed. As an example of its relative importance, you could just compare the space occupied by "software maintenance" and "test driven development" in Wikipedia (and I have nothing against TDD). Furthermore, software maintenance is a topic that is mostly discussed by university scholars and no practitioners. Have you ever heard of a software maintenance guru or agile software maintenance?
The main theory is that maintenance is "just" like software development on existing systems and does not need particular approaches or skill. Anyone who has spend time trying to understand an existing program or an architecture that has been twisted during some years knows that this activity is different from new projects.
Our last poll wanted to know what percentage of your software development budget was devoted to maintenance. Maintenance is defined as the process of correcting, enhancing and optimising deployed software. Here are the answers:
25% or less of the budget ...........37%
26% to 50% of the budget ............27%
51% to 75% of the budget ............24%
more than 75% of the budget .........12%
Number of participants: 433
The annual maintenance costs in the US are estimated at over $ 70 billion. According to the different studies produced in the last century, maintenance should cost between 66% and 90% of the total life cycle costs. We can see in our survey that the majority of the participants estimate their maintenance budget below the 50% threshold. If we accept that these numbers are representative of a modified situation, many hypothesis can be made to explain it.
The adoption externally developed software (like ERP) for the large enterprise application has replaced the in-house development of the last century. Thus, a large part of the maintenance budget could be displaced to the licence area. This could also push the development teams of participating organisations to work on smaller applications, so there is less maintenance because this type of software is more easily replaced, especially in the Web world. The new technologies (Web, services) could also explain the lower level of maintenance spending. Many organisations are currently redeveloping applications to use these new technologies, freezing in the meantime the evolution and spending on existing software. The rapid evolution of Web technologies reduces the life expectancy of application and therefore the maintenance budget. Even if the backend remains unchanged, there has been a many evolutions / redevelopment from the initial static Web to the current Rich Interface Application trend. Finally, the outsourcing of maintenance activities to lower cost countries reduce proportion of the maintenance part in overall software development costs for organisation that locates new development in the US or Europe, where the majority of the Methods & Tools readers are.
Resources and numbers on maintenance:
Software Maintenance Costs
A software maintenance survey
Software Maintenance As Part of the Software Life Cycle
A Study in Software Maintenance
Software Maintenance and Evolution: a Roadmap
Measurements to Manage Software Maintenance
Evolution or Maintenance of Quality Software: An exploratory interview study in nine Swedish organisation
Tuesday 30 October 2007
Tuesday 23 October 2007
BEA Systems vs Oracle: the Players and the Eventual Winners
The offer made by Oracle to buy BEA Systems for $17.00 a share (total value $6.6 billion) is one that could change the current state of the software development market. Currently BEA Systems board is refusing the proposal, stating that it undervalues the company. The stock market thinks also that the price could be higher as the closing price of BEA shares last week was above $18, even is some analysts declared that Oracle proposed price was high.
What benefits could Oracle achieve with this deal? Technically, it will acquire Web server and transaction monitoring software expertise. Even if Oracle has already its own set of products competing with BEA Systems, its technical reputation is a little bit lower in this area. Financially, the acquisition could provide additional revenues, a strategy Oracle has followed these past years with PeopleSoft and other targets. In this area, Oracle seems to transform itself in a Computer Associates-like company, more driven by financial interests than technical capabilities.
Even if it is only a "mid-size" company, BEA Systems is not a small fish in the software market and there are not many companies that can afford to buy it. So what are the other players that could enter this game? Oracle main competitor, SAP, has just announced the acquisition of Business Objects and is usually looking for more business oriented targets. IBM could be interested, but then there is many products overlap between the two companies that will make integration difficult. HP could be another possible acquirer, as it is currently trying to increase the software part of its revenues. Its interest will depend on the price to pay and how its current digestion of former acquisitions like Mercury and Peregrine is progressing. Finally, Computer Associates could also jump in the process if the price is right, but this is difficult as BEA Systems has not released audited financial figures for a long time, due to stock option issues.
In the winners side of this situation, we could certainly find IBM and JBoss, as uncertainty about the future of a company is always a strong topic that buyers will consider when the look for their Web server. Losers will be BEA Systems customers, because company executives will be distracted by the battle and that a change of ownership always rise questions on the future roadmap of the products and the availability of knowledgeable people to provide some support.
There are many probabilities that the following actions of Oracle proposal will be on the financial area. It will be interesting to see if BEA Systems shareholders will resist selling their shares and if Oracle will slightly increase its price so that everybody could look satisfied at the end. Hint: Oracle rarely takes "no" for a correct answer to its bids.
What benefits could Oracle achieve with this deal? Technically, it will acquire Web server and transaction monitoring software expertise. Even if Oracle has already its own set of products competing with BEA Systems, its technical reputation is a little bit lower in this area. Financially, the acquisition could provide additional revenues, a strategy Oracle has followed these past years with PeopleSoft and other targets. In this area, Oracle seems to transform itself in a Computer Associates-like company, more driven by financial interests than technical capabilities.
Even if it is only a "mid-size" company, BEA Systems is not a small fish in the software market and there are not many companies that can afford to buy it. So what are the other players that could enter this game? Oracle main competitor, SAP, has just announced the acquisition of Business Objects and is usually looking for more business oriented targets. IBM could be interested, but then there is many products overlap between the two companies that will make integration difficult. HP could be another possible acquirer, as it is currently trying to increase the software part of its revenues. Its interest will depend on the price to pay and how its current digestion of former acquisitions like Mercury and Peregrine is progressing. Finally, Computer Associates could also jump in the process if the price is right, but this is difficult as BEA Systems has not released audited financial figures for a long time, due to stock option issues.
In the winners side of this situation, we could certainly find IBM and JBoss, as uncertainty about the future of a company is always a strong topic that buyers will consider when the look for their Web server. Losers will be BEA Systems customers, because company executives will be distracted by the battle and that a change of ownership always rise questions on the future roadmap of the products and the availability of knowledgeable people to provide some support.
There are many probabilities that the following actions of Oracle proposal will be on the financial area. It will be interesting to see if BEA Systems shareholders will resist selling their shares and if Oracle will slightly increase its price so that everybody could look satisfied at the end. Hint: Oracle rarely takes "no" for a correct answer to its bids.
Wednesday 3 October 2007
A "Bones" Approach for Dead Projects
Rest In Peace (from Latin requiescat in pace) is a sentence that typically appears on christian tombstones. Software development projects have usually the same destiny. Once they are finished, often the best thing that will happen is a little celebration for the project team. Nobody will formally look back at a project to understand what went well or wrong and why those things happen, so that this project can actually rest in peace and lessons learned could be used for the next projects. There is however an activity to analyze project after their completion. It is called "post mortem" analysis (so the RIP reference is not far) or "retrospective" in the agile approach. If you have not heard about this practice or never performed such activity, you should not be ashamed. I have never seen its implementation in my software development life. Even in the last Agile survey published by Version One, where a large majority of respondents are using an agile approach, only 39% of the participants are using this practice. Why?
The first explanation is that time is a rare resource in software development organizations. It is often associated to money in budget-driven companies. As there is a sense of urgency, people try to use their available time for the more essential (for them) activities. It is sometimes already difficult to justify taking some time to think before coding, that trying to have time to think after coding could seems an utopia. It is also difficult to tell as a project leader that you will spend some man/days after the project's completion to think about what went wrong. Are you not supposed to do things right in the first time?
Our difficulty to create a context for constructive criticism is another issue faced when you try to institute some "post mortem" reflections. This is mainly due to the difficulty to separate the problems from the people that are associated to them. This is an important issue in organizations where professional excellence is a driver for monetary gains and career evolution. Will you speak openly about project problems if part of your (or your colleague) salary is a bonus linked to achieving certain professional goals? Maybe not...
There are however techniques that could help you to profit from lessons learned without creating personal issues, so that your past projects could really rest in peace and everybody could improve from a shared experience. You will find more resources about post-mortem or retrospectives for software development projects in the following articles:
* Refactoring Your Development Process with Retrospectives by Rachel Davies (HTML)
* Retrospective Agility by Tim MacKinnon in Objective View issue #8 (PDF)
* Plan of Action by Bas Vodde (HTML)
* Project "Post Mortem" Review Questions by Michael Greer (HTML)
* A Review of Small and Large Post-Mortem Analysis Methods by Mauri Myllyaho1 et al. (PDF)
The first explanation is that time is a rare resource in software development organizations. It is often associated to money in budget-driven companies. As there is a sense of urgency, people try to use their available time for the more essential (for them) activities. It is sometimes already difficult to justify taking some time to think before coding, that trying to have time to think after coding could seems an utopia. It is also difficult to tell as a project leader that you will spend some man/days after the project's completion to think about what went wrong. Are you not supposed to do things right in the first time?
Our difficulty to create a context for constructive criticism is another issue faced when you try to institute some "post mortem" reflections. This is mainly due to the difficulty to separate the problems from the people that are associated to them. This is an important issue in organizations where professional excellence is a driver for monetary gains and career evolution. Will you speak openly about project problems if part of your (or your colleague) salary is a bonus linked to achieving certain professional goals? Maybe not...
There are however techniques that could help you to profit from lessons learned without creating personal issues, so that your past projects could really rest in peace and everybody could improve from a shared experience. You will find more resources about post-mortem or retrospectives for software development projects in the following articles:
* Refactoring Your Development Process with Retrospectives by Rachel Davies (HTML)
* Retrospective Agility by Tim MacKinnon in Objective View issue #8 (PDF)
* Plan of Action by Bas Vodde (HTML)
* Project "Post Mortem" Review Questions by Michael Greer (HTML)
* A Review of Small and Large Post-Mortem Analysis Methods by Mauri Myllyaho1 et al. (PDF)
Subscribe to:
Posts (Atom)