Steuer V0.2 – making progress with my iPhone app

December 28, 2010 by · Leave a Comment
Filed under: English, iOS 

Over my last few train rides I’ve managed to make some progress in making my app a bit nicer.

This is what the old version looked like:


Apart from a few “under the hood” things (like moving to a new version of XCode and the SDK, so the simulator looks like an iPhone 4 now), I’ve improved on the following items:

  • switched to a table-based view
    This makes the inputs (Eingaben) and results (Ergebnisse) pretty self evident. I’m still going to tinker a bit with the view as there is one row that wouldn’t quite fit on one screen and I don’t want the app to start scrolling.
  • added a “title bar” (called navigationItem in iPhone-speak)
    I couldn’t quite figure it out how to do that for the simple version where I didn’t have to write a controller for the main app screen.
  • ditched the “Berechnen” button
    After changing the inputs, the results are automatically calculated.

Here’s where I am now:image

I think that is looking a lot better than V0.1, but there is still a lot to do – both from a design (colors anyone?) and a functionality standpoint, but at least I’m making some progress. I’m hoping to get a bit more done in the “free” days after Christmas, but it already looks like a lot of days are filled with visits to family and friends, and that is certainly important, too. I’ll keep you posted!

Unit Testing an iPhone App – Not important to Apple?

December 7, 2010 by · Leave a Comment
Filed under: English, iOS 

After the base functionality of my iPhone app was in place, I wanted to have a closer look into unit testing. I try to use unit testing where it makes sense when developing for my customers, so I wanted to do that for my own app as well. I was encouraged that there was some documentation in the Apple developer’s guide, and I was really looking forward to putting the framework to use.

Restructuring my App for testability

Before being able to properly test the tax calculation functionality, I had to a bit of restructuring to do in order to properly isolate the functionality I wanted to test and to separate it from the GUI. I pulled the tax calculation into its own class and made the GUI use this TaxCalculator. This separation of concerns is one of the benefits of using a Test Driven Approach – it forces you to think about testability and separation of concerns if you want to have an easily testable class. The changed were totally unnoticeable to the user, but added some value because the code is now much easier to understand and to maintain. It took me less than an hour of development  time, and that was time well spent.

Initial Problems with SDK 4.1

The next step was reading up on Unit Testing with the iPhone SDK. There is a chapter in the iOS Development Guide that describes how to add tests to your project. From the start, I was getting strange errors even though the tests seemed to pass. As I was developing these tests while riding the train, I played a bit around in order to avoid the problems, but didn’t have any success. I added a few tests for the TaxCalculator, but ran into some more strange behaviour.

Some Progress with SDK 4.2

When I was back home, I googled for my problems and quickly found that it was a problem with SDK 4.1 (thanks to this Stackoverflow question). There seemed to be a workaround in 4.1, but as the problem was fixed in SDK 4.2, I just decided to upgrade my SDK which I wanted to do anyways.

