Saturday, March 25, 2006

Migration to

Dear readers, this blog moved to Meet you there! Here is the new RSS feed .

Wednesday, March 15, 2006

Good and evil of software platforms

Software platforms by definition are
“some sort of framework, either in hardware or software, which allows software to run. Typical platforms include a computer's architecture, operating system, or programming languages and their runtime libraries.”
Business requirements driven platforms

Lately I've heard an opinion of one manager that the platform features should be driven by the business requirements and then these features will enable the concrete products. As an agile methods supporter I immediately became suspicious: anything that does not directly add value is over-design and are very likely to be useless and harmful.

The danger is in the fact that the business requirements discovered by some business analysts might simply hang in the air without the real link to the implementation, while various project will struggle trying to do the concrete things what their concrete customers want. The horizontal platform can easily become unbalanced, with too much effort put into never used features while some other components are not flexible enough.
Project driven platforms

As Joel Spolsky correctly notes:
“It's really, really important to figure out if your product is a platform or not, because platforms need to be marketed in a very different way to be successful. That's because a platform needs to appeal to developers first and foremost, not end users.”
The crucial mistake of business requirements driven approach is the assumption that these are the end-users who are the target audience. They are not. The platform customers are the developers and concrete projects.

Good and evil

So are the horizontal platforms evil? Not really. System libraries are useful, encourage the code reuse and save the developers from the unneeded low-level details. The only thing the platform designers should pay big attention to is who the actual platform customer is and how exactly the platform helps them. Platform driven by the [generalized] project requirements greatly facilitates the application development and exactly at the points where help is needed.

What is your experience with the platforms? What of the platforms you used was the most useful and why?

Tuesday, March 14, 2006

Overagiling in testing

Jonathan Kohl, a writer on software testing issues talks about good and bad in software testing. To me the key idea is that Agile testing does not mean throwing away all the testing habits and practices you got from waterfall or whatever approach you used. Agile development and testing is not a new silver bullet, it's just a more efficient way of using the old good things.
Agile methods have some great things going on with regards to testing, but we’ve been set back by a lot of bad testing folklore that was rehashed under the “Agile Testing” banner in early writings. Sometimes ridiculous claims that software testers have heard for years were once again trotted out as “wisdom”, such as “manual tests are harmful”, or “every test must be automated”, or “testers are the Quality gatekeepers on a project”.

Recently, I’ve worked with more and more developers who were misled by the “Agile-Testing” folklore that automated unit testing encompasses software testing.
Via IndicThreads

Monday, March 13, 2006

Waterfall 2006

A great sample of satire: Waterfall 2006 conference.

After years of being disparaged by some in the software development community, the waterfall process is back with a vengeance. You've always known a good waterfall-based process is the right way to develop software projects. Come to the Waterfall 2006 conference and see how a sequential development process can benefit your next project. Learn how slow, deliberate handoffs (with signatures!) between groups can slow the rate of change on any project so that development teams have more time to spend on anticipating user needs through big, upfront design.

Attend these valuable tutorials:
Eliminating Collaboration: Get More Done Alone by Jean Tabaka
Making Outsourcing Work: One Team Member per Continent by Babu Bhat
User Stories and Other Lies Users Tell Us by Mike Cohn
FIT Testing In When You Can; Otherwise Skip It by Ward Cunningham

Saturday, March 11, 2006

Error handling

Check out the post on error handling by Mika Raento, the researcher at the University of Helsinki, Forum Nokia Champion and the author of the huge amount of free source code examples for Symbian.

Mika talks on the ways of error handling in software and how the developer can aid the error handling:
  • You may need to document specific errors and supply additional information to the immediate caller.
  • The error information must support generic handling strategies, like a blind retry.
  • Low-level exceptions should not be remapped by upper layers.
  • The routine detecting an error is responsible for describing it in terms understandable to a human, often the user.
  • The system must be able to tell the user if they should contact another human.
  • The system must produce different messages for consumption by different humans.

