Craig Pardey

Software should do one thing, and do it well. Each piece of software should have a clearly-stated goal that is used to determine whether a particular feature should be implemented or not. When a proposed feature does not fit with the software’s stated goal then don’t implemented it. Just don’t.

Like adding source control to your product. We already have several perfectly good source control systems. Building your own custom source control system into your product is never a good idea. Your implementation is unlikely to be as good as the standalone products like Git, Mercurial or Subversion, and it’ll probably make it difficult for me to use my source control system of choice.

I’ve been working on re-platforming the online banking system for a Canadian retail bank for over two years. Leading up to the initial launch, The Business decided to defer a few features to the next release which was scheduled for about a month later. We created a release branch to support defect fixes found in testing, and the development team continued adding features to the develop branch. Bug fixes from release were merged into develop regularly. The process was working.

Remember the Great Equifax Hack back in Sept 2017? Equifax came under a lot of fire for the way they handled the breach and one of their mistakes was using the custom domain equifaxsecurity2017.com for “customers” to check whether their personal information had been compromised. Shortly after the breach, several other lookalike domains were registered including securityequifax2017.com. In fact, the custom domain was so confusing that Equifax themselves directed people to the incorrect site via tweets on Twitter.

A trucker delivering palletized cargo to a pier would have to remove each item from the pallet and place it on the dock. Longshoreman would then replace the items on the pallet for lowering into the hold, where other longshoreman would break down the pallet once more and stow each individual item - all at a cost so high that shippers knew not to send pallets to begin with. – The Box, Marc Levinson. P143

[Read More]

I’m currently reading The Box by Marc Levinson. It is a fascinating book that chronicles the changes in the shipping industry brought about through the introduction of shipping containers. It sounds dry, but it’s not. The innovators faced huge barriers, including governments, labour unions, and standards committees. I have such deep respect for Malcom McLean for persisting through the insurmountable bureaucracy.

At one point, they discuss how a particular design aspect of the container was deemed unsuitable and had to be rectified:

When I first heard about the so-called UK Challenger Banks like Monzo and Atom, I was amazed that there wasn’t a similar offering in Canada. The Canadian retail banking sector desperately needs new players bring compelling products to the market but nobody was doing it. There are some options like PC Financial and Tangerine but they’re both backed by one of the Big Banks (CIBC and Scotiabank, respectively). Nobody was attempting a ground-up rebuild of a bank using modern technology and practices.

Michael Feathers says that legacy code is any code without tests but I’d go a step further and say that legacy code is any code that is still running even though the original developer(s) are no longer working on it. And there is certainly plenty of that in financial institutions. There are other characteristics too, such as:

• unreproducible production environment
• incomplete source control
  • missing files
  • ‘master’ fails to build
• no automated build process
• no release process
• few or no unit tests
• no way to run or test the code on a developer workstation
• little or no documentation
• none of the original developers available

I am presently working on a codebase that checks all of the above boxes and it isn’t even that old but instead of dismissing it as an unmaintainable mess I have changed my mindset and have started referring to it as Heirloom Code.

The Pragmatic Programmer is one of the most influential books that I have read as a software developer. It is right up there with Software Craftsmanship and Clean Code. Andy Hunt recently gave an interview that was peppered with several poignent quotes that struck a chord with me.

You need to understand how to work with other people, both with teammates and with those pesky users

This is the single piece of advice that I’d give to anyone looking to get into software development. A team that works well together can accomplish anything even if it is only staffed with “intermediate” developers. In contrast, I’ve seen teams stacked with “rock stars” that have failed to produce anything meaningful due to poor team dynamics and toxic attitudes.

Your email address identifies you in this online world. Companies use it to verify who you are, to communicate with you and for resetting passwords. You may also use the same email address to correspond with your friends and family, and it may even be linked to your calendar too.

It makes sense to separate your personal email from your work email - you don’t send personal emails from your work address, nor do you send work emails from your personal address. In all likelihood you use a free service like Gmail, Hotmail, AOL or Yahoo for your personal email.

This is a continuation of my post about clean tea, except this time I analysed the offerings from Tealyra.

Tealyra by the numbers:

• 490 teas (excluding kits and samplers)
• 175 contain sugar and/or flavourings
• 187 caffeine-free

So I filtered the list to only show teas with:

• No caffeine
• No sugar
• No stevia
• No flavourings

86 teas on the Tealyra® menu pass my filter for what I would consider to be “clean” which makes Tealyra the best of the three that I’ve looked at so far. Overall the offerings from Tealyra are pretty decent once you filter out the ones with sweeteners and/or flavourings however I felt overwhelmed by the sheer number of options.