Dev lab news: Does your indie software have enough quality?

Transcript of episode 11

These days, I have really been thinking about quality. I got questions from my early users about the quality of things in GetTheAudience, and I thought: Why not do a quick self-assessment of whether my software has enough quality or not?

I provide a SaaS solution for audience development, that is: a user can find their audience, they can understand them, they can select members of the audience that they want to work with, and they can also engage with an audience.

What exactly is software quality?

In the world, there’s a standard for everything. So there is also a standard for quality: It’s called ISO standard 25010, and it has several categories.

Quality can be divided into, for example … functions:

• Are they complete?
• Are they correct?
• Are they appropriate for the user?

The next category would be performance:

• Does it use time efficiently?
• Memory, battery, and other resources?

What about compatibility?

• Can the software co-exist?
• Is it interoperable with some other software on the same machine?

Is it usable? Usability, we can divide that into

• recognizability
• learnability
• operability
• protection against user errors
• aesthetics, so is it kind of … beautiful, easy to use, aesthetic?
• Is it accessible? What about blind people? Can they also use the software?

Reliability is an also an important category:

• Is it mature enough?
• Is it always available?
• Is it fault tolerant?
• Is it recoverable from errors, or from a total crash, or from a cloud server restart?

Security:

• Is the data that is inside, is it confidential?
• Is there enough integrity for the data?
• Is it proof against manipulation?
• How about authenticity and accountability? Is it clear which user has done what?

Maintainability is a big issue:

• Is the software written modular enough?
• Is it reusable?
• Can it be analyzed in case of errors?
• Is it modifiable without causing side effects?
• Is it testable enough? Can I test it successfully?

Portability is the last category. This concerns…

• Adaptability: Can it be adapted to new situations?
• Installability: Can it easily be installed on the client side?
• And: Is it replaceable? Can it replace other software in the same category?

So … lots of interesting questions in the ISO standard. And I said: Why not do a quick check for GetTheAudience itself, for my own software?

Self-assessment of the quality of my SaaS

One question could be: Is it functionally complete? Well, I have to ask my users for this. Some users say “Oh, that’s already enough for me. It’s way too much, way too many features in there. I’m not ready for this, I have to prepare myself to use it.”

Others say: “Oh, wow, yeah, I can use it successfully. I’d like to have this … and that … and that feature!”

So users are of different opinion when it comes to functional completeness. What’s my own opinion on that?

I wanted to use GetTheAudience for this FUSE process. It means Find, Understand, Select and Engage. So I had the feeling that the U, the S and the E were pretty much covered.

So you could understand your audience, you could select members of them, and you could engage with them by clicking on it and going into Twitter.

What I was missing was the F, something for finding the audience. I wrote this browser extension that you maybe heard about last week. You can install it in Firefox.

This week’s version is also in the Chrome store. I submitted it for review, at least. The Chrome store will take some time. It can take weeks until they finished the review so that it appears outside.

(Edit: Only 5 days after that, the Chrome extension passed the review. It is now available for installation, directly from the Chrome store).

Anyway, this browser extension allows you … when you just switch it on, it traces your Twitter behavior and records which tweets and which accounts you visit on Twitter. It writes this into a Twitter history inside GetTheAudience. Basically, you’re finding your audience for yourself and GetTheAudience records that.

And in that history, you can click on one entry and say: Create an audience from this! And then, you can go into the usual, “U, S, and E”: the understand, the select, and engage steps. So that was one function that I was really missing: The F in “FUSE”.

What users have been missing these days are the delete functions. You can create an audience, but you can’t delete it. You can add someone to an audience, but you can’t remove them. So, the delete functions would be incomplete. This is something I have to work on!

Performance

Is GetTheAudience using time, memory, battery, etc. efficiently?

Battery is still a big problem with smartphone applications. For example, some years back when I was still using the Facebook app, it was draining the battery on my iPhone, so I wasn’t too happy about this.

Fortunately GetTheAudience is a web app that’s not designed for smartphones, so I don’t have to care as much about battery usage.

