Are Unified Modeling Language (UML) Models Still Used?

The Agile approach prefers face to face communication between developers and user. User stories could be specified in simpler artifacts like index cards rather than put larger requirements documents. Does this impact the usage of UML models?

A recent Methods & Tools survey tried to evaluate the usage of UML tools in organizations.

http://www.methodsandtools.com/dynpoll/oldpoll.php?UMLPoll2

Agile + Software Testing & Quality in Methods & Tools Spring 2010

Methods & Tools is a free e-magazine for software developers, testers and project managers. Spring 2010 issue has just been published with the following articles:
* Using WatiN to Leverage Common Elements in Web Testing – structure your Web testing efforts
* Five Symptoms of Mechanical Agile- detect agile adoption issues
* Writing Testable Code – testable code is better code
* Model-Based Testing Adds Value – a quicker way to functional testing plans
* Tool: Sonar – monitor code and project quality
* Tool: Express Agile Project Management – a simple tool for Scrum
* Tool: Apache JMeter – for load and functional testing

60 pages of software development knowledge that you can download from http://www.methodsandtools.com/mt/download.php?spring10

Review of 2009 for Software Development: Many Acquisitions and a Funeral

Last year has certainly been busy for the software development tools industry. We have seen many companies merging together and also the funeral of one of the oldest brand in the software development industry.

Bye, Bye Borland

After the sale of its development tools division to Embarcadero in 2008, Borland kept only the tools dealing with requirements management and software testing. This didn’t improve its financial situation and finally Borland sold itself to MicroFocus. This was a sad end for a brand that accompanied software developer for more than 25 years. Software requirements have always been a secondary topic in the software development tools world and the trend towards agility hasn’t improved this. Now you can manage user stories with paper cards and a board. Approaches like UML are declining and you will find few items dealing with them in today’s programmers waterhole like dzone.com or stackoverflow.com, The end of Borland is just the symptom that this world is difficult for requirements tools vendors.

Oracle Buys Sun, WMware Buys Spring and You Buy Software

With a little bit of irony, just one year after having bought MySQL, Sun was acquired by Oracle. It is difficult to judge a deal that is not completed yet as the European Commission is still examining the merger. I am however afraid that the business and financial objectives of Oracle will largely lead to the reduction or the end of most of the Sun open source efforts and a serious slowdown in MySQL evolution.

Just after the future of Java becomes a topic of discussion after the deal between Oracle and Sun, WMware decided to acquire SpringSource and to give to this entity a stronger platform to promote the Java language. Since then, SpringSource has launched its Tomcat server version, Enterprise Java Cloud and Spring Roo. Previously it had acquired G2One at the end of 2008 and thus the control of the Groovy and Grails products. It is now surely the most important active player for Java software development tools.

Google is (also) a Software Development Tools Company

Google domination in the search engine world is well known, but as far as developers are concerned, it is amazing how Google is quietly occupying more and more space. Here are some of the software development initiatives of Google:
* Google App Engine
* Google Web Toolkit GWT
* Go Language
* Google open source projects forge
* Google I/O Conference

Google seems to have understood that besides the content, it should also be active in the plumbing that runs the Web. This is why software developers should be interested in what Google does in this area. You could do this following some blogs like the Google Code Blog and the Google Testing Blog. You will see that besides the well-known projects, Google releases a lot of interesting open source tools created by its development team.

Spring 2009 issue of Methods & Tools

Methods & Tools is a free e-newsletter for software developers, testers and project managers. Spring 2009 issue’s content:

* How to Build Articulate Class Models and get Real Benefits from UML
* When Good Architecture Goes Bad
* Finding a Partner to Trust: The Agile RFP
* Database Locking: What it is, Why it Matters and What to do About it
* Code Generation for Dummies

80 pages of software development knowledge that you can download from
http://www.methodsandtools.com/mt/download.php?spring09

Unit Testing Still Widely Informal

