Everybody has time to write an automated test. If you don't, then you don't have time to write code in the first place.
That's the difference between professional software engineering and just hacking something quick in your free time.
You wouldn't ride a motorbike at 150mph on a German autobahn if it was put together by your neighbor with parts from a junkyard in an afternoon. Unclear to me why you'd treat software any different.
Fair, automated tests are important, but it's still ludicrous to call automated testing "1%". It's a lot. And let's be real - there isn't always the time, requirements being what they are, especially for properly isolated unit tests. But I'm always an advocate for a "worse-is-better" integration-test-script that requires a full test environment rather than having to build a full mock architecture. Unit tests are the gold standard, but a few integration tests per-feature are a good bare minimum.
My personal conclusion is to never work under management who are not software engineers themselves. All my bosses understand what building great software entails since they could do it themselves. So what I do to improve qualiry has always their backing. And nobody can BS them into some nonsense.
Those competitors will be known for crap quality and eventually their product beasts will be unmaintainable and hard to extend. So, while you keep steadily improving and extending they will eventually fold under their own unsustainable mess. I've seen it many times and been on the other side of it often enough.
Considering automated testing as "technical debt" is why there is so much crap out there.
> ship awesome product and iterate as fast as possible
And that attitude is why so much software just sucks. Spending some time to contemplate and test and find out what's good and throw away what's not before it ships, all that goes a long way with quality. "Iterate as fast as possible" is one of those immature ADHD approaches and I'd run if a manager forced my team to do this kind of rushed nonsense.
> Spending some time to contemplate and test and find out what's good and throw away what's not before it ships
Why would you build something to throw away before it ships? Hire good people and they won't build un-shippable crap. "As fast as possible" doesn't mean you rush things, it just means you don't waste time with all these peripheral activities.
> Why would you build something to throw away before it ships?
That's because you learn things along the way. About underspecified requirements, about design choices that looked good on paper but ended up brittle, about tech that promised something but couldn't hold up to it when tested out thoroughly. There are many reasons and in every field you see this effect.
> Hire good people and they won't build un-shippable crap
Ever heard of a prototype? Those exist for a reason.
(The projects I work on typically spend over 50% on automated tests, but I'm in an area of the software industry where we really can't have and bugs escape into the wild. I wish more areas would work like that.)
> Writing documentation is always a time sink, though, in my experience. Or maybe I'm just not good at it :P It's usually an additional day of work overall, though.
And it saves you days and days of re-discovering truths about your code weeks/months/years down the line. Sometimes those rediscovered facts are not even true which will come bite you big time.
Integrate your documentation with your testing. That makes it easier to create and maintain. You don't have comprehensive automatic tests? Then that's your problem right there.
* comments in code
* team-based comments
* project design docs
* knowledge-base articles for handling on-call rotation around feature
* how-to guides for customers
Each of these has a different cost and a different direct/external usefulness. I absolutely believe in good documentation and I absolutely believe that it's valuable. It does not negate the extra cost of including these forms of documentation - especially the "not-in-code" documentation.
Of course they "cost". But the issue is the mindset that they are "extra". They are not. They are an integral part to professional software engineering. You can't take them away without moving from a professional craft into some hobby hack.
When developing medicine you wouldn't consider safety studies as "extra". When you fly an airplane then the take off checklist is not "extra". Arguing that automated test suites or documentation are just "extra" on top of making software and could be skipped is similar to arguing that you could fly a plane without any checklists or releasing medicine to the public without evaluating its safety. That's just unprofessional nonsense.
And that's a problem. Often there are full of issues which eventually are all known but never fixed.
Updateability is the defining advantage of software over pure hardware solutions. If you don't use the advantage then you are stuck with just all the disadvantages.
Nice theory, but it is overfitted to a broad category of all software and a product that is thriving shouldn't be conflated with a product that is improving.
Some products with software continue to "live on" successfully and thrive, without updates. Think of a digital alarm clock who's goal was to help typical users to wake up on time most of the time. If you ship a product that does that and it isn't being updated, is the product really dying or doomed to failure?
No alarm clock will ever wake everyone up on time, but we can always strive to get closer to that goal if we chose to set that goal. An unreasonable goal could cause unnecessary bike shedding, etc.
But a simple pacemaker for the heart, the goal is closer to the idea of helping as many people as possible, rather than most. Hopefully we write good software and we go 15 years without needing an update. I think that is better than bad software that has to receive more updates. Which software is more "alive" and "thriving". Is the good software with no updates for 15 years really "dying" since it isn't "improving"? Again, thriving and improving shouldn't be conflated.
So, a product setting appropriate goals helps determine how much maintenance is actually necessary and some goals can be met without requiring any future maintenance. Other goals may benefit from frequent maintenance. Some products can thrive without improving. A product's goals determine's the importance of improvements.
Putting "automated testing" into the last 1% is the issue right there. It needs to be part of what you are doing from the start. You are done when your automated tests are complete and reliably green, not when some underpaid tester in Bangladesh gives their thumbs up.
Ideally your documentation is tightly integrated with your tests too, then it will be done as well and won't go stale.
The key here is the dishonesty in society. It annoys me every day.
I hear 30-year old overpaid software engineers brainstorming how to cheat the ticket checks at the ski resort. I watch people at all-you-can-eat buffets piling more food on than they can eat and bring something with them for consuming later at home or by their family. People discussing tax loopholes. Or how to get train rides for free if nobody checks the ticket. All well-off folks. Cheating their way through life. It's sickening.
It makes me wonder whether religion may actually be a (partial) solution to this. An atheist myself, I can see value in brainwashing people into believing that they are constantly being watched by an almighty being which will ensure they go to hell if they steal or similar, even if nobody else is watching.
That's the difference between professional software engineering and just hacking something quick in your free time.
You wouldn't ride a motorbike at 150mph on a German autobahn if it was put together by your neighbor with parts from a junkyard in an afternoon. Unclear to me why you'd treat software any different.