But there are interesting performance problems:

For example, the early versions of GetTheAudience (the problem is solved in the meantime) had a big problem with image loading. When you opened a big audience with lots of members, there are all of these tiny little profile pictures of the users inside the audience. And let’s say you open an audience with a thousand members, and GetTheAudience tries dutifully to display all of them. This causes the client computer, the user’s computer, to load a thousand of these little images!

Well, this was not so much a problem on my machine because I have very fast Internet connection, but this is not typical! Users in Asia told me that when they open GetTheAudience and open a slightly bigger audience, they completely block, the browser of the user is completely blocked.

So, what did I do? I inserted a function that loads the first, let’s say 10 to 20 images immediately. And then, it only loads 20 images per second, or 10 images per second, depending on the speed.

And the user won’t recognize that because it happens outside the visible screen area in the images further down in the audience.

So this solved the problem quite nicely, also for Asian people with different internet speeds. This was nice. That’s worked quite well.

Memory is quite efficient. That’s not a problem. And other resources? Yeah, screen size! But let’s get to that when it comes to usability.

Compatibility

Well, this is not so nice! I had some interesting problems concerning the Safari browser because I develop GetTheAudience in Firefox and I test it in Chrome, but I test it not so much in Safari, although I’m working on an iMac and Safari is the native browser of the iMac!

The effect was that I was using some interesting styling for the hours of day:: The diagram that displays how many how active an audience is at a certain hour of the day. This diagram showed really nicely on Firefox and Chrome, but it was totally distorted in Safari.

So it turned out that a Firefox and Chrome were making some assumptions that I was making, too. But Safari didn’t make those assumptions about the height of elements, so I had to explicitly give each element the proper height, and Bingo: It worked also in Safari!

Compatibility is still a big issue for the browser extension that I mentioned before. If you install the GetTheAudience companion (as it’s called) in Firefox, it works fine. In Chrome, it works fine, but in Safari, it cannot work because Safari has a totally different interface for browser extensions. Amazing!

In Edge, it’s not such a big problem since Edge is Chromium-based, i.e. the same engine as in Chrome.

And Opera should also not be a problem, although I didn’t test it. (If you don’t test something, it might not work.)

So compatibility, yeah: The biggest issue is with this browser extension, but I’m working on that.

Usability

That’s an interesting chapter! I suffer from the “curse of a big screen”. I have a big iMac in front of me, with a 27-inch monitor and lots of pixels on it.

This leads to the effect that in my mind, I make certain assumptions about how a user interface can look like.

These assumptions might not be true when people use a standard MacBook, MacBook Pro, or something, or a totally different computer, maybe even smaller laptops, like 11-inch machines.

For example, I have got this audience explorer user interface. That has a very, or a quite big header section. The headline and the search bar and the first one or two elements are quite big for a smaller screen.

On my big screen, it’s not really a problem, but on smaller screens, it becomes a blocking, non-scrollable region on the screen so that the list of tweets becomes very short. You only see three or four tweets in the scroll area!

So that’s the curse of a big screen, when the developer has a big screen.

What I need to do is make things more scrollable, make it more adaptable, test it on smaller screens. For example, I have a MacBook Air with a 13-inch screen next to me. So, I will take that machine and test how it behaves on a smaller screen.

My goal is not to run on even smaller screens, like smartphones, but I would like to be able to run on an iPad or iPad Pro – this should work, so that’s my goal!

Apart from that …usability… (ponders) Yeah, it’s recognizable, it’s learnable, it’s operable, protected against user errors.

Aesthetics, yeah, we can discuss this: One user, for example, he said the contrast on the screen is much too high. He had difficulties to concentrate, to focus on what’s visible on the screen. So maybe screen contrast might be a problem. I need to check that.

Accessibility would be interesting. I’m thriving to make it accessible for blind people, too, so I always use screen reader text, if possible, but I didn’t test it at all with screen readers.

I don’t have a screen reader and I didn’t test it, so there might be big gaps in this field, in the field of accessibility.

Reliability

