The generalist specialist

I’ve been having a lot of conversations with startups lately. I love their energy and sometimes “simple” view of the world, in which everything is possible. In a way they are correct, and I’m probably getting old(er). I’ve been coaching startups to help them organize and prioritize their projects and ideas. This is all very fascinating but here is what strikes me. I see myself as a generalist, but they see me as a specialist.

There are a very wide range of items I’m interested in, from design, programming, music, architecture, painting, literature, cooking… If I considering myself to be a generalist, I also believe I know some stuff about those domains, but I don’t consider myself to a specialist. I presume that people who earn a living in one of these domains, will be better informed, and more professional than me… but apparently this is often not the case. This makes me very smart, let’s say a genius, but I know that’s not the case 😉

I’ve noticed over the past 5 years, that nobody takes the time to really understand anything anymore. We get some high level info about a topic, which gives us a partial and distorted understanding of the topic, which we use to construct our logic on.

In my professional field of software and project management, there are less and less people that have a good understanding of the business processes of their customers. Enterprise architecture (EA) is often seen as a technical decision, completely separated from the business logic. Everything is divided into generic micro-services for reusability, which is good from a EA standpoint, but which can be a disaster from a business logic point of view, making applications overly complex and too dependent on reusable components.
We’ve reached a point where we stop looking for a solution if we don’t find an answer after a few hours; where a software developer changes from platform and technology every year. How can you become a specialist if you only have been using a tool for a few months? They do it because this way they are in demand, and they can ask a higher price. But it doesn’t deliver a better end result, in my opinion.

So as a generalist, who understands how things work, and takes the time to understand stuff, I go further and deeper into complex problems, and turn out to be a more specialized person than you’d expect.
Startups need flexibility in concept thinking and problem solving, and than the expertise to quickly execute the developed concepts. Business logic and business insight are way more important than a discussion about the technology landscape.


What’s on the table

Ok the title is probably misleading. In this post I liked to talk a bit about tableau. Tableau, and is this case public Tableau, is a free data-visualization tool, that allows you to share visualized data on-line, for free. Have a look at the tableau gallery with the vizz of the day.

Tableau desktop (free for MacOS, Window…) allows you to link data in the form of static files (Excel, csv, pdf,json…) or online data (e.g. Google Doc – sheet, databases…), and visualize your data.
You can visualize data in worksheets, like a chart, a table, a map. You can than combine these worksheets in a dashboard, and add text, links, images… to explain the dashboards. These dashboard can be seen as slides, which you will use in a storyboard, to tell your story.

It’s completely up to you how to tell the story. You could start with a global birds-eye view of the data, and drill down to some detail, and maybe come to a conclusion. This is a great way to visualize data for a presentation, but the most powerful thing about it, is that this is not a static slide. As a user of this visualization, you can filter and view the data the way you want, and interactively get a better understanding of the data. Of course, as with all visualizations of data, it can become painfully obvious, that some of your data is incorrect or incomplete, so be prepared to clean up your data…

So why am I looking at tableau? In the context of my general interest in genealogy, I’m always looking for ways to visualize data, and in this case how to easily compare data, and look for data in my family tree.
In a first step I am converting GEDCOM files to useable files for tableau. Publishing my family tree in a tableau vizz makes looking for relatives interactive and fun, compared to the static html pages exported by most family tree apps.
In a later fase I want to compare 2 (or more) GEDCOM files, and look for places, people, events that might overlap… trying to determine if there might be a connection… This could be an interesting tool for the genealogy detective.

If you are interested in the test tools we are writing, and like to participate, you can contact me at

Have a nice weekend.

The life of a developer

Looking back on last year, I can say it was a very interesting year. There were complex projects and a lot of new tech to learn.

I think the most used tech term in 2017 was AI (Artificial Intelligence) or more specifically ML (Machine Learning) and it’s siblings like neural networks… I’m not going to explain AI or ML here, there are a lot of sites that can explain it better than I can, but I do want to talk about the perception of AI and developers to the general public.