Friday, March 10, 2006

Toyota's Five Why's

Toyota is one of the industry leaders known both for its quality and revenues. It's quality system was being built for decades and quite often the quality of the cars was by an order of magnitude better, than what, say, it's US competitors had to offer.

There are few simple principles behind the Toyota quality system. Here are two of them:
  • Built-in-quality
    Quality is not something that is added at the end of the production line. Every major robot that works on the car parts has sensors and intelligence to recognize defects early and either fix them or remove the detail from the line.
  • Toyota's five why's
    Whenever the problem occurred, the engineers ask why. Once they identified the factors that led to it, they investigate the reasons for these factors to happen. This process is repeated until no new information is forthcoming. Usually five levels of investigation is enough, therefore the technique is called "five why's"
Could the Toyota methods be applied in our industry? Early defect discovery and through investigation of the root cause should help producing astonishingly reliable programs. But wouldn't it cost too much? Is it economically feasible? Do we have time to fix all these bugs?

Does it pay off? - Ask Toyota.

Thanks to Lasse Koskela for the idea of this post

Thursday, March 09, 2006

New feed address

I eventually switched to feedburner. The new feed address for this blog is The old feed address will work ok, but it would be very kind of you, dear readers, to subscribe to the new feed. This way, I can know how many readers are there and if I write stuff that is of interest for somebody :)

Wednesday, March 08, 2006

Do you own your code?

When there are more, than one programmer on the project, the work has to be divided somehow. Agile methodologies propose self-organized team to decide who is doing what, more traditional waterfall approaches propose that manager allocates tasks to the guys with the free time slots. Whatever the method is, there is one more thing to consider: who is allowed to make changes where.
It is quite often that particular modules are "owned" by particular people and only they are allowed to make reasonable changes there. Usual argument is "The person, who doesn't know the module, can unintentionally break it".

What is interesting is why is it easily possible to the fellow programmer to break the code easily. After all he is often as experienced as the author of the code. The sad answer could be that the code is hardly understandable, too complex, not well commented or doesn't have enough unit tests to prevent the regression. Most of agile development methods promote: 1) fixing, testing and finishing the existing code, before adding new features; 2) test-driven development; 3) common code ownership; 4) frequent peer code reviews. The first two items help to cope with the "can unintentionally break it" part of the argument, the last two - with the "the person who doesn't know the code"

Next time you will hear that somebody should have an "own" module, ask the speaker for the reasons and tell about the known cures for the "code ownership syndrome".