A recent Methods & Tools poll examined how organizations perform unit testing. Is it an informal activity that is done before integration if there is some time left after programming or is it the key element of the development effort? The question was: How is unit testing performed at your location?

Proportion	2008	2006
Unit testing is not performed	17%	13%
Unit testing is informal	40%	46%
Unit tests cases are documented	9%	11%
Unit tests cases and their executions are documented	14%	16%
We use a Test Driven Development approach	20%	14%

Participants: 384 (2006:460)

Ending date: October 2008 (February 2006)

Despite the fact that the number of TDD adopters has grown nicely since the previous survey, you can notice that unit testing is still widely conducted in a informal manner, when it is not simply ignored by developers. This could sound weird when many people announced a general adoption of the agile approaches, but the results of our survey are similar to many other polls on the same topic.

Comparing the two surveys, it seems that people that were already doing unit testing formally have switched towards a TDD approach. People that don’t do unit testing have different reasons. Some will consider simply that they don’t add value to their development process, which is sometimes difficult to believe. For others, it is the lack of time, a reason more easier to understand ;o) Many complains that unit test are hard to write, but creating a good unit test is a proof that you understand what your code should do. I agree however, that it could be difficult to maintain large libraries of unit testing scripts if requirements are changing constantly. In the “good” reasons not to perform unit testing, some thinks for instance that the client side of Web application is not suited for this kind of tests. There are also some organizations that have separate testing teams. Their developers will rely entirely on the QA guys to test their application. You can also consider that when the software has a very limited life expectancy, it is not worth making unit tests.

New Software Development Links Directory

SoftDevLinks.com is a new general directory for software developers, testers and managers. If you have a blog, a web site, distribute a tool or work a consulting company related to software development, do not hesitate to add a (free) link in this directory.

More than 1000 articles in Software Development Articles Directory

The Software Development Article Directory has now more than 1000 articles in its database. This directory references knowledge-providing articles related to all software development activities (programming, testing, configuration management, process and project management) selected from the best sources on the web.

Some of the last interesting additions to the directory are
* Must-have tools for HTML, JavaScript and AJAX development and debugging
Use the best open source tools to work with Web pages, scripts, and styles, and make development of new sites and pages easy.

* Schedule Adherence: A Useful Measure for Project Management
This article utilizes the new practice of Earned Schedule (ES) to discuss a proposed measure for further enhancing the practice of EVM. The measure, Schedule Adherence, provides additional early warning information to project managers, thereby enabling improved decision making and enhancing the probability of project success.

* Focus on Value: How to create value-driven user stories
Agile has a tool that can help organizations re-focus on return on investment: value-driven user stories. Value-driven user stories are created specifically to link features with their users and the value the features have for their users. They can be created from a list of high-level features or a list of values and users centered on a general idea.

Can We Develop Agile Software in Traditional Organizations?

As it was confirmed by a recent Methods & Tools survey, the adoption of agile approaches has been increasing recently. Following these results, I asked software practitioners on different discussion forums to share their opinion about the substance of agile adoption. As agility is now becoming “trendy”, we could see a number of organizations that will qualify now themselves as “agile”, without implementing the essence of the agile software development practices.

The fact that everyone could have its own definition of “Agile” is not upsetting. After all, agile groups different approaches like extreme programming, scrum, test driven development, feature driven development etc. The problem is that people will now adopt the “agile” badge as they could have been doing “RUP” before, just because it is the “right” answer. Besides this, the main obstacle to true agile adoption is the organizational context existing in large companies or governments agencies. As a participant cleverly says, it is difficult to transition from a “Command & Control to a Collaborate & Communicate structure”

Lack of documentation and control are the weaknesses the more often associated to the agile approaches. The truth is that agile recommends “just enough” documentation which could be different if you are developing a web site or medical device software. Short iteration could be considered as a very good tool to control project evolution and fight the “99% complete” syndrome that reveals many project failures. Practices are therefore not obstacles to agile adoption, but it is rather the environment where its culture should be living that makes successful implementation difficult.