Developers are often seen as these nerds that type stuff in the computer to make it do what they want it to do. Developers are also these people that cause all the bugs, or don’t understand what the user wants. They are the reason why your app doesn’t work, or does work the way you want.
AI is presented as the magical solution to fix all this, and developers will not be needed anymore… In some presentations AI is this thing you talk to that will figure out what you want, and will take care of everything. Well, good luck with that.

From experience I can tell you that most users have a hard time explaining what they exactly want. The way people explain what they want is full of pre-conditions, assumptions and limits that are so obvious to the person in question, that it is never explained or even listed. An App needs to know these assumptions, limits and pre-conditions, otherwise it will not work or work badly. What I’m saying is that when you can not provide a framework, a structure to an AI, it will result in a disaster. Maybe developers will become more like business analysts, I don’t know, but I do know you need to understand the process, the flow, the logic of an App for it to work.
Unfortunately, we see the opposite trend with users. More and more users only know their little part of the process, and not the whole picture. For an AI to write an App, someone will need to tell it what to do… For a super easy app this may be an end-user, but for more complex apps… I’m almost sure it will need to be someone else.

2018 will be great for developers. It will be interesting on all fronts. Developers will be needed more than ever. AI, AR (Augmented Reality) and ML will be more and more integrated. IoT (Internet of Things) will take of. BlockChain implementations will become mainstream… and so much more. Business analysts and developers will be in demand.

Have a happy and wonderful year.


I don’t know if you ever read the book rework, from the founders of basecamp, that’s what I’ve been doing: rework.

In the last posts I’ve been writing about the switch to programming in swift, and the setups for synchronizing data between macOS and iOS through CloudKit. Well, it’s still not finished, and I’ve started reworking my apps. Let me explain.
I’ve rewritten the iOS app in swift, and written a macOS version of the app. So far so good. This is all working fine on the local devices. I can also get data from CloudKit and sent data to CloudKit on both platforms, so that’s fine too. But covering all scenario’s to keep everything in synch, is more challenging than I thought.
You expect to be able to work with all your devices in an off-line mode. You may be on an air plain with your MacBook, or your iPad has no mobile connection, only WiFi… you expect that you can get all data magically synchronized and up-to-date once you get a connection. Your iPad may have not been on for several days, but you updated a lot of stuff on your iPhone…
Deciding how to manage changes you make in your local app, and tracking if the changes are uploaded successfully to CloudKit at first sight seems straightforward. But than you have to managed conflicting changes made on the same record (data) on different devices. So you start tracking changes and the moment that change was made, and compare it to what is in CloudKit… Before you know it you add state and date/time tracking to every field in your database… It’s a mess.

So you rethink what information is stored when, where, how, and what the logic is behind it. You write this out and think of all the possible use cases, to see what works for your app. You try to keep a good balance between complexity and functionality, keeping in mind that for the user, the behavior is normal and consistent… So that’s the challenge for the next weeks or so… reworking change logging and business logic…

Sounds easy enough. I’ll let you know.

MacOS and Swift 3.0

About a month ago, I started working on converting an iOS app to Swift 3.0. The iOS app was basically converted a few weeks ago, and additional functionality has been added. The macOS version didn’t exist, so I started from scratch. One of the most important reasons I’m doing this exercise, is to test the CloudKit synchronization over different device and platforms. Not just as a proof-of-concept, but as a completely functioning solution. I already got the synchronization working between my iPhone and iPad, but with the Mac it didn’t work.