Thanks to the F-Secure person (sorry, still don't know his name) who shared with me the arguments presented in the post

Monday, March 06, 2006

Test the platform

One concrete tip about from the seminar discussion: If you are unsure about the platform features, create a test for it.

One of the topics discussed was Test Driven Development (TDD). It is the software development method, when programmer first creates the unit test for the new functionality and only then implements it. I had the concern about the unknown platform capabilities. It happens so, that I and my colleagues often work on fresh betas of the coming software platforms that don't have all the new features documented or even implemented. Therefore quite often I don't have a concrete plan in mind. I try using one feature and another until I find a way that satisfies the original requirements somehow. Of course, these feature trials tend to become the release code and it's mentally difficult to write a unit test after the code - after all this way it is not TDD anymore.

The solution proposed by somebody from F-Secure (sorry, I don't know the name. Please, comment if you know) was as simple as every ingenious idea. If you are unsure about the platform features, create unit tests for them. It might not be possible for the GUI area, when you have to observe the results manually, but for all the other areas such tests would be a good compatibility test and a good starting point when you'll have to port your application to the next version of the platform.

Sunday, March 05, 2006

Agile SW Development Practices Seminar

Last week I was attending the seminar on Agile SW Development Practices in Vantaa (Agenda in pdf).The seminar was very nice with a lot of speakers, talking about their own very practical experience in agile-related SW development. Most probably I'll highlight several seminar topics in the coming posts.

At the moment I can present my main impression: all the agile methods are about is truth and visibility. Don't lie to yourself; don't overplan, what you are not going to implement; don't pretend the project is 95% ready, if you are expecting endless bugfixes and don't hide the current situation from your customers. That's it. All the remaining details are about how to implement these principles in practice. I.e. how often and in which terms to report to customers so that they understood you and weren't overloaded with the unnecessary details, how to prevent yourself from overplanning, etc.

Tuesday, February 07, 2006

Compilable Symbian Code Examples is eventually up and running. It took quite some time to restart it, but I am very much pleased with the results. It is build on the Drupal CMS 4.7 Beta 4. As it is still beta, I disabled comments - they work ok, but display error-like messages, when you post. They will be enabled whenever Drupal community releases the next Beta or RC of the 4.7 (sometime in February)

Nevertheless, the site looks great (as for me) and I am extremely pleased with the customization possibilities, to be enabled one by one in the close future.

And by the way. You can post or link your Symbian code examples there ;)

Sunday, December 11, 2005

Agile software development practices in the non-IT world

Lately I, my wife and couple of our friends had a chat about how people get the feeling of success and manage their lives well.
At about 2 AM we more or less jointly concluded, that the key to success and to the feeling of success in virtually any project (including the individual life) is the following:
1. Don't lie to yourself, never. Realize what the situation really is. You cannot get the correct direction unless you understand what the starting point is
2. Get some long-term vision of your goals and periodically review and adjust them. No detailed planning is possible and should not be attempted
3. Get the work done step by step. Don't plan in detail for a year, establish a subgoal for 1-6 months and work on it. Don't be afraid on throwing away your work results if it proved to be the wrong path, but don't give up until the establish dead line passed

Surprisingly the "universal" success plan almost precisely resembles the values of the iterative software development. Last three or four months I am trying hard learning and applying Scrum - one of the most popular Agile development methods and, voila, it happens to be very close to the universal formula for managing the complex processes in my very life. In fact, it is what Scrum claims, but it is very impressive to get the same conclusions yourself.

Tuesday, November 22, 2005

Series 60 examples

Today I've spent several hours trying to locate a simple example for the Nokia's Series 60 3rd edition. And miserably failed.

At the moment I am developing my first 3rd edition application. It is also the first app, where I am going to use vector icons in the svg format (introduced in Series 60 2nd edition Feature Pack 3). Somehow in all my previous projects I did the non-UI components only and never bothered about the application wrap-up.

Today in the morning I found that even though I have access to a lot of 3rd edition applications, I don't have a single simple example. As you might guess the attempts to "intelligently copy" the existing code failed.

I've spent the following two or three hours digging NewLC, Forum Nokia and Google looking for a HelloWorld or at least some program with the custom icon. It happens, that neither on the Forum Nokia, nor on the web, nor even in the Series 60 SDK (!) there is no single 3rd edition example. I wonder how third party developers are supposed to create great applications for the new platform without any (!) example.

Fortunately I managed to solve the problem myself. Now the action point for me is to speed up the SymbianExample upgrade and start posting the 3rd edition examples there - looks like there is a big demand for them.

For those interested the problem was in that I forgot to include one of the header files into the resource. Unfortunately resource compiler didn't complain, and the path to the application was incorrect

Friday, November 11, 2005

Restarting SymbianExample went down - a hoster failure. Unfortunately their backup drive crashed also (taking into account, that they restored everything, but MySQL databases, I'd say, that probably DBs were not backed up as often as they should've been)
Anyway I'll have to restart the site from what I have backup up to my local hard drive. On the other hand, I was already disappointed with Joomla as a site platform. This time I'll try to make a Drupal-based site.
Stay tuned, I'll report on the progress.

Sunday, October 30, 2005

Multitasking in the workspace

On Joel's Multitasking in the Workplace

Multitasking in the Workplace:
Joel Spolsky, a known writer on software development related topics is a long standing advocate of private offices for every developer, perfect working conditions and managers whose main role is to “move furniture out of the way, so people can concentrate on their work”. Lately he found the support in the published in the NY Times research report claiming that in the cubicle space people loose hell a lot of time on interruptions. I believe that there is a proven way to unite the advantages of the open-space communication and private office focus.

Switching between tasks can take too much time
Joel's point is in that software development is a type of task that requires very high concentration. It takes too much time to switch between different tasks. Open office space might mean the increased level of inter-communication, but at the same moment it means too high rate of interruptions by the colleagues. Gloria Mark's study shows that in the open space based software development company
"Each employee spent only 11 minutes on any given project before being interrupted and whisked off to do something else. What's more, each 11-minute project was itself fragmented into even shorter three-minute tasks, like answering e-mail messages, reading a Web page or working on a spreadsheet. And each time a worker was distracted from a task, it would take, on average, 25 minutes to return to that task"

Overcommunication and undercommunication
The lack of communication is a known problem in the software industry. Lack of developer's focus and continuous interruptions is another one. It is the communication problem, that open space offices aim to resolve, and it is the concentration problem, Joel considers being the most worth solving.
There is a set of Agile development methods that put special emphasis on both enhancing the inter-developer communication and study of the consequences of the rate of communication. It is of no surprise, that having both "Individuals and interactions over processes and tools" and "Responding to change over following a plan" as the main values, Agile methods pay attention to the respect to the individual's work (i.e. to its concentration) while trying not to harm the level of communication.
Here is how Scrum, one of the most popular methods, addresses the open space issue.

The grand Scrum's idea of finding a concentration-communication balance is in protecting the developers from the potentially irrelevant discussion topics, in encouraging irrelevant topic discussions to happen at the dedicated moments. This idea is not unique to Scrum, but here it is used to the full extent.

1. Time-boxed iterations with a fixed set of goals
As most of iterative development methods Scrum utilizes time-boxed iterations strictly limited in time and, what's more important, with very limited set of concrete goals. Scrum does encourage frequent and early requirements and design changes, but all the changes are permitted only at the edges of the iterations. During the 30 days of the iteration, goals and main focus are frozen. In the world of chaos, there is a need for some stability. To emphasize this feature, Ken Schwaber, one of the Scrum creators, even named his web-site

2. Daily meetings

Scrum overview from

To filter out the interruptions even more, Scrum features the daily meeting practice. They are sometimes referred to as “stand-up meetings” to emphasize the short length of the meeting. During it every person answers only three concrete questions: 1) What did you do yesterday? 2) What are you going to do today? 3) What got in your way of doing work? The daily meeting is a very short moment (usually 5-15 minutes) when everybody updates the understanding of the project state. At this moment potential problems (usual source of interruptions) are discovered, team has an opportunity to relocate resources and Scrum master is able to schedule actions for removing the obstacles as soon as possible.