The main issue faced by agile approaches is the traditional management vision of the software development projects. Drawing from the engineering perspective, many organizations wants to specify a solution and then estimate the time and budget needed to realize it. I suppose that you would not commit to build a new house without a detailed plan and a budget. Many managers don’t act differently when they have to invest in a new software system. The agile approach requires relinquishing the (illusion of) long-term control to accommodate changes during the project. We have a long history of organizations signing off projects knowing that the probability of getting the initial requirements for the budgeted price is very low, and this is also true for other domains than software development. People don’t ignore this situation, but the buyer mainly uses the project “contract” as a protection mechanism against criticism. On the other side, many sellers use the proposal only to get the contract signed, hopping to bargain about price and functions after the project has begun. We are sadly often more dealing with organizational politic than honest human relationships. This has caused often a situation of distrust between users and developers and transition open collaborative development is difficult. Users are reluctant to abandon the situation when they think they should know at the beginning of the project the answer to the question: “how much will I pay for what”. If things started to go wrong, managers don’t want to find themselves explaining to their boss that they started a project with a lot of (assumed) uncertainty.

The final question is: should we adapt organization to approach or adapt approach to organization and people? I support the agile trend to change the user-developer relationships, but I doubt that this will be a quick and easy goal to achieve, moreover in large organizations where the political aspect is more important. We should therefore keep in our toolbox different approaches to suit diverse organizational contexts.

Wise Iteration

A you move ahead, keep in mind the following:

* Never confuse the map with the journey - The project plan is only an outline (and a guess at that), so you should believe the team’s results and not the plans. Remember, it is the achievement of the objectives that is important, not the production of artifacts or the completion of activities. Be careful not to confuse the ends (objectives) with the means (artifacts and activities).
* Adopt the attitude that continuous planning is a good thing - In every iteration, expect your plans to change (albeit in small ways if your planning is effective). Don’t fall into the trap of thinking that the plan is infallible.
* Mature your process alongside your team - Tune the working practices alongside the plans, adapt your team’s skills as necessary to improve over time.
* Be prepared to cut your losses - Canceling bad projects early is success because you save time, money and resources that can be applied to better opportunities.
* Be honest - Without objectivity and honesty, the project team is set up for failure, even if developing iteratively.

Source: “Managing Iterative Software Development Projects”, Kurt Bittner, Ian Spence, Addisson Wesley.

Transitioning from a traditional approach to iterative software development is more a change of mind than a schedule adjustment. So try to be honest… or at least as honest as you can be ;o)

Agile Software Development: True Adoption or Just a Label?

At what stage is the agile approach (XP, Scrum, TDD, …) adoption at your location? (2005 results)

Not aware 13% (26%)
Not using 13% (16%)
Investigating 14% (14%)
Analysed and rejected 4% (3%)
Pilot projects 8%(4%)
Partial implementation (adoption of some agile practices) 17% (17%)
Partial deployment (some projects are using this approach) 14% (12%)
Deployed (all new projects are using this approach) 17% (8%)

Participants: 512 (232)

Ending date: February 2008

Source: Methods & Tools

Comparing the 2008 and 2005 results, we could notice that the level of ignorance of the agile movement has decreased, as only 13% of the organizations are ignorant of it. Full deployment numbers have doubled in the recent years to reach 17% and total rate of various adoption levels is now 56% compared to 41% in 2005. This growing adoption rate has also been confirmed by other surveys on this topic. Some critics will naturally discuss the “scientific” nature of this kind of surveys, but I believe that they are useful to give us an idea of the evolution of the software development world. The increased popularity of agile is also visible on the Indeed job request trend.

The recent improvement in agile software development process visibility and acceptance should however make us cautious with the current results on agile adoption surveys. When software development practices are more widely accepted, the number of adopting organizations increases, but the substance of valid usage of this practices decreases. The answers to surveys tend then to be biased towards what should be the correct answer instead of reflecting the reality of the software development context. The tendency of upper management to “push” new approaches to people who are more reluctant to change their old habits does usually not produce good results. This is even truer when projects will not be given additional resources to support the transition.

