1. Know what and why you are building. Some would call it business-domain knowledge. I'd prefer calling it "now why your product is being used, and how it is used exactly". This alone gets rid of the vast majority of bugs and other problems.
2. I used to be a QA for about a decade in a previous life. I know where and how classic (technical) bugs happen, it's easier to avoid then that way.
Automation is not a great way to catch the important bugs, at least until good AI test frameworks become better and more common. Automation is good in finding the known knowns, and sometimes ok in finding the known unknowns, but it is terrible in finding the unknown unknowns.
Surely, important bugs are ones that make it into production and impact your service - so any solution that catches bugs and stop them making it into production aren't catching the important ones.
Your point about automated testing only catching known knowns and known unknowns needs to be understood by everyone in the IT industry, because that's why it's so powerful - it frees up resources that would otherwise have to be looking for those issues, which can then spend their time looking for the unknown unknowns.
Someone on the inside being obsessed with the product. As a user.
There's a night and day difference between products that get used by the people who make it and those who ship it off to the user and wait for the response.
This is primarily aimed at B2C but there's plenty of cases where it applies in B2B as well (if you can somehow use your own product).
Dogfooding is one attempt to mimic this, and it can work. But what I really mean is someone inside the company actually cares enough, is interested enough, to use the product for themselves. Without being told to.
I work on software to assist public transit. The fact that my own city uses this software, and that I use public transit all the time, is as close as I can get to this. Even that amount of interaction helps drive better UI/UX decisions quite a bit.
Secret sauce is not a technical one, but rather organizational. Pushing back against product/marketing/management to timely address the tech debt is vital for a product quality. As opposed to always sprinting to implement new features.
Organizational is the right answer, but it works both ways- you shouldn't let the technical side force and lead the business side, for example by chasing the latest and greatest if it doesn't solve any customer need.
I do code reviews as part of team meetings - so assign someone to review the code, then walk it thru in the meeting. It allows us to be clear on the expectations and discuss changes
The key is to not make it an ego led session to keep discussion open
Less. When I write JavaScript I use ECMA modules, primitives, 1 style of loop, arrays, functions, objects, and conditions. That’s it.
I limit my use of dependencies to as few as possible, typically just TypeScript and a compiler like SWC. No frameworks because that’s nonsense I don’t want to be responsible for.
I measure things. When people talk about performance they are almost always full of shit and likely wrong by several orders of magnitude. When I mention that my software is fast it’s because I have numbers for my own software. I also have numbers for the competition, where products or alternate conventions, so I know just how much faster my software is.
My prior application was a peer to peer file sharing application that displayed an OS-like gui in the browser. I need end to end test automation that could work on multiple computers in a peer to peer model. Since that did not exist I wrote my own and was able to run about 300 tests in 8 seconds on a local computer and about 200 tests in 30 seconds across 5 computers interacting with each other using the application.
If you want quality in your software you need to really own it. All of it and obsessively so. If your team pushes back because they need easy or some superficial bullshit like React or Angular then people management is, by far, your biggest problem.
11 comments
[ 6.0 ms ] story [ 41.0 ms ] thread2. I used to be a QA for about a decade in a previous life. I know where and how classic (technical) bugs happen, it's easier to avoid then that way.
Your point about automated testing only catching known knowns and known unknowns needs to be understood by everyone in the IT industry, because that's why it's so powerful - it frees up resources that would otherwise have to be looking for those issues, which can then spend their time looking for the unknown unknowns.
There's a night and day difference between products that get used by the people who make it and those who ship it off to the user and wait for the response.
This is primarily aimed at B2C but there's plenty of cases where it applies in B2B as well (if you can somehow use your own product).
Dogfooding is one attempt to mimic this, and it can work. But what I really mean is someone inside the company actually cares enough, is interested enough, to use the product for themselves. Without being told to.
The key is to not make it an ego led session to keep discussion open
I limit my use of dependencies to as few as possible, typically just TypeScript and a compiler like SWC. No frameworks because that’s nonsense I don’t want to be responsible for.
I measure things. When people talk about performance they are almost always full of shit and likely wrong by several orders of magnitude. When I mention that my software is fast it’s because I have numbers for my own software. I also have numbers for the competition, where products or alternate conventions, so I know just how much faster my software is.
My prior application was a peer to peer file sharing application that displayed an OS-like gui in the browser. I need end to end test automation that could work on multiple computers in a peer to peer model. Since that did not exist I wrote my own and was able to run about 300 tests in 8 seconds on a local computer and about 200 tests in 30 seconds across 5 computers interacting with each other using the application.
If you want quality in your software you need to really own it. All of it and obsessively so. If your team pushes back because they need easy or some superficial bullshit like React or Angular then people management is, by far, your biggest problem.