The Power of Quality: Why Your Software Needs More Than Just Correctness

When developing software, many people focus on one aspect above all others: functional correctness. While this is an important aspect of software development, it’s not the only one. Two other vital elements should be considered: software quality and software testing.

So what is the difference between software quality and testing, and why are they so important? Let’s take a closer look.

Software Quality

Software quality refers to the overall quality of a piece of software, considering factors such as reliability, maintainability, and usability. In other words, it’s about more than just whether the software works correctly or not. It’s about how easy it is to use, how easy it is to maintain and update, and how reliable it is over time.

High software quality requires careful planning and attention to detail throughout software development. It includes everything from writing clean, well-organized code to designing intuitive user interfaces to rigorously testing the software to ensure it meets all its requirements.

Software Testing

On the other hand, software testing is focused explicitly on verifying that the software works correctly and meets all its requirements. The process involves designing and executing test cases that exercise the software in various ways to ensure it behaves as expected.

While software testing is integral to software development, it’s important to remember that it’s just one part of the process. There needs to be more than testing to ensure high-quality software. You must take a holistic approach that includes careful planning, design, coding, and testing to achieve that.

Why It Matters

So why is focusing on software quality rather than just functional correctness so important? The answer is simple: because software is rarely used in isolation. In most cases, it’s part of a more extensive system that includes other software components, hardware components, and human users. As a result, if the software is difficult to use, unreliable, or hard to maintain, it can negatively impact the entire system.

For example, imagine you’re using a piece of software that is difficult to use and prone to crashing. Even if the software technically meets all its functional requirements, it will still be frustrating and time-consuming to use. In addition, it can have a ripple effect throughout the entire system, slowing down other processes and potentially causing errors or delays.

By focusing on software quality and not just functional correctness, you can ensure that your software is reliable, easy to use, leading to a better overall user experience and more successful outcomes.

Summing up

While functional correctness is an essential aspect of software development, it’s not the only one. To truly ensure that your software meets the needs of your users, you need to focus on software quality and testing. By taking a holistic approach to software development, you can help ensure that your software is reliable, easy to use, and easy to maintain, leading to better outcomes for everyone involved.

How safety at work improves creativity and productivity

I finished 2019 with a short holiday. I used the time to reflect on the journey past year. In December, I was at the “AWS re:Invent” conference. Amongst many sessions, I particularly enjoyed those that focused on Software Engineering processes and practices. During one of the presentations, the speaker said a sentence which very much engraved itself into my mind:

“The most productive and creative work happens in environments where it’s safe to experiment. To get most out of your Engineers, create safety instead of restricting freedom by introducing draconian rules and policies.”

Working for many years in tightly controlled environments, I realised the importance of the above statements. I also realised the many dimensions of safety to which the speaker was referring.

Impact of tight rules and policies

Many organisations, specifically large organisations, introduce regulations and procedures to prevent undesired situations from happening. In my experience as a software engineer, I had to deal with tight controls of Internet access, permissions of my development environment, access to test environments, curated list of software and dependencies.

Those rules were not only frustrating and inconvenient for other developers and me, but were also preventing us from trying new things, improving existing solutions and slowing down the delivery process.

The frustration resulting from the blockers, caused me and my colleagues to find creative ways to work around the restrictions, by “hacking” processes. We wasted our creative efforts on the wrong outcomes.

The sad truth is that regardless of the rules and policies undesired situations happened. Back in the days, you could hear about security mishaps and performance issues on the BBC.

When I think about the quote from the beginning of the post, I know that fruits of my work might have been more creative and take much less time if I would have the freedom to experiment and progress safely.

Safety comes in different shapes and sizes.

As a software engineer, when I talk about safety, I immediately think about safe development environments where I will cause no harm to the production systems. However, there is another dimension to it: a safe environment in a company, where:

it’s fine to voice opinions and raise concerns
there is no prejudice, bias or harassment
no blame is assigned.

No amount of technical solutions will make a difference in your organisation unless you make people feel safe to express their thoughts honestly and openly.

How to create safety

road_block_driving_safety

As leaders and managers, we create a safe environment by being transparent and open. When our people realise they don’t have to worry about speaking their mind and challenging current approaches, they would have time to focus on existing work and bring ideas for improvements.

Safety is a feeling, and different people might feel it differently. It might take time, and a different approach before people in your team feel safe. Start by asking yourself, what would/is making you feel safe at work? Adopt it as your behaviour towards others and iterate on the approach. I find it useful to get feedback on my methods during 1-2-1s.