We are therefore transitioning from a period where agile adoption level may have been underestimated to another where it could be overestimated. Previously, some developers would not define their practices openly as agile or extreme programming because manager would have considered it a “cow-boy process”. A 2006 Forrester’s report found that agile adoption in the US and Europe was 17% according to a survey of 1078 IT decision-maker. They however precised that ” because Agile processes are often adopted at the grassroots level, they frequently fly below the radar. This makes it unlikely that a single IT decision-maker knows what methodology every development team is using. For this reason, Forrester believes that Agile adoption is actually higher than reported in this study.” Today, some companies will pretend that they are agile, but without implementing the essence of the approach.

It is also interesting to notice that the rate of rejection is similar in both surveys. This means that the percentage of companies completely opposed to agile practices is still very low. We could also see that the proportion of companies that are in a partial implementation state is still superior to those who are in partial deployment. This confirms that organizations prefer to adopt agile practices by gradually shifting their process towards agility instead of choosing a big bang implementation. Agility is about iteration and incrementation and this should be also applied to process changes.

When compared to other surveys performed in 2007 on agile adoption, the results of the Methods & Tools poll are equivalent. The adoption rate of participants is slightly inferior with 56% (48% without pilot projects) compared with 73% for the VersionOne survey and 69% for the Scott Ambler survey. Our percentage of organizations having deployed agile approaches in all projects stands at 17%, which is very close to the 15% rate that VersionOne presents for 100% agile adoption.

The importance of the agile approach is surely growing in the software development community. It remains to be determined, with an unbiased perspective, how this evolution will translate in the rate of software development project successes, because at the end, this is what matters the most.

Other agile deployment surveys and agile adoption material

Indeed.com Job Trends for: agile, scrum, “extreme programming”, “test driven”

VersionOne 2nd Annual “State of Agile Development” Survey (2007)

Scott Ambler Surveys (2007)

Scott Ambler Surveys Presented in Dr. Dobb’s (2007)

Scrum Alliance Membership Survey Shows Growing Scrum Adoption and Project Success (2007)

TDD Survey Results by Stelligent (2007)

Boston Roundtable Survey Results by Stelligent (2007)

Agile Project Management Tooling Survey by Trail Ridge Consulting (2006)

Corporate IT Leads The Second Wave Of Agile Adoption by Forrester (2005)

Waterfall Manifesto Agile Software Development Adoption Poll (ongoing)

Slowdown in ScrumMaster (CSM) Certifications?

Low Scrum Adoption Rate in German-speaking world?

Adopting an Agile Method

Agile Delivery at British Telecom - A case study on Agile process adoption

Sharing Trough Implementation Patterns

The thing I like about the pattern form is that it gives you a way to talk about the motivation for what you are doing. So there is a lot of Java style books, and good ones, out there people with lots of experience, people who've thought carefully about how to program, but when I read them what I hear is a set of commandments, "Name variables like this, arrange your code like that, etc" and all those are good things to do in certain circumstances, but what doesn't ever come true for me is why? What's the context, what stage needs to be set before that's the right thing to do, and what are the consequences? If I do that what other thing should I do so that the whole system works well together? So there are different personal styles.

People come to those styles because there are a bunch of decisions that work well together. Taking one bit of that out and using it isn't necessarily working well. So by writing a pattern kind of format I get a chance to say: "How do you name fields?" Well, let's see. What are all the things that you might want to communicate? What things might a reader be interested in if they are reading a name of a variable? What are all the constraints on naming, both in terms of like cognitive constraints. Abbreviations don't work well for a variety of reasons, but why? Really long names don't work well, but why? By writing in terms of patterns I get an opportunity to think about all of those. Here is my rule for naming variables, to use simple names that describe the role of the variable in the computation, but if I just said that as a commandment, someone could copy that, but they don't really get it in the same sense that I care about, and more importantly when that is not the right rule, they don't get any sense of what thinking was behind that rule, so they don't know when to break it.

