Stand-up for Lock-down

Stand-up meetings have always been one of the most important features of Agile working. It gives everyone to update on what they achieved the previous day and what the commit to achieve in the coming day. When people voice these achievements and commitments amongst their peers and stakeholders, it makes them more real and more likely to stick. Likewise the early identification of "blockers" and dependencies allows for swift action to be taken so as to not become a project hindrance or bottle-neck that will cause major problems later on.

But, at times like this with most people working from home and isolating themselves from neighbours and colleagues, the stand-up meeting can take on new responsibilities and become an even more valuable management tool. Isolation has always been a concern for those working remotely, hours or even days at a time, sitting in front of a screen squinting at your IDE or terminal program of choice can have a detrimental effect on our mental health and motivation. The tendency for technologists to sit and work on a problem until it is solved can mean losing track of time, forgetting to take breaks and further isolation.

Stand-ups are a great way to start the day and get everyone to their work-station to kick-start their day, they can be done perfectly well over Teams or Slack with the Scrum Master sharing their screen to discuss the Scrum Board or backlog. However, this meeting can be so much more in times like these and here are some tips for getting more from your stand-ups and maintaining team cohesion at a distance.

Run VT!

Nearly all collaborative platforms such as Teams, Slack or even Skype has screen-sharing and video capabilities, the first thing you can do is tell everyone that they need to join with video enabled. This seems like a small thing, but you would be surprised at the difference it makes. People will be much more social and interactive if they can see each other face-to-face. Social interaction is more than simply voice, non-verbal communication carries nuance and feeling and will make your stand-ups more fun and more valuable. It also has the side-effect of encouraging everyone to wash and get dressed before the call. Keeping a routine when working remotely is one of the most important things you can do, your team will feel better and be more productive if they start the day fresh.

Bantz

Uggh - I dislike that word, but keeping things light and humorous will make the Stand Up something people look forward to, rather than dread. Talk about your day, share TV shows you have binged, stories from home. Try and build a water-cooler like environment to get a little bit of chat going - this doesn't mean that meetings have to go on for much longer than usual, but a quick personal interaction can really help. It is also worth checking that everyone is on good form, you can throw in the odd bit of advise too - tell them all to phone their mother after Stand-up, for example.

Theme a Friday

We are going to be working remotely for some time yet and keeping things fresh is going to be tough after a month or so. Why not do something silly, just to keep spirits up? For example, set "Friday is hat day" where everyone on the call has to wear a hat - it is silly, but it breaks the ice and encourages chat.

Not Agile? Stand-up anyway

Even if you are not running an Agile process, or work in an industry where it is not popular Stand-up meetings can still hold a lot of value, particularly at times like these. Consider instituting a 15 minute meeting at 9am each day, it will pay dividends almost immediately.

Apps