When it comes to technical solutions, the following are some ideas on safety for experimentation:

Managed developer desktops, with no access to the corporate network, with permissions to add additional software at will
Sandboxed dev environments with no connection to delivery pipelines
Separate Internet access without restrictions on the development resources
Production-like data for experiments

Following ideas are for safety in the delivery work, as a part of development practices :

Automated functional and non-functional testing
An automatic, no-human-touch deployment pipeline
Reproducible environments
Configuration as code

I know that the last few points are essential DevOps practices. It’s not coincidental as they are designed for safety due to the fast-paced nature and the elimination of human error.

Remember, keep your workplace “safe”!

Naming things is hard … and very important

Have you ever watched “The Croods“? When my daughter was younger, I watched it many times. The Croods are family of a caveman trying to survive another day in the dangerous, prehistoric world. There is no doubt in the entertaining value of the movie, but the thing that I remembered the most are the scenes where cavemen are attempting to name new “things”. I always wondered how did they come up with names for things, how come “wheel” is a wheel? It is difficult even to imagine the thought process. Why not try yourself? Think of a different name for a “wall”.

800px-English-English_and_English-Persian_dictionaries

Naming things is hard. It’s even harder when you have to do it regularly during the day. If you are somehow puzzled to what profession requires to continually come up with proper names for things throughout the day, let me put you out of your misery; it is Software Developer or Software Engineer.

When creating software, developers have to name: variables, functions, objects, modules, systems, classes, etc. All of them would have behaviour, which requires a proper name as well. Proper naming is crucial because:

it communicates meaning
it helps collaborate
reduces time and cost of maintenance

Working with a team means that developers have to collaborate and incorporate each-others code in their work. They need to understand the meaning of the code, intention and behaviour to incorporate it within their work correctly.

Naming things in Software

Today, computer programs can contain thousands if not millions of lines of code. Without code being transparent, it is hard to modify it, change it, improve it. The naming of different elements of code is a massive part of making code clean.

Each programming language has its own set of conventions and practices when it comes to naming. Following those standards provides a mental shortcut and reduces cognitive load during the development process.

Naming standards are also crucial for aspects of the development process itself. Thanks to the common understanding of words and phrases like “build” and “release”, or “story” and “feature”, we know how to work with each other.

Naming things in the Development Flow

When working with code, we collaborate using Version Control Systems. The one that is the most popular at the moment is Git. Few services are offering Git repository hosting, with GitHub being defacto golden standard in the industry.

branches

Git is quite flexible with the ways of using it; however, teams typically adopt one of the standard models. GitHub or Atlassian has a great set of posts explaining the different models. The model that seems the most suitable for the Enterprises that worked 90% of the time for the teams in companies I worked for seems to be GitFlow. The flow prescribes names for branches. Those names are relevant as of the points mentioned above in my post. Branch names help with the understanding of:

where to put code that is Work in Progress
where to integrated completed code
where to stage code ready for creating a release candidate
where to put code that is officially released and in production
where to put code that fixes issues and bugs

I do like to make it easy for people to do the right thing and hard or impossible to do the wrong thing. Hence I created a little GitHub Application, that looks after names of branches in the repository and raises an issue if the name is wrong or deletes the offending branch.

You can check it out at https://greggigon.com/brunchyyy and https://github.com/greggigon/brunchyyy.

Final words

Correct naming is essential in software development. Naming standards provide mental shortcuts, reducing cognitive load. They also provide a shared vocabulary for communicating and building blocks of understanding. Pay attention to naming and help your teams adopting standards.

I’m going to leave you with this funny short Clip from “The Croods” illustrating how hard it could be to name things correctly 🙂

Fixing DevOps

I recently posted a one-liner on LinkedIn, that attracted a great deal of interest and thought-provoking discussion.

If I was paid a £1 for every consultancy, company or private contractors who claim to come in and “fix DevOps” for us and then fail, I would be a very rich man 🙂

In light of the comments and queries, I decided to expand on what I mean by Fixing DevOps and failing at it. First, let me start by explaining what was the trigger to write the line.

Devops toolchain

One Cheeky Email

As a Head of Software Engineering I have been targeted by Sales representatives attempting to sell software products and software development services for quite some time now; a few days ago I received yet another email promising to Fix all the DevOps headaches we might have and change our company to become a DevOps Nirvana if only we would to bring them in.

I have been working in the financial sector for 9 years and witnessed a number of times promises that hardly ever been delivered on. I know that my industry colleagues have had similar experiences.

