Restarted Melbourne Edition of Startup Digest

fter a bit of a hiatus I have restarted the Melbourne Edition of Startup Digest, a weekly newsletter showing events in Melbourne that are of interest to entrepreneurs, creatives, technical professionals and business professionals.

It tends to be orientated towards the software industry. Despite things powering down for the holidays there is still quite a few events going on.

If you subscribe there is also a calendar of upcoming events (need to sign in).


Update: The following is an excerpt from the beginning  of the newsletter I put out on the 3rd of August 2017.

THU03	Silicon Beach August 3rd 5:30pm
Drinks & Pitch Night Royal Melbourne Hotel 629 Bourke Street, CBD | View in Calendar
THU03	Software Testing (Free) August 3rd 6:00pm
Talk: Exploring SET - Arun Sivasubramaniyan Carsales.com.au 449 Punt Rd, Richmond | View in Calendar
THU03	Talk Data To Me (Free) August 3rd 6:00pm
Discusses data and the infinite possibilities for the travel, transportation and tourism industry. General Assembly 45 Williams Street CBD | View in Calendar

Everything is High Priority and Distributed Agile

went to the Agile Product Owners and Business Analysts Meetup Group last night.

The facilitator cancelled at the last minute. Since I was the only Co-Organiser at the meeting I stepped up and ran the session.

I wheeled out the whiteboard and we brainstormed topics that the attendees wanted to talk about. Then we dot voted on the captured topics and two of them received most of the votes.

1. Everything is High Priority 
2. Distributed Agile

Everything is High Priority 

It seems to be a universal experience. Almost everyone has come across bosses, stakeholders or customers who refuse to prioritise.

Most of the solutions generated by the attendees involved avoiding the concept of priorities altogether.

• Using Ranking (Not allowing items to have the same priority. Just using a ordered list.)
• Using Defaults (Telling them your best guess priority and telling them that unless you hear back from them you are going with that)
• Using Business Value.
• Using Business Value divided by Estimated Time of development.
• Using Risk (what are the elements that have the most unknowns)
• Controlling the size of the backlog / ranked list.

Distributed Agile

A large percentage of attendees had experience with distributed teams.

The issue that seemed to cause the most trouble was timezones and either non-overlapping business hours or where the overlap was small.

There was also agreement that some sort of digital Kanban Board or some other form of item tracking was vital.

Some face to face contact was also considered vital.

Sharing the pain of off-hour meetings and not letting one sub-team feel like second class team members was also mentioned.

Making sure that all sub-teams had a clear understanding of the process and a clear understanding of the reasons behind the process could be an issue. Credibility of the company could be an issue as there was a danger of Agile being seen as a business fad if it was enforced top down.

  

Zen, Improv Theatre and Responding to Change

teve Mitchell conducted a very interesting and useful session at Agile Coaching Circles last night.

I experienced Steve's workshops before at LAST Conference 2013. Along with the session on visual communication his session was the most memorable workshop at that conference. I have certainly obtained a lot of mileage out of those workshops over the years. I have used them on software teams to increase mindfulness and creativity, at my toastmasters club as an ice breaker and on my children as a fun bonding activity.

Steve's workshops are an interesting blend of Improv Theatre, Mindfulness Training, Divergent Thinking Training and Buddhist Philosophy. With one exception the exercises  Steve taught were different from the ones I learnt before.

He started off with a spatial awareness meditation to help get us in the mood and shake off the cares of the day. 

When I have used Steve's exercises on client's before I haven't incorporated his Eastern Philosophy, however after the session last night I am starting to think that was a missed opportunity. The Buddhist religion has surprising synergy with Change Management as its core principle is the need to be open to change, that all suffering is caused by resistance to change, by attachment to the Status Quo and our own Imagined Future. I probably won't mention to my clients that elements of what I am teaching come from Buddhist Philosophy. Steve certainly didn't mention Buddhism during the session, I was only aware of the origin of some of the ideas from other sources. Mindfulness, of course, comes directly from Buddhism, even though listening to Western Psychologists and Business Gurus, you would think they invented it.

It was a refreshing change to attend a workshop that was so active. This active participation  is one of the reasons I find Steve's exercises so valuable. Instead of passively receiving the wisdom of the presenter the attendees are constantly engaged participants in their own learning.  Even small workgroup sessions are not this active.

Instead of teaching us how to convince others how to accept change, Steve taught us to be more open to change, by both, teaching us by example, and teaching us that change begins with us.

Common Complaints heard at the Scrum User Group Meeting