3. Whole team together
The last Scrum practice I am going to mention is “Whole team together”. “Whole team together”, taken from XP means exactly the whole team sitting together in a single common room without cubicle borders and working on a closely related set of tasks. After all the irrelevant stuff has been filtered out by the fixed-goals iterations or scheduled to happen at specific time-place by the daily stand-up meetings, there is very little what can irrelevantly interrupt the programmer. If Mutt asks Jeff about the advanced usage of the ProvideReports function, it is quite probable, that he is working on something related to either ProvideReports itself or to some services that it uses. Voila, interruptions have been transformed into a useful channel of communication.

There is no silver bullet in the software development. Private offices do attract people, but harm inter-developer communication. Neither Scrum, nor XP, nor any other method can guarantee the success. Nevertheless the right balance between the developer's communication and concentration seems to be one of the keys to the successful software development. Scrum proposes a thoroughly elaborated set of practices aimed at finding this balance. At least, these practices are worth consideration.

Monday, October 17, 2005

Welcome to

And so I did it. is up and running. In perfect accordance to the Agile Manifesto's "Working software over comprehensive documentation", design is far from perfect, e-mail is not functioning, no forum installed, but it is up and running. You can already find there a launcher of ExeDll projects and sample code for global key capturing (including a tricky case of long key press capturing).