Thus, the above one-liner shared on LinkedIn, was born.

Some problems of large organizations

Historically, the organization I work for had nothing to do with technology. Banks offered financial services for centuries without the use of Software. Computer systems and software were adopted in the 60ties. The technology was used as an aid to business, means of making money easier and faster. Today banks would not exist without IT systems. There is more virtual money in the economy than tangible assets.

In many large organizations, technology is still looked at as an afterthought, the necessary evil that has to be dealt with in the most cost-effective way possible. Latest advances and innovation are hard to introduce. New technologies and processes are adopted at a much slower pace than technology focused organizations like Google or Amazon.

Large and complex organizations can’t exist without modern technology as well as technology makes no sense without their core business. The truth is, both sides have to work together but in reality, the way organizations are constructed prevents it from happening.

Technology is siloed into one organizational unit and business into another, each with its respective leader. Technology becomes a service organization for business. Local goals emerge, driven by local targets resulting in both organization pulling into different directions and the customer finding little to no improvement.

Let’s reiterate some of the DevOps principles at this point:

Focus on delivering value to a user
Thinking big picture – End-to-End product delivery, from inception to delivery and beyond
Never-ending feedback loop on the product, it’s quality and behavior in production
Cross-functional and autonomous teams
Ruthless automation of everything

#BuzzWords to the rescue

I observed the following pattern in the history of DevOps adoption with the involvement of technology leaders at different organizational levels.

A Leader hears a ‘buzzword’: DevOps. Next steps are:

some research into benefits,
multiple visits by DevOps consultancies, referring to case studies within a similar large organization,
a consultancy (or few) comes in to perform DevOps assessment,
a report is produced with information about organizational challenges,
recommendations on how to change and what tools to adopt

Tools become the focus area of proposed improvements as organizational changes are too problematic for A Leader. Consultancy begins the new engagement, ramping up resources and bringing in new tools. The process of “fixing the DevOps” in the organization starts.

A Leader chooses a small area of Organization to roll out new approached and tools. Neither the consultancy nor small area of Organization has enough remit nor possibility to influence any organizational changes, resulting in: consultancies automating a few basic processes, leaving behind a large backlog of future/unfinished work and a hefty bill.

Small, local improvements make little impact in the large organization. The experiment is deemed as a failure and adoption stops (until next Leader arrives or a good sales strategy from different consultancy).

Summary

Many DevOps consultancies are selling The Dream, utilizing template case studies based on the size of targeted organizations, rather than being tailored to individual requirements of said organizations. Challenges posed by organization structure in DevOps adoption are overlooked during sales negotiations. Resulting engagement creates an invalid perception of DevOps as not being fit for purpose, causing more damage than good.

The truth is that for any change to be successful, creating long-lasting effect the initiative has to come out from within, driven by ‘outside the box’ approach.

New features in My Personal Kanban, Kanban Themes and new Card details dialog

I did spent some time adding new feature requested by my Wife. Links, in card details field, are now supported as real HTTP links, which could be opened. I did remodel slightly the Kanban Card dialog to support that.

The other new feature is the possibility of changing look of Kanban. The feature comes with easy way of adding own styles.

You can get a copy of the software here: http://greggigon.github.io/my-personal-kanban/

The video bellow is a quick overview of the new features.

How to update My Personal Kanban with your own styles

You need to create a css file with styles and copy it into: my-personal-kanban-folder/styles/themes/ folder. Name doesn’t matter, however you will need to use this name in last step. The default-bright.css and default-dark.css can be used as a starting point for your own styles.
Prepare image capture for the new style and place it in my-personal-kanban-folder/img/themes/ folder. It should be a jpg no bigger than 150px in width with the same name as the css file (you can see that there are default-bright.jpg and default-dark.jpg in that folder already).
Last step is to open the themes.js file from my-personal-kanban-folder/scripts/ folder (it will have a funny name like 5ebce75f.themes.js ) and add entry for your new theme. Name is the property that will be displayed in the Drop down. css is the property that will be used to find the css and jpg file prepared in steps 1 and 2.

If you want me to make the style a permanent member of My Personal Kanban, just make a pull request on GitHub. https://github.com/greggigon/my-personal-kanban

Greg

My Personal Kanban, offline Kanban board for personal use

I’ve just released new version of My Personal Kanban. You can check it out at http://greggigon.github.io/my-personal-kanban/ .

My Personal Kanban is offline Kanban Board that runs within web browser.

Why Kanban for personal stuff?

