Posted in People on
Today we are talking to Evelina Kirliova, PMP, one of our senior project managers. She’s been with the team since 2022 and now works with our enterprise clients in Europe and USA.
We’ve seen these separately and combined in many projects over the years. It’s an amazing write-up and it’s hard to quote particular passage. We like the whole thing.
If you work on a complex system and have ignored technical, design and operational debts for a while give it a read. Besides the cautionary tales it contains good advice on how to manage these.
We stumbled upon this cool initiative by @lazyevaluated.
If the productivity gains from AI are so big, spending one day a week to minimize its downsides shouldn’t be a difficult trade-off.
However, why not do “No AI Mondays” instead. Mondays are notorious for statistically being the most stressful day of the week. Why accellerate the anxiety even more?
Also let’s put the bots to work on Friday, so we can leave early.
All the new features we shipped in Raketa Cloud during August.
A good read if you work on software that needs to keep changing for years.
We’ve been around long enough to learn that keeping a system healthy has to happen continuously – not during some mythical “technical debt sprint” or entire system rewrite. We’ve done those too, and believe us, they’re painful for both us and our clients. The problem is that regular maintenance is hard to sell. As companies grow, the focus naturally shifts toward new features and expanding the business, while the legacy quietly accumulates.
As Nat puts it nicely:
The problem with “tech debt” as a metaphor is that businesses like debt. There’s such a thing as “the right amount” of debt for a business. It’s not zero.
At Raketa, we try to bridge the gap between business growth and technical health by measuring complexity, test coverage, performance, dependencies and SBOMs – making the invisible a little more visible. We also reserve capacity and offer a separate team to keep this work independent from feature delivery and avoid conflicts.
Basically, we put a fixed, predictable cost on a hard-to-define risk.
That’s why we particularly liked this article. It articulates not only the compounding effect of small technical compromises, but also the compound effect of regular, small improvements.
Another great article from Jason Fried.
They don’t hate technology. But building and maintaining their own critical systems isn’t their wheelhouse, regardless of how much faster and easier it’s become. It’s another job on top of the job.
We can totally relate to this. More and more, clients arrive at our door with working prototypes and fleshed-out ideas, which is fantastic.
We’ve been able to build things that previously wouldn’t have made economic sense, both for customers and internally. We can prototype faster, iterate more freely, and remove huge amounts of friction from our collaboration.
But a prototype isn’t necessarily a product. Someone still needs to make the right trade-offs, turn it into a reliable system, maintain it, and be there when something inevitably goes wrong.
Because making software development accessible to everyone doesn’t make good software judgment universally distributed.
It makes it even more valuable. Being a good craftsman now matters even more. That’s the kind of software industry we want to be part of.
If that sounds like your kind of software company, you know where to find us.
Prototyping forms the foundation of our working process at Studio Raketa. Read why we find it important and how we learned to do it.
Contact
Tell us what you're building and we'll scope it with you.
We hire for craft and curiosity — show us what you've made.