Years and years of developer info on stackflow often helps, but for Swift, you better specify that you want swift 3 examples and even than you will mostly get iOS code. With Objective-C you mostly get iOS code as well, but in the case of Swift 3, this is double so.
So you download examples of Apple and others; you look at wwdc videos to see what you missed…. nothing. This should work!
So what I usually do, is continue with other stuff, and in most cases you find the solution sooner of later.
By chance, I was working on another iCloud issue, when I noticed I had switched iCloud accounts. Meaning, that when I’m developing in xCode, I connect with my developer account to iCloud (and CloudKit), and my iMac was using my personal iCloud account… of course this doesn’t work. Accounts are synchronized, not devices, so when you are not logged in to the correct account, you don’t get any updates. OMG, how stupid.

That being said, I do find Apple should allow me to have more than one iCloud account active. Maybe you have a personal and business iCloud account, and you want the corresponding apps to sync, or even get the info of the two account both displayed in the app.
You could share items with other accounts, but this doesn’t really cover it for me.

Anyway, I learned a lot, but basically lost a lot of time trying to solve a problem that didn’t exist.
Have a nice week…

How swift is the progress

In my last blog I talked about switching our development completely to Swift. So how does it go.

To be honest, better than I thought. A good book and documentation helps of course, but it’s easier and more transparent than I thought. As explained in a previously, I’m rewriting an an existing app, which makes things a lot easier. You don’t need to think about the business logic, so you can focus on the code. In this app, you encounter all the typical code, you’d use in other apps. The if…else, for..loop, Core Data fetching, error handling… etc… You quickly get used to the different syntax, and fortunately the syntax is very consistent and logical.
I do write the code in an Objective-C like way. One of the requirements of Objective-C is that you need to explicitly specify things. A NSString is an NSString and not an Array or a NSMutableString. In Swift you don’t need to do this, but I do specify it in most cases, just because I find it easier to understand. An other way to do this is giving a variable a name that corresponds to the content and it’s type. For example dateString or dateArray… anyways, things are going fine.

Next up is building a web app. The iOS and macOS apps both sync data to iCloud using CloudKit. So now it’s time to have a full functional web app, that more or less matches the iOS and macOS functionality. For this we’ll use CloudKit JS and build a web app with data binding and responsive design. This will take some time, because we haven’t got a lot of experience in this domain. The world of web development keeps on changing very quickly. Frameworks that where popular last year didn’t always keep up and are dropped by developers. This is the a world where you can’t predict what will come next, in contrast to platforms from Apple or Microsoft.
So the challenge is on. I’ll give an update in a few weeks…

Have a nice weekend!

Swift (for ever)

From now on, we’ll always be using Swift as our programming language.

Learning Xcode (Apple’s development environment) and Apple’s programming languages can be hard. When I first switched to Xcode, it took me a while to get used to all the tools, the debugging …etc. Don’t get me wrong, I love working in Xcode, and it has developed nicely the last years, with some really cool features 😉
When I first started working in Xcode, the programming languages to use were Objective-C and C, and I have to say that once you’re used to Objective-C it is a very powerful language. Than Apple introduced Swift as a new programming language in June 2014. Swift 1, was definitely too early (for me) to start with. Swift 2 and 3 followed in 2015 an 2016, and with Swift 3 I got the feeling that it was time to switch. But you are working on this project, and it is so much easier not to learn a new language while you are developing a new App… On the other hand, you don’t want to get stuck with old code, that you’ll have to rewrite in a few years… so when do you switch?

Apple does completely support new functionality in Swift and Objective-C. But what triggered me to switch is the online programming communities, like stackoverflow … etc. Over the last year, it has become clear that most online examples are only in Swift. In general it isn’t difficult to find the matching code in Objective-C, but it is a big sign saying “switch now”. This is of course more so for new features than for older topics.

So I’m rewriting an App from scratch in Swift. Admittedly, it’s not the biggest App, and there’s some redesign on the app… but this way the coding can be a mix or “copying” existing code and adding new code.
New apps that are under development will also be refactored to be in Swift, so that all updated and new Apps will be in Swift.

So this is goodbye to Objective-C and hello to Swift. Go…