The first question coming to my mind is: »What is a bug?«
Depending on how you define bug, the answer varies.
I find "bug" is the most overused techical term within our industry - and unfortunately even outside on the customer's side. Everything is a »bug« nowadays. And everyone thinks "bugs" are "critical" and so on.
I try to avoid the term most of the time - sometimes it slips over my lips which I regret immediately.
There are several classs of things which are described with the label »Bug«
simple typos: 10 taks completed-message instead of 10 tasks completed
simple mistakes: Choose between »a« and »a« instead of »a« and »b«
Display logic shows unexpected results (which are in itself correct but not expected to be seen)
results of calculations are just wrong
your webapp comes up with a HTTP 404, HTTP 400 or even HTTP 500.
...
The list goes on and on.
And for each of these classes of things which could go in the wrong direction, there are tools and methods to help detect these.
But I think the most important thing for me is to understand that there are ways to detect problems but not to prevent them.
Depending on what kind of software you build you have to make a cost-effort matrix to find the steps to take. There should be differences in developing software, where peoples lives depend on literally or only metaphorically, i.e. building e.g. medical products vs. the new productivity team communication app.
Working in a branch which is similar to the latter, I have not so hard requirements I can tell how my last project went with this:
It was software for the public sector (local scale, small userbase, small data).
How do you know you are ready to present your software?
I constantly developed preview versions, deployed and the customer reviewed changes. So I presented my software in a pre-beta-phase. But I released when we both agreed for a release. Timeline was flexible here.
Do you attempt to find any showstoppers or critical issues before a release goes out?
Showstoppers were in the category of HTTP 500 so yes, I clicked the paths.
The customer did the same.
Is shipping a fearful thing or is it second nature all day every day?
As I released on a near daily basis: it wasn't fearful.
But "going" live is always a bit "thrilling".
How do you find things you might have missed?
The interesting thing is that working closely with the customer dealing with "missing" things is less painful. There is no "blame mode", where a division between customer and provider of a service gets visible.
Since we both worked on the app closely, missing is more of an oopsi, we both haven't thought about that and makes fixes pleasant. As soon as we noticed, I fixed and both were good with it.
That doesn't work for every product and every customer but it was the mode I liked to work in the most so far.
Fast releases. ASAP fixes. No blame culture. Shared responsibility.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The first question coming to my mind is: »What is a bug?«
Depending on how you define bug, the answer varies.
I find "bug" is the most overused techical term within our industry - and unfortunately even outside on the customer's side. Everything is a »bug« nowadays. And everyone thinks "bugs" are "critical" and so on.
I try to avoid the term most of the time - sometimes it slips over my lips which I regret immediately.
There are several classs of things which are described with the label »Bug«
HTTP 404,HTTP 400or evenHTTP 500....
The list goes on and on.
And for each of these classes of things which could go in the wrong direction, there are tools and methods to help detect these.
But I think the most important thing for me is to understand that there are ways to detect problems but not to prevent them.
Depending on what kind of software you build you have to make a cost-effort matrix to find the steps to take. There should be differences in developing software, where peoples lives depend on literally or only metaphorically, i.e. building e.g. medical products vs. the new productivity team communication app.
Working in a branch which is similar to the latter, I have not so hard requirements I can tell how my last project went with this:
It was software for the public sector (local scale, small userbase, small data).
How do you know you are ready to present your software?
I constantly developed preview versions, deployed and the customer reviewed changes. So I presented my software in a pre-beta-phase. But I released when we both agreed for a release. Timeline was flexible here.
Do you attempt to find any showstoppers or critical issues before a release goes out?
Showstoppers were in the category of
HTTP 500so yes, I clicked the paths.The customer did the same.
Is shipping a fearful thing or is it second nature all day every day?
As I released on a near daily basis: it wasn't fearful.
But "going" live is always a bit "thrilling".
How do you find things you might have missed?
The interesting thing is that working closely with the customer dealing with "missing" things is less painful. There is no "blame mode", where a division between customer and provider of a service gets visible.
Since we both worked on the app closely, missing is more of an oopsi, we both haven't thought about that and makes fixes pleasant. As soon as we noticed, I fixed and both were good with it.
That doesn't work for every product and every customer but it was the mode I liked to work in the most so far.
Fast releases. ASAP fixes. No blame culture. Shared responsibility.