I think it’s solved. It is mature enough, available enough, fault-tolerant, recoverable. Yeah, I’m pretty happy about all this.

Security

I think it’s also solved. It’s confidential, the data is confidential: One user cannot see the data of another user. Integrity of data: yes! Non-repudiation? No, it’s not a factor for me.

Non-repudiation is a big subject for betting sites, or for banking where a user is not allowed to repudiate something that he did. But this is not a problem here in this app. It’s not so critical.

Authenticity: Yes, it’s important, it’s solved and accountability? Well, I think I don’t need to trace something back to the person who did it. This would be important in a support case. For example, when someone complains about an error in the app, I really need to go through the logs and see what they did in the application, so that I can trace back to the part where the error really happened. So accountability, for me it’s a subcategory of supportability.

Okay, so security is fine.

Maintainability

Can I maintain GetTheAudience over time? Does it still run within a few months from now?

Will it be extensible, can I introduce new features without breaking anything?

I think: Yes, this problem is solved pretty well because I made the software quite modular. It is decomposed into small modules. Each module has only one exact task, one exact responsibility. So if something goes wrong, I know exactly the part in the system where I have to make changes.

I don’t care about reusable modules, no, this is not a subject for me.

Analyzability? Yes, it is analyzable. I can find bugs very easily.

It is modifiable: I make changes in a defined place, and it doesn’t break other components. Sometimes I have to work on this. For example, when I introduce a new feature and I realize that the new feature would break the existing design, then I have to do small redesigns inside the code, so that the new feature gets some “space” where it can be inserted.

We software engineers talk about “refactoring”, we call this refactoring: to make space for new modifications.

And yeah, the software’s also testable enough. That’s right.

Portability

This is interesting. There are some challenges, too, because…

• Today, GetTheAudience is offered in the English language, only. Porting it into a non-English speaking country would be an interesting challenge.
• In the “hours of day” tab where I display how active the users in the audience are at a certain time of day, I’m using the AM/PM time format, only. It’s from zero to 12:00 AM and zero to 12:00 PM. Previously, I was using the 24-hour military format but this wasn’t too popular in the U.S., so I replaced it by AM/PM. This would also be a portability issue, a smaller one, but still, when I port to Europe, for example, European users are not used to AM/PM, but they are used to the 24-hour clock.

The software is independent of the cloud provider. It’s a simple web application – mostly, yeah, no, it’s not simple, but it’s a web application!

And it’s running on the Heroku cloud. I didn’t use any special Heroku functions so that I could take it away from Heroku and deploy it on Digital Ocean, for example, or I could deploy it on AWS, or on Azure. It’s not a problem because it doesn’t use any special functions of Heroku.

It would still be a challenge, though, because I would have to change my development and deployment processes, for example, when I moved to a different cloud.

Summary

Yes, that’s basically it:

• functionality
• performance
• compatibility
• usability
• reliability
• security
• maintainability, and
• portability, all these “-ilities”!

That’s the current state of affairs!

How about your software? When you write software for your audience to solve their problems, does it have enough quality?

If you want to check, if you want to do a quick self-assessment, I recommend having a look at ISO IEC 25010, that’s the current standard for that.

Be honest to yourself, answer all those questions for yourself, but … make a priority list! It need not be perfect, all at once, at the same time!

As you see from my assessment, there is still some work to do. But the most important thing is:

• Your users are happy!
• You can happily work on the app, so it doesn’t block you from extending or modifying it.
• And it’s operable enough, right? You should be able to sustainably operate it, without having too much hassle and headaches at 2am in the morning.

So, I think these are the most important points when it comes to quality.

This was this week’s quick quality check. See you next week with another the report from the development lab.

---

Outro

Thanks for listening to The Audience Explorer podcast, today.

You can find me on Twitter at @GetTheAudience and you can check out the blog at gettheaudience.com

If you have any questions about this episode, reach out on Twitter or send an email to matthias@gettheaudience.com

If you want to support this podcast, please leave a rating in your favourite podcast player app. This will help other founders or creators to find this podcast about developing an audience for their product or service.