Source: "Kent Beck on Implementation Patterns" on infoq.com

The main point in Kent Beck's words is that you cannot use software development methods and tools without knowing the context in which you should use them. Every time you find something interesting and new, you should ask yourself why and when you could use it, and why and when you should not use it.

Agile Software Development. Cooler Heads Must Prevail

I have been distraught at the level of dogmatism, bigotry, contempt, or just plain ignorance that I witness in the agile world. I am not blaming the topnotch agilistas, though they sometimes, and just for effect in writings and presentations, reduce their messages to their essential bones, to the slogan level, and they omit the context—both source and applicability.

As agility is crossing the chasm, however—as you can see if you attend any big software synod such as SD East or West or OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications)—many more people say (or repeat) rather uninformed messages with a strong conviction and little background, scoffing at anybody who dares to question their claims, even if it’s just a clarification about scope or context.

For writing these words, I’ll be shot dead as a traitor to the agilism cause, a defender of the waterfall church, a dinosaur, the über-curmudgeon, though I do value agility or agile practices in the proper context, and with the tainted glasses of my own 33-plus years of experience. But I would like my friends and colleagues to keep cooler heads, to question assumptions, not assume too much of a common, shared mental model, and contextualize what they hear, read, say, or write.

Source: Philippe Kruchten, Voyage in the Agile Memeplex

These are word of experience from Philippe Kruchten. It should be repeated that there is no silver bullet in software development and that many approaches will fail in specific contexts when their essence is not understood, but rather people are just trying to apply some recipes without intelligence and common sense. Every new approach will have its share of zealots that will apply them as strict religious rules. I am a strong believer that the success of software development depends more on adapting existing tools and processes to specific situations and not the contrary.

New Software Development Jobs Board - Free Job Posting Until January 15, 2008

Software development jobs for programmers (java, .net, c/c++, cobol, php, ruby, xml, javascript), software and business analysts (UML), user interface specialists (ajax, flash, silverlight), project managers (RUP, agile approaches), database administration (oracle, sql server, db2, mysql), software configuration management and system administration.

Get additional visibility as your postings will be reproduced in Methods & Tools issues and will reach a worldwide community of more than 50'000 software development professionals. Distribution: Asia 37%, North America 27%, Europe 23%, South America 8%, Africa 3%, Australia 2%.

http://www.softdevjobs.com/

New Software Quality Assurance Portal

The Software Quality Assurance Zone is a repository for resources concerning software testing (unit testing, functional testing, regression testing, load testing), code review and inspection, bug and defect tracking, continuous integration. The content consists of articles, news, press releases, quotations, books reviews and links to articles, Web sites, tools, blogs, conferences and other elements concerning software quality assurance. Feel free to contribute with your own articles, links or press releases.

Lower Software Maintenance Period?

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

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.

Doctor Beck and Mister Dilbert

Following a dzone.com link, I reached an article accompanying a presentation made by Joe Rainsberger at the Agile 2007 conference. This article, "My Greatest Misses: XP 2000-2007", is an honest experience report on the many issues and failures met by Joe Rainsberger as an agile change agent during these years, trying to teach others the merit of the extreme programming approach created by Kent Beck.

Seeing an agile coach admitting publicly its weaknesses dealing with people is an ironic situation that makes it an easy target to criticise agile approaches. If I would have like to add an additional "dark" humour remark, I would have said that the advantage of agile approaches above other processes is that they at least recognise their difficulties to deal with the "people factor", as I never saw this kind of report from a RUP consultant. But I am not so bad. Or am I? ;o)

