Tracking change and innovation in the enterprise software development community
Testing Tools to
Support Agile
Software Delivery
Whitepaper
Posted by Jonathan Allen on Jul 17, 2008 06:56 AM
The proposed changes for Gtk+ 3.0 have stirred up quite a bit of controversy. A lot of people are sounding off against the plethora of breaking changes that are being made for "code quality" issues and don't directly lead to new features. Those hit hardest are also Gtk+'s most important audience, the application developers that rely on the framework.
Havoc Pennington doubts the usefulness of the changes,
I'm skeptical, as many others are, of claims that "cleaning up code" or "removing deprecated stuff" are ends in themselves... sometimes code cleanup is important, because the code is still in active use, and it becomes impossible to make it correct or understand it anymore. But the deprecated GTK+ widgets aren't like that; they are just sitting there untouched and are a cosmetic problem at worst. They don't significantly affect anyone who isn't using them, that I know of.
Meanwhile Morten Welinder is worried about keeping his existing applications viable,
Producing large applications is a lot of work, so when I write a piece of (hopefully) well-designed code, I want that code to stay written. I do not want next week’s GTK+ deprecation to come along and, effectively, cause my code to bitrot. (and I really do not want to write two different pieces of code for the job: one for “old” GTK+ and one for “new” GTK+.)
These concerns are not just about version 3. The Kristian Rietveld has stated that they intend to introduce breaking changes every 3-4 years.
But with tribulations come opportunities. While the Gtk+ API may be changing as quickly as project finish, the Gtk# API has no such intentions. As Jeffrey Stedfast points out, Mono developers are isolated from this and Gtk# 2 applications should run on Gtk# 3 without any changes.
Offshore software development: Making it a success with Agile Practices
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
Gaining Control of Changing Requirements Webcast
White Paper: Writing Good Use Cases
Continuous Application Performance eKit - Articles, Discussion Panel, Whitepapers, Demos
Charles Nutter discusses bringing JRuby to the JVM, why Ruby is hard to implement, JIT compilation, precompilation, core Ruby implementation, Java library access, library challenges and future plans.
Alois Reitbauer specifies several architectural anti-patterns that one should stay away from and which can downgrade an application’s performance.
Teams in large organizations still struggle to adopt TDD. In this article Mark Levison shares problems he uncovered when he surveyed teams, and his own strategy to introduce TDD into an organization.
In this talk from RubyFringe, Luke Francl asks: is developer-driven testing really the best way to find software defects? Or is the emphasis on testing and test coverage barking up the wrong tree?
John Pampuch discusses the HotSpot compiler, the history of Java performance, HotSpot development philosophies and challenges, optimization, JVM library improvements, and tips for better performance.
In this interview, Keith Braithwaite, an Agile developer, consultant and trainer, says that we should show a good deal of skepticism towards today’s Agile practice.
This article demonstrates how to build and orchestrate highly configurable and extensible yet light-weight embedded process flow using AOP techniques with Spring AOP and Aspect J.
Jeff Patton explains why one needs to embrace uncertainty in order to succeed with his/her Agile project and how to avoid some of the common mistakes leading to project failure.
No comments
Reply