When you purchase through links on our site, we may earn an affiliate commission.Heres how it works.
Would you be surprised to hear software developers do test their software?
Then whats with all the outages?
These outages didnt happen because developers didnt test software.
Many companies are testing code within a software architecture nobody understands anymore.
Its a hideously large Jenga tower.
Just one more feature block might collapse the whole thing.
No one wants to touch it.
No one even remembers how it was built.
But sooner or later, an executive decrees this product needsAI.
Director of Product Management and Product Marketing at Qt Group.
Why is software eroding?
Like rocks and mountains, oursoftwareis slowly eroding over time.
If software is a rock, then developers are the wind and water breaking it up.
Thank the dependency hell weve put ourselves in.
A developer gets asked to add a new feature.
Said feature bloats the codebase.
The developer adds a shortcut to work faster, which adds complexity.
A manager asks the developer to expand the product.
The shortcut from earlier?
Its incompatible with the update.
The developer starts patching.
It takes a long time.
The developer adds another shortcut and….round and round it goes.
The eventual outage disaster and ensuing PR blunder is just an extra sledgehammer to morale.
The next thing that happens is attrition from engineers who have had enough.
Onboarding new engineers then lengthens time to market, frustrating everyone involved.
Old mistakes resurface, more people leave, except now its also seasoned veterans.
Where does it end?
The cyclical misery many developers face wont end until we fix shift left itself.
Fixing shift left means not just dumping more testing time into developers busy schedules.
Some companies hire external QA testers to lessen the burden, but thats an expensive mitigation.
Its slapping scotch tape on the leaking holes of a deck thats being battered by warships.
A late fix is a costly fix.
The least costly fix is getting your architecture right when youre still designing it.
Weave QA tightly into your software development before writing all the code, not after.
If youre early into prototyping, then sure, QA might be unnecessary overhead.
But the moment you build a viable business that attractscustomers, you need quality code.
You dont want to lose customers early in your products lifespan.
It will push your time to market out, balloon development cost, and burn everyone out.
How do you get quality code?
You need multiple sources ofintel.
Dont skimp on static code analysis and functional tests, which should be run as new code is written.
When you know these things and run your architecture verification, its easier to identify problems.
More importantly, does your architecture even let you achieve your objectives?
If not, time to re-architect.
A company with decades of legacy code might not be able to, but anSMEwith five years of code?
The litigiousness of unhappy customers dwarfs any headache involved in re-architecting.
Understand, too, that different roles have different incentives.
Developers sometimes resist static code analysis because its additional work and adds time to projects.
Whose responsibility should this be?
Figure that out early.
Too few people know their architecture inside out.
With a little discipline, that can change.
It has to, because that tower is collapsing soon.
We’ve featured the best laptops for programming.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc.
If you are interested in contributing find out more here:https://www.techradar.com/news/submit-your-story-to-techradar-pro