attended September's Scrum User Group meeting where we split into 6 workgroups of about 6 and discussed what issues outside our traditionally immediate sphere of control where causing us problems. Areas that might not get addressed in a normal retrospective as being outside scope. Although I must say that my teams have discussed most of the topics brought up in the Scrum UG in retrospectives at one time or another.

The first thing I noticed was how similar the problems brought up by my fellow workgroup members were. The first half of the session was devoted to identifying problems, after which workgroups created cards outlining the problems which were then displayed.

We all examined each other's cards. We were supposed to pick a card, then form another set of workgroups to brainstorm a solutions. All the card listed very similar problems. In fact I couldn't tell which one been written by my original group.  I picked one at random and a second workgroup formed to tackle brainstorming solutions.

The number one pain point was

Constantly Changing Requirements

Most people wanted to freeze requirements and / or reduce / funnel / manage communications.

Interestingly the Aconex Project Manager was very much against freezing the backlog during a sprint.

My approach to the problem is the opposite.  I will increase communication often with a larger pool of stakeholders. I will make the conversation more concrete with design mockups, paper prototypes, mocked up screens with fake data, and more traditional partially functional prototypes.

Changing Direction and Losing Focus

There is a tension between maintaining a targeted focus and being adaptable enough to respond to an evolving understanding of the requirements. However I would rather lose a little of the sunk costs than end up with something that is not going to be used.

If it is clear that the stakeholders are not able to provide a clear consistent vision for the product or service that the team is building I am not afraid of going back to the discovery phase.

The natural tendency is to start coding too soon.  At the initial inception and discovery phases I prefer to use whiteboard, flip charts and pen and paper. Even when Teams resist early coding, they often go to Illustrator and Photoshop too soon. It is better to use hand drawn designs to build the initial consensus.

Scrum usually recommends not interfering with the sprint backlog within the sprint, but in practice work items are constantly being re-evaluated and re-interpreted as the sprint progresses. Just because you have the same card on the board as it travels from the waiting end of the board to the done end of the board, doesn't mean that it symbolises exactly the same task at the end of the sprint as it did at the start.

Interruptions

One solution that is often proposed is placing a gatekeeper between the development team and the stakeholders. Statistics and studies are often cited that show the high cost of context switching and the frequency of interruptions in the modern workplace. However the gatekeeper usually becomes a bottleneck. Communication suffers and is distorted as gatekeeper re-interprets and re-phases the information according to her understanding and experience which is often different from both the development team's and the stakeholder's. Most teams suffer problems because of lack of communication and a gatekeeper's job is to reduce communication.

My solution would be to setup cadences of set times to to co-ordinate or ask for assistance and have the team come up with their own protocols on how and when to interrupt.  Often it is we, that interrupt ourselves. So turning off toast and only checking email and messages at set intervals can help.

Often the cost of changes and interruptions fall unevenly on the team overloading your knowledge keepers, your specialists. Shifting your highest performers to coaching and training the other members of the team will mean loss of inefficiency, productivity and poorer quality in the short to medium term. Yet failing to do so, can lead to them being overloaded, becoming bottlenecks, and risking knowledge loss when they leave.

Other Issues that were discussed where

• Misalignment
• Bike Shedding
• The Big Rewrite
• Bring me a Rock
• Zombie Projects

Unsurprisingly the Convenor / Moderator / Event Organiser Craig Brown picked up on the similarities in topics workgroups focused on, as well. There was a discussion at the end where the themes of the night were elaborated and possible solutions shared.

Pencil and Paper Battleships

chool holidays and I wanted to spend time with my daughters. I remember how I used to play Pencil and Paper Battleships with my brothers. I do a search and none of what I find is anything like what I used to play with my brothers. So I made up some sheets from memory and they were a big hit with my daughters.

Maybe a kind reader could tell me where we got these rules from. I am not sure whether we made them up or got them from somewhere else.

Burns Family Rules for Battleship

Place the following battle units on the “Your Ships” grid. The units can be rotated or flipped to face any direction. However they cannot be placed running in a diagonal direction. Units cannot be placed next to each other. There must be at least a one square gap orthogonally and diagonally between each unit.

The following ships must be placed in ocean squares on the grid.

The following air units must be placed on any squares on the grid.

The following ground units must be placed on land squares on the grid.

Now that all units have been placed on the grid. Each player takes turns guessing the location of their opponents “Ships”. They fire off a “shot” by calling out the ‘Letter’ and ‘Number’ of a location on the grid. Their opponent calls out ‘Miss’ if they have nothing at that location and ‘Hit’ if they do have something there. If all squares of a ‘Ship’ have been hit then the opponent announces the type of “Ship” sunk and the fact that it has been destroyed. The tally box of the ‘Ship’ (to the right of the grid) should be crossed out when a “Ship” is destroyed. The first player to destroy all their opponents ‘Ships’ wins.

