Profile

Scrapbook photo 1
Scrapbook photo 2
Scrapbook photo 3
Scrapbook photo 4
Scrapbook photo 5
Nick Dixon
Works at Sky
89 followers|116,341 views
AboutPostsPhotosVideosReviews

Stream

Nick Dixon

Shared publicly  - 
 
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
[cause]
NullPointerException will be thrown when
hide tutorial view.
[solution]
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.
9 comments on original post
1
Add a comment...

Nick Dixon

Shared publicly  - 
1
Add a comment...

Nick Dixon

Shared publicly  - 
 
I'll just... er... leave this here.
3
2
Add a comment...

Nick Dixon

Shared publicly  - 
 
I do hope imitation is just sincere flattery, and nothing more.
The snobs and critics will have a field day with the US author’s latest work – but I’m not joining in
1
Add a comment...

Nick Dixon

Shared publicly  - 
 
Well who wouldn't be tired and emotional on their last day at work?
POPULAR Radio Stoke DJ Paula White had to be taken off air just 30 minutes into her farewell afternoon show – after she appeared to be slurring her words.The presenter, who was due to host a...
1
Add a comment...

Nick Dixon

Shared publicly  - 
 
Always wondered about this...
1
Add a comment...

Nick Dixon

Shared publicly  - 
 
Puts things into perspective.
1
Add a comment...

Nick Dixon

Shared publicly  - 
 
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.
6
Add a comment...

Nick Dixon

Shared publicly  - 
 
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. 
443 comments on original post
1
Colin Wernham's profile photoNick Dixon's profile photo
2 comments
 
But I wonder, as I do with most politicians, whether he's really that ignorant or just talking down to his audience because he thinks they don't understand.
Add a comment...

Nick Dixon

Shared publicly  - 
 
It's nearly done...
1
Add a comment...

Nick Dixon

Shared publicly  - 
 
Bit of light reading for me later...
1
Add a comment...

Nick Dixon

Shared publicly  - 
 
Boston police didn't lock down the entire city. They locked down the entire city except for the donut shops.
1
Add a comment...
Collections Nick is following
Work
Occupation
Software developer
Employment
  • Sky
    Developer, 2015 - present
  • University of York
    Web Developer / Systems Integrator, 2014 - 2015
  • The British Library
    EThOS Technical Developer, 2007 - 2014
  • PA Sport
    Developer, 2006 - 2007
Links
YouTube
Story
Tagline
Developer. Geek.
Introduction
I fix stuff that's broken, and sometimes actually write code for a living. Don't know how to work people yet.
Basic Information
Gender
Male
Easy access to Watford and nearby villages. Hotel feels a little maze-like, but the rooms are a good size. Staff are friendly and helpful. Breakfast was plentiful and satisfying. Disappointed that Hilton still feel that WiFi is something guests should pay extra for – even in 2016. But that's a group policy, not the staff's fault.
Public - 5 months ago
reviewed 5 months ago
Well-appointed room, friendly and polite staff. Only let down a little by the staff seeming to be too busy to attend to everyone in the restaurant.
Public - 7 months ago
reviewed 7 months ago
4 reviews
Map
Map
Map
Whether eating in the restaurant or as a takeaway, the food is always excellent: good range of dishes, good tasty ingredients and generous portions. Staff are consistently friendly and polite. A little pricey for the area, but worth it. There's also a cheaper self-serve buffet option on Sunday evenings.
Public - 3 years ago
reviewed 3 years ago