From now on, whenever I publish some more or less non-trivial code, I hope it to be stored on

Sunday, October 16, 2005

Getting a personal code examples site

After about a half a year of trials on my PC, I finally decided to get some more or less real personal web site to store Symbian code samples. Reasons are quite simple: I like to read and write at NewLC and Forum Nokia discussions, but I want my examples to be nicely orgainized. I want to be able to refer to my own examples.

That said, today I've bought a on Yahoo! domains. After the domain is activated, I hope to start posting there.

Monday, October 10, 2005

Visit to the Nokia factory in Salo, Finland

Before publishing this post I carefully verified that all the described content was already published in the web. You can consider this post being a syndication of these “other” reports :)

Update: Everything but the above paragraph has been censored out

Wednesday, October 05, 2005

Getting AdSense

I eventually got an AdSense for this blog. It might sound useless for a blog with one post a month and one reader a week (who is apparently me), but who knows how famous I can become just next week :) Let everything be ready for getting reach. After all, I am just trying the yet another must-know technology.

Thursday, September 08, 2005

Second Agile Finland seminar

On the 7th of September I was visiting the Nokia Research Center in Helsinki, where the Second Agile Finland seminar was hosted.

The popularity of the Agile methods among the software developers is growing all over the world. My first university degree was focused on the ways of constructing large software systems. So I've been always curious about different trends in the design methodologies. I could not miss a chance to discover more about this area.

Read more

The presentations were very impressive. What particularly excited me was the great amount of statistical and historical background presented by Craig Larman from Valtech. You all know, that "waterfall" is a devastating way to go. It was amazing to discover, that it was considered harmful from the very first time it was mentioned (!). But not so many readers of the article, where the waterfall was introduced and thoroughly described bothered themselves to read to the part, where it was criticized and iterative methods were offered instead.

2nd and 3rd presentations were devoted to the success stories about using Scrum methodology  - lightweight iterative way to design software. It proved to be really simple, controllable and effective.
If you want to improve the software development at your company, have a look at Scrum. I will definitely try using some elements of it - its backlog and burndown chart seem to be very simple and at the same time effective and even fun tools to use.

Craig Larman starting the seminar

Monday, April 25, 2005

"Read more" links

If I successfully learned how to use Blogger tags, you should see a "Read More" link below.

Read more

I've learned about this feature here
The question for now is how do I display "Read More" links only for the posts that have something "more". Blogger guys leave this "as an exercise for the reader" :)

The question solved with the solution found here.
Not that elegant solution, but it works

Friday, March 11, 2005

Google Desktop Search . Is this a way to become a programming superstar?

Two days ago Google released its final version of the Google Desktop Search. I was using the Beta for two months already and I must confess, that it was just perfect for searching through Outlook e-mails. I get so many important e-mails every day, that before GDS it was very difficult to find any particular one.
Of course, you can use GDS in the office for evaluation only if you have read their Terms & Conditions ;)

What is one of the most amazing things in the GDS - is that you can create your own plug-ins for it. Check the Developer's guide and start the Visual Studio, you can become famous by being the first who releases plug-in for indexing the Opera browser history. Google will publish your plug-in on its web page and even will give you the Google T-Shirt.

The API and examples are really simple. Everything you have to do is to create a COM object, that will process files of specific format and convert it into text or HTML, that GDS will process further.

Sunday, March 06, 2005

What's the best way to learn how to write? It is to write

I was so much impressed by the Joel's advice about the fact, that learning good English is a must for every decent developer. That's why I start this blog in English. I hope to post at least sometimes and ideally this would improve my English a bit.

I am going to collect here links to all the articles on software development, that I find interesting. There are so many interesting articles on software, that you loose somewhere on the web. From now on I'll have my personal catalog for the favourite stuff :)