Three times in a game a player can use a mega-bomb. Mega-bombs hit everything at the called location and all 8 adjacent squares. The opponent calls out any hits from the bomb and their location plus the names of any ‘Ships’ destroyed. Cross out an ‘M’ tally box each time you use a bomb.

Game Sheets 

• Small (17x12 Grid)
• Medium Small (18x14 Grid)
• Medium (18x15 Grid)
• Large (18x18 Grid)

Source Code on Github for Simple Card Game written in Swift

knocked up a simple game in swift using SpriteKit as part of a job interview. Its based on a game my family plays all the time using real physical cards. I put it in the app store under the name Rickety Kate and uploaded the source to Github. You might find it takes 8 to 16 days for the code in the repository to find its way to the app in the App Store, one and half review cycles on average.

I probably over engineered this one. You can build your own deck of cards, anything from a 40 card deck with 4 suites to a 168 card deck with 10 suites. I knocked up some very simple input controls to control the options.

Putting 1x and 2x images  in texture atlases was a little finicky. I did a little experimentation and the 2 versions of the images seem to need to be in the same atlas for the 2x images to be automatically used in a retina device. Also here were problems unless all images in a atlas had the same number of versions e.g. they all needed to have 2x versions or none should have them. I have not tried using 3x images yet.

I am going put out a series of very simple games and apps. I put out another card game called Sevens. Next one after that is going to be a tilt game with retro neon line graphics. Set in the wreckage of a large city post alien invasion, you pilot spacecraft picking up refugees, and ferrying soldiers, diplomats, wounded, equipment and supplies while avoiding Lurkers, Tripods and Space Jellyfish.


Update: Rickety Kate 1.1.4 Just passed review (22/01/2016) and Sevens v1.0.2 just passed review (09/01/2016)

Rickety Kate is now localised for English, French, German, Portuguese and Spanish.

Is it worth while transitioning from Objective C to Swift?

'm late to this bandwagon. However I had a heavy investment in an Objective C code base and a lot of distractions. Enough with the excuses, better late than never.

I know others have held off for many of the same reasons I did. So the question is useful. Was transitioning to swift worth it? The answer is a definite yes.

The Pros

No pointers and no nil-able values or objects unless they are wrapped in an option. This cuts down on a large class of errors.

Named parameters. This language is targeted for Objective C programmers so of course it has name parameters, however I still count it as a plus because named parameters increase readability and are a good idea, even C# has named parameters theses days.

No lisp-like nested square brackets everywhere (yes I know lisp uses round brackets, however I am talking about the nesting behaviour)

Immutable values using the let keyword. This reminds me of Scala's val and var keywords and of F#'s let keyword, although F# makes it harder to make values and objects mutable. Immutable values can make an application easier to reason about and make it easier to do concurrent programming (less need for locking)

No more header files.

Memory management that doesn't feel like a tacked on after thought .

Only one form of closure instead of the two different flavours in Objective C (selectors and blocks)

The 'if let' statements ability to chain together multiple let statements capped with a where cause reduces nesting and as nesting plays havoc with readability this is all to the good. There is a 'if var' version but I never see it used.

Swift has its own REPL which in Swift's case is called a playground. REPLs are common in many interpreted languages, they are ideal for learning and experimentation. REPL is pronounced 'reppel' and stands for Read Evaluate Print Loop and at its heart in a very simple, effective and old piece of technology.

No more need to box and unbox value types just to use collections. I remember when C# had this problem (versions 1.0 and 1.1 fixed in 2.0), but at least C# 1.1 had the __box and __unbox keywords,  in Objective-C you have to wrap and unwrap value types by hand.

Swift has generics, type safety and even type inference. Plugging that hole (lack of generics) in the type system pays off massive benefits in reduction of errors and increased ease of use. There is no way to have general purposes containers like lists and dictionaries without either having a generic type system, using dynamic types or breaking the type system by casting away type.

Less use of special characters in syntax, no more semi-colons at the end of your lines and a more modern cleaner looking syntax.

Initial Annoyances / Gotchas

You will need to lose the habit of surrounding if conditions with brackets as this can break things. This is initially is frustrating, but when you get used to it, it actually looks cleaner.

Significant white space between operators and operands or lack there of will turn binary operators into prefix unary operators.

Xcode habit of warning you that you have not used a declared variable or constant straight after you have declared it and before you have had the chance to type the line that will use it, can initially be distracting.

The Cons

I am used to uninformative and obscure error messages, but Xcode has reached a new low in this lost art of sowing confusion. After a while you get an idea about what it could be complaining about, but even when you know what is causing the problem, drawing a meaningful relationship between the error message and the cause of the problem can be bewildering.