More seriously, I found that this presentation is a very courageous step from Joe Rainsberger. It is not easy to admit and talk about the problems he met as an agile coach, as it is always difficult for us to recognise our mistakes, without even thinking to make a public presentation about them. Joe Rainsberger does this very sensibly, as he does not blame other people for its own failures, a practice we too often follow. In my opinion, the main message in this article is not about the agile approach, but about changing software development people and organisations. This paper summarises very well the problems we could all face when we try to implement a new approach or a new tool in an organisation. We would like to find enthusiastic people who want to improve their work context and believing in the solutions that we are offering them to achieve this goal. The truth is that we work more in a dilbertian universe as describe in the Waterfall Manifesto, than in an agile paradise. In the reality, there are many reasons for developers to prevent change, to choose other solutions that the one we provide or simply to change at a different (read slower) speed that what we would like them to do it. I am always dubious when people advocates a "big bang" and "all or nothing" change strategy as this has in my opinion many chances to fail (we could have another interesting discussion about the differences between the "appearance of change" and the "reality of change" in an organisation...). There are some situations (very serious crisis, above average people) where change can happens more easily and quickly. However, in medium and large size organisation, you will found that change could only happen gradually and often "imperfectly".

Joe Rainsberg's paper should remind us that it takes many iterations to implement change... and to become an agile coach. Thank you Joe for sharing openly this experience with us, keep on your work and I am looking forward to read in 2014 what you will have learned again in the past seven years.

More than 500 Software Development Tools

The Software Development Tools Directory has just registered its 500th tools. This web site regroups both open source and commercial tools used to develop software. Companies and open source projects can also post news about their activities. If you are active in the software development tools sector, do not hesitate to register and to contribute.

If You Can't Beat Them, Join Them !

August 13th, Borland's subsidiary CodeGear announced JGear™, a set of specialised plug-ins for the Eclipse open-source development platform. JGear augments Eclipse in three areas - Java application performance, visual development and team collaboration. According to CodeGear, the top pain points for Java developers using Eclipse stem from the difficulties of application performance tuning , Java code archaeology, coding and configuring Java servers and frameworks, team collaboration

The new JGear product line includes - JGear™ Performance for Eclipse, JGear™ LiveSource® for Eclipse, and JGear™ Team for Eclipse (both Client and Server editions). JGear Performance contains a variety of performance and tuning features such as memory and CPU profiling and debugging; automatic detection of potential memory leaks; and real-time monitoring of programs' use of virtual machine memory. JGear LiveSource includes a graphical EJB workbench and Web services designer; Unified Modeling Language visualisation of code artefacts and design for analysing an application's design and implementation; CodeGear's LiveSource technology that simultaneously replicates changes to models in the code and vice versa to aid alignment between software architects and developers; and creation of Enterprise JavaBeans and model relationships. JGear Team offers a complete agile team collaboration and development system based on open-source components. JGear Team is both a turnkey server solution and an Eclipse developer client solution JGear Team Server is a team development server stack based on best of breed open-source components such as Subversion, Bugzilla, Continuum, and XPlanner. JGear Team Server includes ProjectAssist™ - the JGear Team administrator client for simple single-click server installation and configuration, team project creation, user administration and setup.

This is a normal evolution for CodeGear as the future is difficult in the software development IDE sector if you want to remain the supplier of an isolated solution. Competition with open source and free products like Eclipse or NetBeans is difficult to sustain. A better strategy is to offer additional services that could be missing in the core open source solution and that developers are ready to pay some dollars to obtain. Acting like this in the Eclipse ecosystems, CodeGear recognises that its survival may depend on its ability to transform itself from software producer to plug-in developer.

http://www.codegear.com/
http://www.eclipse.org/

The Waterfall Manifesto for Realistic Software Development

After participating to and observing many software development projects in recent years, we have reached the sad conclusion that there will never be better ways of developing software on this planet. While the principles of the Manifesto for Agile Software Development may look appealing for inexperienced developers, serious professionals know that the real world is not similar to the “Little House on the Prairie”

This is the beginning of the story told in The Waterfall Manifesto for Realistic Software Development, an humourous mirror site to the Manifesto for Agile Software Development