Category: Uncategorized

Virgin Airlines as a case study into development failure

~ chriseyre2000 ~ Leave a comment

While on holiday I found myself interacting with some of Virgin’s software and infrastructure.

To start with I tried registering for their app while waiting in the departure lounge.

It’s not normal to have a password with a 12 character max length that will one accept letters or numbers. That is a security fail.

On the night before our departure my wife received a text message telling us to check in.

Checking the website from a mobile phone told us to try again 2 hours later. This is inconsistent messaging.

Two hours later the website would let us start but insisted on us using an app. We downloaded the app, but found that it wanted us to enter our passport and address details – something we had clearly done before as we had already flown to the Caribbean. The app had an interesting user interface. It would tell you that something was wrong but give no clue as to how to fix it. This is a UX fail.

We attempted to use the hotel supplied tablet but was frustrated by it’s 1 min auto refresh – the website was unable to complete a simple transaction between the console refreshing.

Finally we managed to use my wife’s tablet to check in. This time it was fine.

Virgin really need to look at their systems. Forcing mobile users to use a broken app is not helpful. Prompting users to check in when the system is not ready is also not a good idea. Asking for information that has already been given with a UI that can alter the info without sane error handling is a bad idea.

Categories of Bugs

~ chriseyre2000 ~ Leave a comment

This assumes a mature XP process is underway (this is almost 20 years old, so should not be a surprise to anyone).

If you are actively developing software there are only a limited category of bugs:

  • The critical – stop development and fix
  • The important – to be picked up as the next highest priority item
  • Prioritised alongside other upcoming work items.
  • Do not fix – record as unimportant

These days there should be no reason to keep an extensive bug backlog.

A bug is effectively a missing test (unit, integration or end-to-end).

With a sufficient test suit the QA should be getting bored. Hopefully they are spending the time working on acceptance criteria and acceptance tests for upcoming work.

80/20 Principle and Optimizing

~ chriseyre2000 ~ Leave a comment

The following is the means of finding the directory size of a folder and its contents on a mac:

du -s

This came in handy when I was trying to speed up a website deploy.

It turns out that over 98% of the content of the site was in one folder. Spliting this off an changing the copy policy saves between 50% and 75% of the deploy time.

Look for the quick wins!

New Machine Setup

~ chriseyre2000 ~ Leave a comment

I have recently moved jobs. This comes with the inevitable machine setup issue.

This is a list of things that I have been installing on my machine so that I won’t have to build myself another list:

  • Chrome
  • homebrew
  • neo4j
  • java8
  • elixir
  • exercism
  • vscode
    • Enable autosave (on the file menu)
    • GitLens
    • IntelliJ IDEA Keybindings
    • JS Refactor
  • Gradle
  • git ssh setup

After every mac os upgrade:

xcode-select –install

Development Practices That I Want To Use In Future Roles

~ chriseyre2000 ~ Leave a comment

I have just left one company for a new role. These are a few notes that I would like to bring forward to future companies:

  • Empower the devs add cloud resources within a limit say $100 per month without having to ask. The meetings to request this will cost more than the benefits. Dev teams will spend less time waiting.
  • Have a bell that can be used to trigger team timeouts. Hold the discussions as soon as they are needed. Decisions should be made by the team. Go one better than us and actually write up the decision including why’s and assumptions.
  • When adding a new piece of technology always consider how to replace it. Cloud services do stop with anything between 1 and 6 months notice.
  • Actively monitor the cloud infrastructure bills, both current and projected. Warn the team daily if a threshold is breached.
  • Never let the build stay broken. You can only ignore tests for a fixed period of days. This is only to be used for infrastructure failures.
  • Deploy frequently. Weekly at a minimum. Code not deployed will rot. Use feature switches if possible (but ruthlessly remove them after a feature is live). This does allow deploy from master.