The navigation and intellisense  tends to break when you need them most.

No refactoring support for swift yet compared to Xcode refactoring support for its other supported languages, not that Xcode Objective-C refactoring support is terribly good, but at least its there.

Lost Opportunities

There is a lot I could say about this, but Objective-C does worse in features I want to complain about so I will just point you to a post that Rob Napier wrote about how swift is not functional and save the rant I was going to write here for another blog post.

The Experience

The first one or two weeks was frustrating. Most of the frustration was centred around the compiler. However the learning curve was surprisingly easy. After two weeks I felt more comfortable with Swift than Objective-C even though I have been using Objective-C for years. Their is very little in Swift that isn't a standard expected feature in a modern programming language. Even the syntax and the keywords are pretty stock standard. Given the blandness of Swift the main reason for its existence is obviously to have built-in compatibility with the existing libraries and APIs and to make migration from Objective-C and interoperability with Objective-C easy. In achieving these goals Swift is successful.

Conclusion

I am not going to rewrite all my Objective-C code base in Swift. However all new work is going to be in Swift and even major modifications to old projects will probably be in Swift as you can mix the two languages in the same project.

The Secret to Managing Images, Sounds and other Resources for Mobile Apps

our simple rules

1. Automate, Automate, Automate
2. Keep all the source artefacts and scripts needed to produce the final resources under source control e.g git or mercurial (don't bother with the derived images)
3. Give everything long descriptive names and a systematic logical folder hierarchy.
4. Use texture atlases rather than individual images ( originally I used Zwoptex to generate texture atlases for me, but now days Xcode does it automatically for me ).

When you first start adding images and sounds to your app it doesn't seem like a big deal to do things manually. Any half baked semi-functional  process or algorithm works as long as 'n' is small. But as the number of images and sound clips grow you will pay a higher and higher price for poor decisions you made at the start. It does not take long before you have hundreds of images and sounds. Any technique that allows you to cut down the number of images is a technique you should use. A favourite trick of of mine is to split an image into several layers and to tint one or more layers programatically to get several different colour themed images.

One of the reasons images breed like rabbits is the different resolutions and aspect ratios of different devices. Making different images for each device manually is the road to insanity. There are two different approaches to get around this problem and I use them both.

Solution 1

Make your images at the highest resolution and then down sample to get your lower resolution. One of my favourite tools to do this is ImageMagick as it has a command line interface and therefore can be called from a script. You can use it to resize, crop and rotate images plus much, much more. If I am using a Mac prefer to use the MacPorts package manager to install apps like this, if I am using Windows I use the Chocolatey package manager.

Once you have a package manager  you type in the following into the terminal for the mac

sudo port install ImageMagick

or the following into the command window for Windows

choco install imagemagick.app

Nicholas Waynik has a tutorial on how to use the resulting images on the iPhone and iPad.

Solution 2

Use a vector format like SVG and then you can rasterise it to any resolution you want. I tend to use this solution as I have the habit of going back and spitting my old images into parts in order to animate or reuse the image in someway. It is easier to modify a vector image later if you have to. Inkscape is a good drawing app to use for creating the images.

It does have a command line interface but you have make it jumps though hoops if you want to make it rasterize an entire folder of vector images. Which is exactly what I am always going to ask it to do. You do not want to create the final rasterized (e.g. *.png) images this manually though the GUI. Remember rule number 1. I use the following snippet in the bash scripts I use to generate the final images.

for i in /full-directory-path/*.svg; do /Applications/Inkscape.app/Contents/Resources/bin/inkscape $i -w 100 -h  200 --export-png=`echo $i | sed -e 's/svg$/png/'`; done

and for the 2x images

for i in /full-directory-path/*.svg; do /Applications/Inkscape.app/Contents/Resources/bin/inkscape $i -w 200 -h  400 --export-png=`echo $i | sed -e 's/.svg$/@2x.png/'`; done

You can either copy and paste these command into a mac terminal window or place them in a text file with a *.command extension to create a clickable command.

I modified the this script based on a piece of bash script voodoo I got from gastarbeiten who in turn got it from someone called forger. The original script no longer works because the upgrade to inkscape 0.91 broke it, thankfully it only took a minor tweak to get it working again. Fair warning these scripts sometimes need little care and feeding every now and again. I seem to need to fix them about once every 6 months. Despite the very occasional annoyance these scripts are a life saver.

Originally I used batik to do the rasterization as it supports processing multiple files out of the box without any fancy script voodoo. However a Java update broke the software and there was much pointing of fingers and little solving the problem. They have probably fixed the problem by now but I have moved on.