Kanban is lightweight enough to bend to my personal lifestyle and to the way I do things outside work. I used a simple TODO list but I wasn’t happy with it.

Kanban gives me clear overview of things that need to be done, things I’m working on and stuff I finished. It also provides way of prioritizing the work (by color coding or bubbling the most important tasks to the top of the columns) and clear visual aid for reviewing tasks.

By limiting Work in Progress I can make sure I stay focused on task and finish it. By looking at the last column with things done I can give myself a tap on the back for achieving task completion.

Have a go and try it. Greg

My Personal Kanban, new tiny application just released

I’ve posted about Kanban before (Free Kanban Board , Kanban), however this time I’ve created a little Kanban Board application that I started to use as my personal, sophisticated TODO list.

My Personal Kanban Screen — Example of a Board

My Personal Kanban is Free and Open Source for anyone to use.

More description of it’s functionality can be found here: http://greggigon.github.io/my-personal-kanban/ and the source code in here: https://github.com/greggigon/my-personal-kanban

Free Kanban board on Mac with no additional software

I’m a big fan of Kanban board. I prefer it over TODO list for all my professional and personal work. It’s clear to understand, doesn’t require extensive management process and most important offers great visibility of work.

I’m not going to focus on Kanban itself. If you want to read more about it I would refer you to few external links for more info:

What I would like to focus on is how to do a cheap Electronic Board on Apple Mac without any additional software installed.

What you need?

If you got Mac you don’t really need anything more. I’m running OS X 10.8.3.

To make the Kanban board I used application shipped with OS X called Stickies and a custom made desktop backgrounds.

How to do it?

First of all, I’ve created a new Desktop using Mission Control and setup Desktop Background to my Custom “Kanban Board like” wallpaper.

Adding new desktop in the Mission Control

I’ve prepared two backgrounds, dark and bright, which you are more than welcome to use for free.

Kanban Board - Desktop background - Dark — Kanban Board – Desktop background – Dark

Kanban Board - Desktop background - Light — Kanban Board – Desktop background – Light

My empty board is ready. All I need to do now is to add some Stickies onto it.

Voila. You can modify color of a sticky and make it transparent. I’m using colors to distinguish between different types of tasks. Stickies on the top are the one with top priority.

Once your Done column is full you can archive your Stickie by saving it and removing from the board.

Simple as that I hope you’ll find it helpful and easy to use. Greg

Inbox Zero – 3 years of happy email

Today is roughly 3 years since I’ve decided to sort out my email. Both, my personal email and my work email. I’ve decided to go 100% Inbox Zero. No exceptions.

Inbox zero

Why?

I had a massive inbox full of stuff. I’m using Gmail for my personal mail and the Exchange and MS Outlook at work. Thanks to Google’s never ending storage I never removed a single mail from my inbox. It was the same at work. It started to bother me at some point for number of reasons.

I took me a moment to find things I was looking for
I was annoyed with the mess and the number of things in my inbox
I couldn’t organise myself based on my email inbox. Couldn’t decide what to do next.

About the same time I started to think of my problem I stumbled upon the concept of Inbox Zero.

How I’ve done it?

First thing was to actually reduce the amount of received emails.
Unsubscribing from useless marketing stuff and newsletters I never read and was never interested in.

I’ve created Labels in GMail and filters in Outlook to put less important informative things (like interesting newsletters, Bank statements, some billing info) into folders. This information is there, separately from the other stuff and I can easily get to it by navigating to a folder.

Last step was to archive everything else. This left my Inbox totally empty.

Ongoing maintenance?

Quite simple.
When I received something I was not interested I either tried to unsubscribe or mark it for my spam filter.

All the filters took care of putting interesting but unimportant mails into folders.

Every email I received become immediately my TODO email. I either answered it immediately or as soon as I could. As soon as I took an action I could archive the email and forget about it.

Summary

I find few advantages of having no emails in inbox.
The fact that my inbox is empty when I navigate to it leaves me with the peace of mind. I know that all the necessary actions I should be taking, I’ve done and I don’t need to worry about it.

Email is no longer only a way of communicating, it’s also a way for organising myself. I do actually send myself an email as a reminder of things I need to do. After three years of doing Inbox Zero, I know I will make sure that I will get to it as soon as I can so the inbox could stay empty again.

Lastly, the fact that there is nothing in the inbox and the fact that my Email TODO list is clear makes me feel good, gives me a motivational sense of accomplishment. That alone is an incentive for the Inbox Zero.