If you are a Microsoft site, I am presuming that your organisation already uses Teams or similar, but if you are looking for a collaboration tool, I would recommend [Slack] (https://slack.com) - its free tier is probably all you will need, but for small teams the paid tiers are very reasonable.

COVID-19 - what have you changed?

As business leaders and individuals, we need to look at our people and ourselves and make changes.

These are strange and worrying times, we are faced by a situation we have never had to deal with before and are faced with decisions that no-one in the west has experience making. However, I think there are two simple ways of looking at this that should help in building an effective plan.

1. If you haven’t changed anything - you are part of the problem

We all need to change the way we live our lives, if you ave not changed your behaviour, or your team's working practices, you are doing it wrong! Everybody has changes they can make and I am not talking about just hand-washing and bottles of sanitiser, you need to make significant changes to the way you organise your teams and live your life and if you are still talking about what you can do, you have left it much too late. If you are still talking about phase 1 and phase 2 plans, you need to ditch them and jump to phase 3. Almost every action taken by governments and enterprises would have been much more effective if they had been done two weeks earlier. Make change, make it bold and make it now.

2. Act like you are already infected

This is not about preventing you and your team from contracting the virus, if that is what you are planning for, you are looking down the wrong end of the telescope. This is about stopping transmission, the way to look at this is to ask yourself "What would I do if I had already contracted the virus?" - the answers to that question are what you should be doing now. Right now, your team needs leadership, they are looking to you to tell them how to work and how to live. Don't rely on governments to spread the word, or hope your team will infer best practice from what they know from elsewhere. You need to make a decision and communicate it effectively in clear and simple terms. Clarity is key, telling your people to work from home "where possible" is not good enough, tell them to work from home unless told otherwise. People make poor decisions when worried about their job or health, you need to remove an ambiguity and make the decisions for them.

Also, it is likely that productivity will drop, at least in the short-term - you should let your team know that this is OK. Finally - talk to your team, tell them what you are doing, if you cancelled a cinema trip - mention this. If you are speaking to elderly neighbours to offer help - share this with your team. There will be benefits that come out of this situation, better communication and team cohesion could be one of them. If you have regular meetings that are now being done remotely, encourage people to use video, it creates a closer bond and encourages people to keep a routine.

Microservices - Good Things Come In Small Packages

There is an old adage that the best way to solve a problem is by breaking it down in to smaller problems, this may seem like an obvious approach and humans have probably being applying it since we lived in caves, but just do a web search and you’ll find many self-styled “Tech Gurus” and “Life-Hackers” explaining this as though it were some kind of new Alchemy.

It is also not a new concept in software engineering - even when writing software in bedrooms on a ZX-81 at the age of 13, we were using ZX BASIC `GOSUB` commands to create reusable functions. 

As we move through the history of third-gen programming languages, the introduction of OO concepts. Service-Oriented Architectures, functional programming and more, the goal of separating software into its logical components for one reason or another has been reinvented more than any other concept in modern computing.

So, here we find ourselves looking at the newest reinvention an old-idea, microservices; the latest attempt to bring abstraction and reuse to enterprise software.

So-long Monolith 

Traditionally, software was built and deployed in its entirety to a single server and scaled horizontally, whether that server was a simple web-server or a full-featured application server, even when software had been “modularised” or service-based, those modules or services interacted with each other on a more-or-less one-to-one basis and were deployed as a single deployment.

Of course there has always been some separation, queueing servers or messaging servers were often separated, but this was really as far as it went.

In the microservice world these single deployment large applications are known, somewhat pejoratively as “Monoliths”, single indivisible tablets of stone that, presumably to extend the analogy - needed armies of workers to move them

Hello Micro

The concept of microservices is to sub-divide the separate modules or services into their own stand-alone autonomous nodes within the application. This has benefits from both an architectural and performance point of view but also introduces risks and complexity to the project.

The benefits of a microservice based architecture are largely the same has been touted before in that it supports abstraction and encapsulation of design and implementation of software services. The ethos of “do one job and do it well” is embraced and each microservice is self-contained, responsible for its own area of the application and its own domain of data. Services generally should not share databases and should rarely be inter-dependent. Each microservice communicates with other microservices using network based technologies such as HTTP, and where necessary will hand-off work for which it is not responsible to the other microservices in the network.

Small but Mighty

This approach has several strengths that go beyond the logical modularisation that was striven for in the past, whilst it is true that the physical separation of these services enforces a more rigid approach to design, architecture and development, there are more tangible benefits that come from the physical separation employed.

As microservices are deployed separately, each can be scaled independently, indeed this can often be done dynamically in response to fluctuating changes in load. For example when a major marketing campaign is due the messaging services can be briefly scaled up to provide greater capacity and throughput. This is of course especially useful in cloud-based hosting where there is an abundance of computing resources but can be very expensive to be paying for unused capacity.

Microservices do not need to share an architecture, in fact legacy services can be wrapped up and containerised to work within a mixed-architecture, communicating with more modern systems seamlessly.

The separation of responsibilities across the service architecture means that communications between the services can be asynchronous where possible and this can have a positive impact on overall service latency.

Communication can be facilitated by a queue system and “handed-off” to be processed at a later date, for example data loading for reporting can be processed in near-real-time without this putting any strain on the core systems.

Because each service is properly self contained, it is much easier for development teams to work in parallel on software that has had its dependencies removed, unit testing and functional testing is also much easier to achieve.

To a man with a hammer…

As Mark Twain (allegedly) said “to a man with a hammer - everything looks like a nail” - microservices need to be applied as part of an overall design and planned architecture, they are not the architecture, they are one tool available to developers and DevOps staff when designing and building a system.

Microservices are in no way a panacea, nor are they without their own pitfalls and bear-traps. 

One of the biggest mistakes that teams fall into with microservices is a system that is far too “chatty”. This can easily happen when the ethos leads the design and services are created in a too granular or distributed manner meaning that a simple business operation is distributed across many nodes that all depend on one another, this causes a huge amount of network traffic between the nodes and causes major latency issues. 

Perhaps the most well-known example of this is Dell Computers migration project - this was more a failure of design and management than of technology, but it is a sobering example of how project myopia can crate major problems.

You've spent months re-architecting your monolith into the new microservices vision. Everyone gathers around to flip the switch. You navigate to the first pa...

Building towards a Microservice future

Of course, as with any architecture, it is much easier to adopt on a “green-field” project than it is on a live system. However as described above, there is no reason that this transition cannot still be achieved. 

New services can be built in the micro service architecture and can talk to the existing monolith system. In fact this is sometimes a better way to introduce the team to a new technology such as this, where they can use the new project as a “sandbox” to understand the new architectures, failing fast and early and truly understanding the concepts, the rules and when those rules should be broken.

A successful migration will probably take a year or more, but as with Agile, deliveries should be rapid and iterative and as with any aspect of architectural change, strong management and good communication are the keys to success.

Also published on LinkedIn.

Is SwiftUI ready for the big time?

You are a Technology Manager at a medium or large company - when is the right time to embrace SwiftUI?



In June 2019, at Apple’s Worldwide Developer Conference (WWDC), Craig Federighi, Apple's senior vice president of Software Engineering introduced a new declarative method for building User Interfaces across all Apple’s platforms (iOS, macOS, tvOS and watchOS). This built on the announcement of a new programming language, Swift in 2014 at the same event.

SwiftUI is an incredibly ambitious project, almost as ambitious as the Swift language itself, it allows developers to create data structures that translate to user interface views with all the controls and features that an app may need. It can make prototyping incredibly fast and responsive particularly as you can see a live preview of the UI right next to your code in Xcode or on a real device connected to your machine. This will update in real time as the data structure is changed in the Xcode editor window. So, your developers have been champing at the bit to use this new coolness ever since they took a case of beer to a spare meeting room to watch the WWDC Keynote, hanging on Mr Federighi’s every word (to be fair - that is what I did!). Should you embrace this technology now? Will it save you significant time and effort in development? Perhaps unsurprisingly, the answer may be different depending on who your customers are and specifically what your product is.

Know Your User

Well, this is a overused and well-worn phrase and this is largely because it holds a lot of value in all aspects of product design, however in this situation you really need to know what proportion of your user base is running the latest version of iOS - iOS 13.

Apple’s stats show that (at the time of writing) almost 80% of devices introduced in the last four years are running iOS 13, this drops to around 70% for all devices. This is around about the historical norm for iOS releases, 6 months from release.

You can use the data that Apple provides on App Store Connect to check the stats for your own app, this may differ from the high level figures if your app user base has a niche or skewed demographic.

Why is this important?

Apps that use SwiftUI, even with only a single view will only install on devices that are running iOS 13 or above. This means that any users that are not currently running the latest OS will either be unable to install your app or will have to make do with the last version released that does not include SwiftUI views (assuming you have one). 

If your user-base are tech-savvy iPhone users, there is a good chance they are on iOS 13 (the OS will prompt you to upgrade ceaselessly so many people will have taken the plunge to upgrade just to stop the nagging), however if a significant number of your users are on older devices (particularly iPads that tend to be held on to for much longer) or are more elderly, it is quite possible that you will lose a significant chunk of your users if you move to SwiftUI too soon.

It probably "ain't broke"

If you are starting a brand new app from scratch then SwiftUI may well be a good choice (although read on for caveats). However if you already have an app that was built using previous UI development processes then you will already have UI views built using Storyboards and Xibs. You probably have implemented Design Patterns across your app. It makes little to no sense to covert these existing views from Storyboards to SwiftUI - you will have invested many hours of development and more importantly testing in these views and they are presumably battle-tested in the real world. You will have fixes and workarounds that are important, but no-one will remember why, you need a really good reason to relearn all the mistakes you made first time around - worst of all, none of your users will know or care, Joel Spolsky’s 20-year-old article still explains this better than anyone.

This does not mean that new views should not be written using SwiftUI - Storyboards and SwiftUI views can coexist very happily. You just need to not to throw out the baby with the bathwater.

There is, perhaps one exception to this "don’t refactor" rule - if you have views that are extremely dynamic and need to change frequently based on changes in the underlying data then SwiftUI is incredibly powerful when used with Combine - another new Apple framework that automatically pushes changes to your views when the underlying data changes, whilst Combine can be used with ViewControllers and Storyboards, it works best with SwiftUI - again tread carefully so as to not unravel significant amounts of working code for very little end-user benefit.

The State of SwiftUI

Finally, we come to the SwiftUI framework itself. 

SwiftUI is a huge investment from Apple, following hot on the heals of its equally huge investments in Swift and APFS. SwiftUI is clearly the way that Apple wants developers to work in the future, although Storyboards will be supported for a long time to come. It seems likely that as new features are introduced, they may at some point only be available for SwiftUI, this is in fact already the case for watchOS. Apple is already developing new frameworks only for Swift and not porting them back to Objective-C it seems likely that the same will be true for SwiftUI in a few years.

All that said, SwiftUI is showing its immaturity in some places - Xcode support is not as good as many developers would like and error reporting can often be cryptic, opaque and can reflect the building blocks underneath the framework, rather than the framework itself. Additionally, it is easy to forget that building UIs using a declarative structure rather than a drag-and-drop user interface requires a paradigm shift in the mind of a developer and so you will have to make a significant investment in allowing your developers to retrain themselves in both approach and syntax. Much like your codebase, they will have knowledge that has been built up over a decade or more that has given them a deep understanding of how to build apps and UIs. Throwing all this away (like throwing away your existing app code) requires a significant reset and whilst it may well bring benefits down the line, there will certainly be a cost right now.

Conclusion

So, to answer the question I posed at the beginning of this article - Is SwiftUI ready for the big time? As often is the case with complex tech questions the answer is probably “it depends” - however I think the general answer for most medium to large companies the answer is probably “not yet”. The immaturity of the tooling, the dependency on a 6-month old OS (that has had more than its share of bugs and instability) means that unless you are building a brand new app for release in Q3 2020 or beyond, I would caution against taking the plunge just yet.

WWDC 2020 is unlikely to go ahead in the normal manner - COVID-19 will almost certainly mean that it will have to become a “virtual” conference, I suspect the only reason Apple has not yet announced this, as I write, is that they are still planning whatever they are going to do in its place. However I think we can expect that Xcode 12 and iOS 14 will still be announced in June 2020. We must hope that they bring greater stability and tooling to the frameworks introduced in 2019. Come September 2020 when these new version exit beta, it is probable that this will be the point at which the time will be right to embrace SwiftUI.

TL;DR: Be patient for now.

iOS App Review

There has been a lot said and written recently regarding the App Store review process, times taken and the lack of transparency in the process. Panic's Transmit and PCalc seem to have become (perhaps unwittingly) the poster-children for App Store policies that have been viewed by some as confusing and inconsistent.

Having  had cause to deal with an App Store rejection, I felt it might be valuable to reveal some of the workings of the App Store system as I witnessed them recently.

We work in a highly regulated market and this requires us to submit documentation to Apple to prove that we are eligible to operate within the regulations. This took a long time initially but once all the documentation had been supplied and approved our App was published and has been live for a number of years now.

Late last year there was a change in the regulations which meant that we needed to get further documentation approved. This was all done on time and correctly, however I failed to provide it to the App Store review team and in mid December Apple advised us that we needed to provide the new documentation within three weeks.

Unfortunately, due to Christmas holidays, I didn't see this until late and by then iTunes Connect was in its Holiday Shutdown. On 30 Dec when iTunes Connect came back on-line many of us were still on holiday and this caused further delays. Last Friday Apple pulled our Apps from the App Store. I would like to reiterate at this point that this was entirely my fault and if I had followed the rules and the instructions from the review team correctly, this would never have happened,

But there it was - all our Apps had been "removed from sale" and we were running around working out what to do. So - a little late in the piece - I provided the correct documentation by filing an appeal. This was completed by midday on a Friday and I was pretty much resigned to our Apps being unavailable over the weekend and possibly longer. I did have an email address of an old contact I had at the App Store Review team which I had not contacted for 2 years, so I sent them an email too on the basis that it was unlikely to do any harm.

By 8pm that evening all three Apps were back in the App Store - I received an email from my contact (whom, I have never met and only email when I have a problem) making sure that everything was OK and providing me with another contact email address of someone that was now in a better position to help in future. Finally I received and email from this new contact checking to see that everything was all OK and confirming that if I had any problems in future that they would be happy to help.

This is, I believe above a beyond the sort of service we hope to get from the App Store review team. I was made to feel as though they cared about our problem as much as I did and that they worked hard to turn things around quickly. 

Maybe I am lucky that I had a contact in the App Store - maybe the process when an App has been removed from sale is different than the standard review process, maybe our industry has a dedicated team and other Apps don't get this kind of attention. We probably will never know - however what I can say that this was as well a run process as I have had from any service team and was at odds with much that I had read recently and so probably worth sharing.

Classic Album sing-a-long

This is incredibly well done - also, some great albums in there - I'm off to Spotify to grab a few of them right now.

I've fallen, and I can't get up!

This is incredibly well done and more than a little weird!

The Autocomplete Song

I often wondered how far you could get in a conversation using only auto-complete suggestions. Seems there is a much more artistic answer to that question than I had imagined.