key quest: quality

Preamble

The topic of "software quality" is tricky and full of potential traps. There are so many ways to define and measure software quality and so many different kinds of audiences to think about when discussing it, that software quality discussions far too easily fall of the tracks of usefulness. If at all possible, I'd like the comments to this blog to not fill up with bug reports or comments like "well, it's about time because poor-user-me has ...". While those are assuredly valid comments to make, we could probably all make one of them and then we won't be able to discuss what we are actually going to be doing in terms of software quality improvements in KDE for 2010. The result would be to verge on futility.

We have bugs.kde.org, brainstorm and other places for such feedback that are much more useful than my blog for those comments, after all. As such, I will be removing such comments with prejudice if posted to this entry. I will be deleting them "non-permanently" (to use blogger's definition of that), so people will be able to see which comments were removed and who posted the comment.

But enough of that ... onwards!

Why 2010?

In this series I've been highlighting a set of issues that I personally believe to be potentially critical issues for KDE to be mindful of in the coming year. Some issues didn't make the list because they are sufficiently in hand, limited in scope (even if important!) or unlikely to get attention in 2010 (though in some cases I'd love to be proven wrong there!). The issue of software quality in the context of KDE's efforts in 2010 followed naturally in my mind. Why?

Many key projects that have been part of KDE's 4.x odyssey have reached interesting points in their development by the end of 2009. Most of them have reached a level of general utility and even polish that had been the primary locus points of attention for our developers. THis is because many of these technologies were very new or trying to do new things. Whether we look at Amarok2, Plasma, Nepomuk, Solid, Phonon, KDE integration for PolicyKit/PackageKit along with many other examples, there was simply a lot of newness. This was a necessary step towards bringing to the table much needed advances in what we are able to offer to people using computers.

It also reminds me of the early KDE 2 releases; while much more contained in their scope (KDE has grown a lot since then), those releases were also "obviously new code" in their feel. They quickly became robust, release over release, and started maturing with an impressive path towards a great set of software. The fierce commitment to KDE 3.5 we have all seen on the part of various users is a result of that process.

As we are exiting, able to see the exit point or have exited from the "newness" stage for most of these key technologies, it is natural that the software based on the KDE Dev Platform v4 are going to be going through a similar journey.

How Fast, How Focussed?

I don't think it will take as long to get our current generation of software to the same levels (and beyond) of reliability linked to the the 3.5 series as it did KDE 2.x. In large part, this is because we are building on top of those rock solid bodies of work: we still have KDE Core, UI, KIO and many others. While these are all still seeing work and improvement (KIO recently got a new and improved scheduler, for instance), they give us a wider base of stability than KDE 2 ever had the benefit of. On the other hand, we've also created huge spans of new functionality that needs to go through a process of quality improvement.

One question will be how to balance the forward progress of new features versus quality improvement work. New functionality increases our user base as well as our developer base, so is crucial. Quality improvements also do this, but much more incrementally. Still, without a certain level of quality met, it becomes a weak point for us. This balancing point will need to be found. Still, I believe 2010 will be a year that we experience across the board quality improvements in KDE software. This is not to say we're in a horrible position right now, but rather that it can be better and that it is highly likely, given our exiting from the "newness" stage of development, that we will see more quality focused work and results in 2010 than in 2008 or 2009.

How Can We Achieve Quality?

How we can achieve greater quality is a starting point for an ongoing conversation. Part of that conversation will be how to measure where we are at any point in time. Measurement allows us to know if we are going in the desired directions or not. That's why things like tracking defect report numbers on bugs.kde.org, Paul's continued work on metrics and tools like the English Breakfast Network and automated build farms will likely play even larger role in our efforts in 2010.

We have a slew of the "usual suspects" for increasing quality: automated testing, improving documentation and even just simply "using it more for longer". What concrete actions we will take will be another interesting set of discussions, and one that I think will be different for each project in KDE since not all projects are at the same points in their development.

We've been discussing this a bit within the Plasma project and it will be one of the focus topics for Tokamak 4 next month. Currently my plan, with the proviso that this is not final and will likely shift with further team collaboration at Tokamak, is this:

For the KDE Software Compilation 4.5 release, we will be focusing primarily on "finishing and polishing". We have a number of existing projects that aren't "quite there yet". Things like Plasmate are tantalizingly close while others such as Plasma Mobile and Plasma Media Center are still in their larval stages. We need to put more focus on finishing these things out and shipping them in useful states.

Then there is the issue of smoothing off the edges. A number of features offered by Plasma components are pretty compelling, but have a "last mile" left to be walked before they have the "right feeling" to them. An obvious example that jumps to my mind is notifications: we have more work to do there for queuing and passive management of them. I don't think anyone has really got this nailed yet, which isn't very surprising since right now I only know of two F/OSS groups even paying attention to the various pieces involved (which includes system tray icons, notification pop ups, logging and user interaction). Notifications aren't the only thing that needs tightening up so it feels "finished, polished, meeting our dreams for coherency and organics".

Finally, there is the more pedestrian issue of defects. With each release of Plasma and the applications we build around them, such as plasma-desktop, we've slayed huge number of defects. Some releases have seen, quite literally, hundreds of defects fixed relative to the previous release. We're shipping a couple hundred thousand lines of code with each KDE SC release that Plasma participates in. That code is very feature-efficient, in that there is little "boilerplate" duplication and a lot of functionality sharing (often commits reduce code count rather than increase it, these days). So with 4.5, and potentially 4.6, we will be focusing more on the existing code than adding more newness. There will certainly be new features and noticeable expansions in existing features (part of the "finishing things we've started" part of this), but there will be less focus on completely new things relative to the focus on working what's there now. In sports that involve swinging sticks, this is often referred to as the "follow-through".

Now, this is not the strategy that every project in KDE will adopt for 2010. I don't think it's even appropriate for some KDE projects that are either still in "newness" or are already in a nicely mature state. However, I do expect to see more KDE project mulling over these kinds of topics in 2010, relative to 2009, and as such for the 4.5 and 4.6 KDE SC releases (not to mention the KOffice 2.x, Amarok 2.x, Digikam 2.x, etc) releases to reach new quality peaks.

Don't Stop The Innovation!

I spoke earlier about a balance, and I'd like to close by re-iterating that point. We shouldn't aim to stop innovation (things like Silk, which was the topic of my previous blog entry require we don't, in fact) and aim to ossify our projects and start down the road of diminishing incremental returns. However, I do think that we've had the luxury and even need to focus more on getting the "newness" phases of KDE 4 behind us and that now it's a good opportunity to swing things to a new balance point with an increase on product quality.

I'll personally be watching various KDE projects with great interest throughout 2010 to see how this all pans out.

(This article is part of the "Key Quests for KDE in 2010" series)