After that, I had the next problem – XCode was telling me that my “base SDK was missing”. Googling for that problem I quickly found an easy fix for this issue as well (the one I used was on John Alexander Rowley’s blog, but there is a number of helpful hints across then net. After that, my tests were finally running without any errors and I was finally able to focus on writing test cases.

However, I soon ran into a lot of problems in properly checking what the tests were doing and if my app was working fine. I’m usually trying to reserve judgment, but in this case I can’t put it any other way:

What was Apple thinking?

Using the Apple supplied Unit Test library, the tests are only run during the build phase. Running tests during the build phase is not a bad idea, it can prevent building an app if some tests are failing. But running it only during the build phase has some serious drawbacks: Messages sent to the log do not show up in the debugger console (at least they show up in the system console), but more important: You can’t debug the tests!! (I should note that there are some descriptions on how to set up a separate target that would allow you to debug the tests, but the procedure is very complicated – like setting the environment variable CFFIXED_USER_HOME to "${HOME}/Library/Application Support/iPhone Simulator/User". I gave up on it after unsuccessfully trying for an hour or so.)

I have no idea how anyone can think that what is currently delivered is good enough to use. No one who has never used Unit Tests and pretty much wants (or has) to use it will endure the procedure to make it work. It just seems to be some item on a list that Apple wanted to tick (“Unit Testing? We have that.”) but wasn’t really interested in. Very “un-Apple” …

Switching to GHUnit

Luckily, there seems to be a good open source alternative to the Apple Unit Testing framework, name GHUnit (named after it’s developer, Gabriel Handford) which can be found at It was very simple to download and add to my project. Within 15 minutes I had my project use GHUnit and I was able to run the previously developed tests within the simulator:


It also enabled me to log to the console and debug my test cases in the XCode debugger just like any normal app – without having to jump through any hoops. You may argue for a nicer interface (color anyone?), but that is certainly a minor issue. After the disappointing Apple framework, GHUnit delivered on what I was looking for. I’m hoping that the framework will hold up under all the testing I want to throw at it in the next weeks!

Calculating tax owed – My First iPhone App

November 2, 2010 by · Leave a Comment
Filed under: English, iOS 

As indicated in my latest blog posts, I’ve started to dabble in iPhone development. As a starting point, I have programmed a little app that calculates income tax owed based on money earned.

Use Case

The use case for this app is based on my personal situation as a freelancer in Germany. The situation is probably similar to other countries, and I might build similar versions for non-German markets.

As a freelancer in Germany, when you get paid, there is no tax withheld as it would be when you are an employee. At the end of the year, you have to declare your earnings, tax is assessed and then you have to pay. As this is a substantial part of your earnings (30-40% is a typical number here in Germany), you better make sure that you know how much of your earnings is actually money you can spend. It is also a good idea to put away the money you expect to pay for taxes. (I like to save the amount in a money market account, so I even have a chance to earn some income on it, even if there’s not much to make with the way interest rates are these days.)

So the App basically asks you how much money you have earned in a month and shows you how much taxes you would owe on this amount. Sounds really simple, but nothing with taxes is ever that simple:

  1. There is some additional sums that has to be included in the taxable amount. In Germany, the main one is called “Geldwerter Vorteil” or GWV for short – a monetary equivalent for non-monetary benefits that you get. The “classic” example is a company car that you can use privately or for riding to your place of work.
  2. There are different components to income tax, such as the base rate, “Solidaitätszuschlag” (an add-on income tax that was originally introduced to aid East Germany after unification) or “Kirchensteuer” (“church tax” which is collected by the state and then re-distributed to the churches).
  3. The tax rate itself is not one simple formula but has different formulas for different ranges.

So even if the use case is not all that complicated, it is also not trivial to build a decent app for that.

The App V0.1

Here is a screenshot of the first, simple version of the app:

image On the top, you can enter the money earned (“Einnahmen”) and the GWV. Below the ‘Berechnen’ (calculate) button the different components of the tax and the full amount of tax owed is shown (“Gesamt-Steuer”). In addition, the tax rate and the earnings after tax are displayed.

From a functional viewpoint, there is very little that is missing for the use case I outlined above:

  • Kirchensteuer is dependant on whether you are a member of a church and your location. There has to be some configuration, probably in a new view.

There are a few things that would be nice to have:

  • The last values should be saved and reloaded after the app start.
  • In order to calculate GWV for car use there are some standard rules. Instead of entering the final value, the way this is calculated should be made available .. another configuration view.

After that, the improvements are not so obvious:

  • make the interface prettier (icon, title bar, colors)
  • use better formatting of the values (separators, currency symbol)
  • instead of individual labels and fields try out a table-based view (should look “nicer” and also offer an easier way to integrate the configuration views)
  • explore a subview with ads in order to monetize the app (instead of selling it)
  • explore alternatives for smarter entry of values (instead of keyboard, use dials and/or gestures)

The last item is especially important for me, as I want to develop apps that make good use of the iPhone’s capabilities. In my view, today there is not much use for simple data entry iPhone apps that could just be a web form. In order to delight the user, you have to be able to make things better, easier and unique to stand out from the crowd of apps in the app store. This may be tricky for a “boring” tax app, and you also have to find a balance between “clever” and “easy to use”, but I’m willing to explore these areas and see what I can come up with.

I’ll post some news once I’ve improved the “raw” app I have now.

Discussing an iPhone App: Settlers of Catan

October 4, 2010 by · Leave a Comment
Filed under: English, iOS 

Over the last weeks, I’ve been thinking about starting some development for the iPhone. There are some ideas in my head of what I could do, but nothing specific yet. Only thing that I’m sure is that I don’t want to do another “me too” program, but something that really uses the iPhone’s strengths.

For example, a lot of mobile apps I see just let you enter data on the iPhone using the traditional “keyboard” and “picker” methods. I’m pretty sure that some gestures may be helpful and allow for quicker entry. Also, oftentimes “guessing” from a GPS-location or time-of-day may offer some good default values. I hope that this will be a road that I’ll be able to explore a bit more.

Because of all of this, I’ve been paying closer to attention to things I like and dislike about some of the apps and games I’m using.

I like playing the occasional game on the iPhone, and in the last few weeks I was playing a lot of Siedler of Catan (Settlers of Catan in English). Just to be sure: The adaption of the board game is done quite well, the computer players have different strengths, so the game provides fun and entertainment for a long time. Well spent 4€ (or 5$)!

However, there are a few issues that I have. The start of the game features an elaborate animation .. but there is no way I have found to get straight into the game. So every time you start the app, after waiting a few seconds for the animation to load, you get the start of the animation

IMG_0001 After tapping on the screen, you get another splash screen:

IMG_0007where the game even tells you to tap the screen (“Bitte Bild berühren”). Then you get the main game menu

IMG_0005 where you can hit “Spiel  fortsetzen” to continue the ongoing game.

That’s three useless taps (and probably 10 seconds of time) that I would consider bad style for an iPhone app. (It’s okay for a PC game, but not for an iPhone app that gets frequently stopped and restarted.)

There are a few other examples where a bit more thinking would have helped create a better experience. For example in this screen you have only three options, but the graphics don’t fit the screen so there may be some scrolling involved:

IMG_0003 With just some more work, the graphics would fit the screen. Also, swiping doesn’t really work here, instead you have to use the provided arrows.

I’m sure that these issues arise from trying to be consistent with other versions of the same game, but I would think that some more care should have been taken while adapting the game to the iPhone.

So five stars for the basic game, but only one star for the iPhone adaption.

Have you built your DQ trust today?

May 10, 2010 by · 7 Comments
Filed under: English 

For German readers: Es gibt eine deutsche Version dieses Blogeintrags.

In the last time, there have been quite a few posts on using “shame” as a tool for improving data quality. Here are just three from the top of my head:

Picture by Okinawa Soba, taken from flickr with a cc license

I’ve added some comments to these posts that I think that they are missing something. I wasn’t quite able to put my finger to it, not sure how to grab the “missing thing”, not really able to give it a name. In order to move the discussion forward, I’ve decided to go with “DQ trust” and try to explain my thinking a bit more. Let me know in the comments what you think!

The problem I see with the “public humiliation” aspect of what Rob and Jim are describing: It will only work in a certain environment – when the “riot act” gets what I would call a “wink wink, nudge nudge” aspect.  The “culprit” understands why the reaction is coming, but the whole thing is so much over the top that it can’t really be taken seriously. This results in taking the sting out of the “public humiliation” aspect and the riot act achieves its purpose.

In order for this to work, there has to be one of two things: Either you have to be a really good comedian (and I’m certainly not) so that you can spring this on a person you’ve hardly ever dealt with before. If your act backfires, you’ll also have to deal with that person’s boss, and I have found humor to decline when moving up the corporate ladder. Pretty risky to rely on that.

That leaves the second option: Your riot act has to have a background to it, and you must have built a reputation as a fervent defender of data quality in your organization – you must have built a trust in your data quality judgment. This way, a person or his boss can understand that your reaction is aimed at improving data quality, and not at public humiliating data quality villains.

Too often I find that people do not take enough time to build this data quality trust. As they say it takes a long time to build trust, but only a moment to destroy it forever. Here are some ideas of what to do to build the trust:

  • reserve judgment on someone’s actions for as long as possible – try to find out why people do things a certain way before telling them they are idiots
  • admit that you don’t know everything and try to learn constantly by interacting with different people from different departments to get a 360° view on the issues
  • help people to solve their problems – then they will be much more willing to help you when you need their support
  • make sure to explain data quality in terms the person understands – a business user doesn’t care too much about referential integrity unless you can explain how it affects his daily work
  • don’t be too academic in your data quality requirements – it doesn’t make sense to require perfect data quality for data that is never used

Even with this, whenever a new data quality issue comes and I’m shaking my head why anyone would come up with this harebrained scheme, I ask myself whether I’ve built enough trust to shame the person about it or not. Almost always, I come out on the side of caution and try to be firm on the issue, but avoid assigning personal blame. In the short term, this may not be quite as satisfying as “venting”, but has a much better chance of long-term success.

Assessing Data Quality – Improve vs. Maintain

April 16, 2010 by · 1 Comment
Filed under: English 

For German readers: Es gibt eine deutsche Version dieses Blogeintrags.

Last week, I was discussing measuring Data Quality with a customer. For a while it seemed we couldn’t agree on anything, until we realized that we were talking about different types of DQ projects:

  1. A project geared at improving data quality in a specific area
  2. An ongoing effort to make sure data quality stays within accepted levels


Once we talked about these different types, agreement came very easily.

Improving Data Quality

In this type of project, there is an important business reason that requires improving the data quality. Typically, you start with a large number of errors and have to reach a much improved level. In some cases, this level has to Zero, but typically a low number (say, 10) of error cases is acceptable. Examples of this type of DQ project include meeting regulatory requirements or the migration of data to another system.

This is a project in the strict sense: You have to reach your goal by a fixed date. As often these days, the goal has to be clarified after the project has started. For a data quality project this includes identifying important data areas to be improved, defining rules that the data has to conform and a way of identifying non-complying data. When this step is completed, you end up with a number of DQ Measurands (see my previous post on Describing DQ Measurands) and an automated way of measuring the data quality for each specific measurand. Typical projects I’ve worked on had a list of 20 to about 100 measurands that changed a bit over time, but was relatively stable after the initial definition phase.

The main questions that have to be answered in this type of DQ project are:

  • Which issues have been raised and which have been resolved? Which do we still have to work on?
  • Are we on track to getting to an acceptable level of Data Quality by the end date?

Maintaining Data Quality

In contrast to the “Improvement” type of project, a “Maintain” type does not necessarily have an end date but is an ongoing effort. (It may start towards the end of an improvement project when most issues are resolved and should stay that way until the project ends.)

Most of the definition work has already been done by improvement projects, and the maintain project “inherits” these results. Again, the number of DQ measurands may be quite high – even higher than in an improvement project, as over time the rules of multiple improvement projects move into maintenance. The data quality is usually at an acceptable level, so the type of questions are different:

  • Have there been changes that require action?
  • How well do the rules cover all the data in the organization?

Assessing DQ Measurements in different types of DQ projects

A DQ measurand can be defined without having to take into account what type of project it is used for. But interpreting the measurements has to take the project context into account and leads to different interpretations in order to answer the question. My customer and I are still working on the specifics, but identifying the different types of projects helped us gain a shared understanding.

The DQ Cycle – a Procedure for dealing with Data Quality issues

March 29, 2010 by · 2 Comments
Filed under: English 

For German readers: Es gibt eine deutsche Version dieses Blogeintrags.

In the past, I have outlined elements to take into account when starting a DQ initiative. This post describes how to deal with Data Quality issues.

Some Background

The Deming Cycle is an established iterative four-step problem-solving process typically used in business process improvement. It is also know as PDCA for its four phases:

  • Plan
    Establish the objectives and processes necessary to deliver expected results.
  • Do
    Implement the new processes, often on a small scale if possible.
  • Check
    Measure the new processes and compare the results against the expected results.
  • Act
    Analyze the differences to determine their cause. Each will be part of either one or more of the PDCA steps.

(Adapted from the wikipedia article on PDCA.)


The DQ Cycle is an adaption of this general framework to Data Quality. I’ve used this framework at a number of customers with good success. The general idea is pretty simple and easy to follow, but it is an excellent reminder to make sure you’ve crossed all the T’s and dotted all the I’s.

The DQ cycle has the same phases as the Deming cycle. It describes how to deal with a single DQ problem that has been identified. This means that there may be a number of DQ cycles going on at the same time, each cycle dealing with its problem, and each of these cycles may be at different points in the cycle.

As you may have noted, the description started with the term “DQ problem that has been identified”. In order to accommodate this “problem identification”, there is an additional “Init” phase that kicks off a new DQ cycle:


So we end up with these phases:

  • Init: A new DQ problem is identified
  • Plan: You analyze the problem and decide on a course of action
  • Do: The bad data is corrected
  • Check: You verify that the DQ problem is resolved
  • Act: You identify and implement measures to prevent the problem from re-occurring

These phases will be described in more detail in the following posts.

5 Elements of Building a Data Quality Fire Department

March 15, 2010 by · 1 Comment
Filed under: English 

For German readers: Es gibt eine deutsche Version dieses Blogeintrags.

In one of my last posts, I painted a picture of the Data Quality Middle Ages and the resulting fire storms. This post explores the elements on how to move from the Middle Ages into modern times, using a Fire Department as a metaphor.

Photo by Infidelic

Here are 5 important elements that you should have in mind when building your Data Quality Fire Department.


Of course, there is no fire department without any firemen. Foremost, a fireman’s job is to know how to do the firefighting and be trained to do it properly.

For data quality, that means that there has to be at least one person in the organization that is dealing with data quality fires on a regular basis. This doesn’t have to be that person’s only responsibility, as evidenced by the fact the smaller towns only have a voluntary fire department. Only larger towns (larger companies) can afford a large staff (department) of dedicated firemen (DQ professionals).

Fire Alarms

When someone sees a fire, he cries out “fire”, calls 911 or uses some kind of fire alarm system like a manual pull station. For data quality, this means that whoever sees a data quality problem must have some way of notifying the DQ professionals that there is an issue. This can be as simple as a mail-address, but can quickly grow into some form of issue tracking system. (It should be noted that the notification should be as simple as possible, even if for tracking purposes a more elaborate system is used.)

Fires may also be spotted by a dedicated person to look out for a fire like a night watchman. For data quality, this means that the DQ department should of course look for data quality issues on their own. In my experience however, the focus should be on solving problems (see “Firefighting” further down), especially at the start of a DQ initiative.

One more point: Today, there are automatic devices to detect fires. (BTW: You should have a smoke detector installed in your home!) For a more advanced DQ initiative, this means that there are some automatic DQ measurements taken that may also result into DQ Alarms to be raised.


In order to extinguish a fire, fireman follow a procedure. If you look at the Wikipedia article on firefighting, there are a lot of issues to take into account and different ways to attack a fire. It’s certainly not as simple as dumping some water in the vicinity of a fire!

For data quality, there has to be a procedure as well. As with a lot of quality processes, this is usually a DQ-specific adaption of the Deming cycle or “plan – do – check – act”. There is a lot to discuss here, and I will cover the “DQ Cycle” in a future blog post in more detail.

Fire Trucks

The thing that fascinates kids the most about fireman is the fire truck – an the most visible example of the tools that a fireman needs to do his job.

A DQ professional also needs some tools. There are some general purpose tools to analyze data (a SQL query tool,  more “clickable” tools like BI tools). There are also some DQ specific tools (for example, profiling tools, tools to find duplicates, tools focused on address quality).

Again, I would like to offer a word of caution: Buying a tool (especially if it is quite expensive) will not magically solve your data quality issues – after all, “a fool with a tool is still a fool”. Certainly, some tools are needed, but a DQ initiative is so much more than a tool selection process. I constantly have long discussions with clients in order to de-emphasize the tool aspect when starting a DQ initiative.

Fire Prevention

One of the biggest improvements compared to the Middle Ages comes from preventing fires and pre-planning in case a fire happens. This includes switching form easily flammable building materials like wood to fire-resistant materials such as steel or firewalls, minimizing ignition sources and educating people about the proper emergency behavior.

As after fires, DQ should try to determine how a DQ problem could have been prevented and apply that lesson in other areas. This is often tricky to sell, as other (yet unaffected) departments often look to data quality as just one more unloved requirement. It requires an excellent “sales pitch” from the DQ team, and it is always helpful to have built some goodwill by having solved earlier issues.

What other aspects do you think are important when building a DQ initiative? Which areas would you like to see highlighted in future posts? Let me know in the comments! Thanks.

Wild stuff: Nines complement date format

March 5, 2010 by · 7 Comments
Filed under: English 

For German readers: Es gibt eine deutsche Version dieses Blogeintrags.

Photo from Picture Taker 2 at

This is the first in what I hope to be a series of some wild stuff I have to deal with: Strange formats, encodings and data modeling decisions that I or others come across. 

This post is about a date format that we are calling Nine’s complement. I couldn’t find anything about this on wikipedia, and googling I could only find some mention in an obscure IBM documentation.

What we found

Here’s what we found: In one of SAP’s screens you have a ‘valid to’ date field. You can enter some date until the business information was valid (like ‘31.12.2006’). When we looked for the corresponding field in the database, the column was easy to find (called VALIDTO), but it contained values like ‘79938768’ that surely didn’t look like a date. Also the column was defined as a CHAR(8) field. CHAR(8) is not unusual in itself for a date column, storing the date in a format like ‘YYYYMMDD’ so you can sort a date by sorting a number. In that way, ‘31.12.2006’ would be stored as ‘20061231’.

It took some asking around to figure out what was going on with the strange values we were seeing in the database. What you do is you take the YYYYMMDD-format and subtract that from 99999999. Here is the whole story:

Date 31.12.2006
as YYYYMMDD 20061231
8 Nines: 99999999
minus Date-String 20061231
Date in Nine’s Complement 79938768


In order to convert the values found in the database back into a proper date, you can perform the same operations in reverse (i.e. subtract the value from ‘8 Nines’, and you get a date in the YYYYDDMM-format).

But why?

The “official” reason behind this format is that you reverse the sorting order of the dates, so that the most recent date comes first. This way, you can simulate a descending sort order in a database that does not support this concept.

As we were working with an SAP system and SAP has built an abstraction layer on top of the underlying databases, that may well be the case here. Some of the code dates back to the early 1980s, and databases were quite different back then. Sometimes I think that they even built there own database independent indexing mechanism, although these days most indexes defined in SAP correspond to indexes on the database level.

However, it is still not clear to me why defining a descending sort order in an index is important . I’ve asked a question on StackOverflow about why you would defined a descending order in an index definition, and the answers pointed to reasonably obscure situations that do not apply to the situation we were seeing. Unless there is stuff like clustered tables involved, the ordering of an index shouldn’t be important, if you’re doing an order, a binary search or traversing a b-tree, the order would not have a material effect on performance.

It would be quite interesting to evaluate the performance impacts of a “normal” date storage and a regular ascending index. I’m quite confident that there will not be much of a difference. So I can only assume that if there was a reason in the past to do this, the reasoning no longer applies. However, my guess is that someone optimized something that didn’t need to be optimized. Probably some “old COBOL mainframe programmer” from back in the days when all you could do was sequential access to a file …

Preventing the “Great DQM Fire”

February 24, 2010 by · 3 Comments
Filed under: English 

For German readers: Es gibt eine deutsche Version dieses Blogeintrags.

When dealing with the Middle Ages, there are a lot massive fires that destroy entire cities. An example is the "Great Fire of London" (see Wikipedia article). It lasted four full days in September 1666 and destroyed four fifths of the City of London, including most of the medieval buildings, and resulted in about 100,000 homeless people.

Source: Wikipedia, Great Fire London
Today, there are numerous provisions for fire protection, so that fires occur much less frequently than before. And in the case of a fire, every town and every village has a professional or volunteer fire department that can respond quickly and prevent extensive damage.

This concept can also be applied to the data quality management.

Data Quality Middle Ages

Again and again, problems result from bad data quality. Typically, these issues occur in major projects (eg, data migration or process optimization), changes in personnel or when there is a high visibility to upper management. To achieve its objectives, the project must then take care of the problems in an ad-hoc fashion. After the immediate, pressing problems solved and the projects objectives are achieved, there is no need to introduce a regular DQM. Until the next DQ emergency occurs …

This "ad-hoc DQM" has many negatives, some examples:

  • No single approach, no standard tools
  • Only the main symptoms are eliminated, without resolving the root causes
  • No preventive measures
  • Investment in DQ tools cannot be justified for a single project (either too expensive or too time consuming)
  • DQ issues are handled by various people and departments
  • No predictability of budgets and resources, therefore external support is often needed
  • When new problems occur, everything has to start again from scratch, resulting in high recurrent costs

Modern Era Data Quality

It therefore makes a lot of sense to establish a unit with the main task of regular, active data quality management. The objectives of this unit are to establish a general process, organization and technical platform to continuously monitor and improve of data quality. The relevant aspects will be discussed in further posts.

Next Page »