Profile cover photo
Profile photo
Nick Dixon
Developer. Geek.
Developer. Geek.

Nick Dixon's interests
View all
Nick Dixon's posts

Post has shared content
Summarising complex code changes is hard.
Why we (and other companies) sometimes use vague descriptions about what is changed.

Let's look at the latest release note as an example, it contained this:
”This time we bring you a updated camera and...”

What you (and actually me also as you will see soon) immediate want to know is what new interesting camera features are added. But it is harder than you think to dig this up for me. The problem is that software project are to big for a single point of information, that means that the software is developed and maintained by many persons and different teams sometimes even on different developer sites. Within each project and team they have control but in the case as it is now (when we are running this concept) we are sometimes a bit separated from the original teams.

In this case (the new camera application) the camera team is probably focused and working on the latest and greatest camera application for the models after the Sony Xperia X. They still maintains and do stuff for older models e.g. they have a version for Z3/Z3c that they get bug reports and fix stuff on and sometimes add features to. They are doing this in their own pace and have their own control over it releasing it to the official Xperia software according to the official releases.

Along comes the Concept, in the start of the concept where using and releasing it with Android marshmallow a long time before the rest of SONY needed to be finished, actually even long time before we even got marshmallow support from the vendor we are using (Qualcomm in the case of Z3/Z3c). This means that we had to solve some stuff on our own. What we did originally in the concept was to make "a copy of" the official camera code and add concept fixes/changes/addons to make it work. We took the latest version at that date (out of sync with their releases). In later releases like this one the concept camera team resynced the code with the latest and greatest code from the official camera team so all the changes/fixes done in the general code is put into the concept also. :) Since we a “taking” the code out of sync from the official camera team (on each code sync) we can no use their changelog for assistance as that is based on the official software release cycle. As the team are big and many persons are involved there is not a single person to ask about what is changed.

Usually software projects work like this working on separate "copies" (called branches) of the code in different teams and syncing the changes/features now and then. One big reason is that each project want to make sure that it works great together with the rest code and hardware in that project, but it could also have different features depending on hardware, lifetime and markets.

All this makes it a bit hard for me when I write the release notes. I can look at the code (and usually so) but mostly I start checking the list of changes with my “gut feeling” and if it’s seem to be only small bug fixes I tend to use vague description as the ones above. It usually means “many small changes, each to small to mention seperatly”. I could spend a lot of time looking at the code changes but it just gives me a humongous big list of small bug fixes usually with a cryptic text not indicating any end user description of the change. Ill show you.

In this case there are 94 changes in the code most of them have very cryptic description and it is hard to translate it into end user impact. Let’s follow one of these up a bit more as an example.

I spot this change: “Fix crash on a null object reference”.

From this I can see two things
1. It a fix for some crash.
2. There is no info on where and how it is visible for the end user, bummer.

Let’s dig some more, linked with the change I can get a link to our internal issue database with a issue description (like the one you send in using inTouch) and a link to the code change. The description in this case is minimal:

“Unknown. Crashes are reported via <automatic crash collection system>”

Not much info about why it crashed but it tells me it’s origin. Internally here at Sony we collect crash statistic from our own phones to help us find problems before releasing it to you, this crash started to show in that statistic collection system and someone reacted and created a issue report on it. But there is no info on how it crashes for users in this case. I wonder if we can dig something out from the code change?

Looking at the code change there are some more info at least :) I get a little bit better description and I can see the actual code change and in what file(s) the change are. This change was in the camera addon “fast capture” and the fix description is:

Fix crash on a null object reference
NullPointerException will be thrown when
hide tutorial view.
Add Null check and get the tutorial view object again
before mTutorial.setIsHideTemporary(true) was invoked

Some more info, but basically it tells me fast capture could crash in some unknown way and this is fixed. Still not too obvious what the impact is for you (more than less crashing in some unknown case) So I check the code change, it is just adding something like this to the code:

“If value is null (e.g. zero, this is a bad value in this case) then avoid using it.”

Not much info :( Basically this could end up in a release note as “fixed a crash when you use fast capture camera addon”. But when we have 94 changes like this (as we had this time regarding the camera) it ends up with something like “stability changes in camera”, “fixed camera” or as in this case “updated camera”. If it was a bug that many of you would have experienced we would of cause write it out.

This take quite a long time to check for each of the 94 changes I usually use my gut feeling when browsing the list and just dig deeper in the description that would be interesting for you. For example if one of these would have had the word raw or API2 in the text be sure I would have digged hard and long and would have told you.

I hope this makes it a little bit easier for you to understand why we sometimes have these short descriptions.

Post has shared content
Puts things into perspective.

Post has attachment
Now I feel old.

Post has shared content
I'll just... er... leave this here.
Great Private Eye cover.

Post has attachment
This is why we are stupid.

Cut up old books (you weren't thinking of reading them were you?) and turn them into a decorative box so that guests will think you sometimes read.

If you can hear a funny noise in the background, it's just Ray Bradbury spinning in his grave.

Post has shared content
Astonishing to see how out of touch politicians can be. Smartphones have been around for about ten years, and have been insanely popular for the last five. There's no excuse for looking at one now and asking "What should we call this?"
THIS is how plugged in and tech-aware our leaders are. I have NO words. Oh, one. SMARTPHONE. 

Post has attachment
I do hope imitation is just sincere flattery, and nothing more.

Post has attachment
Well who wouldn't be tired and emotional on their last day at work?

Post has shared content
It's nearly done...

Post has attachment
Bit of light reading for me later...
Wait while more posts are being loaded