Slawomir Smiechura

Everything was late and the company was failing. Then we got introduced to ‘agile development’ that will solve all our problems. We were looking very puzzled - it was 2005. The new CTO said: “we’ll do everything the same way as today - just much-much faster“ (the company did not make it, but that's for another story) If we want to have different results - be different - It’s not enough to do the same thing, just better: we need to do things differently. This podcast is a great introduction to one possible way: https://lnkd.in/dHc6X8Qf ▶️ no large teams -> no large meetings -> no slow decisions ▶️ saying no to more things -> keeping the product simple -> don’t need a big team to just run it ▶️ no fixed promises -> no s̶i̶l̶l̶y̶ inaccurate estimates -> no end-of-project deathmarches The combination of an enforced cutoff time and flexible scope is the closest I found to the investment concept of stop-loss in engineering.

11

How many of your supposedly internal-only backends are serving critical end-user traffic? Probably more than you think! Most frontend services have many transitive dependencies, and understanding these dependencies becomes increasingly difficult as your system grows in scale and complexity. As a result, it becomes exceptionally tricky to ensure that internal-only backends are fully isolated from end users. Google uses a common infrastructure platform for almost all of its services, internal and external; this provides for a message-passing mechanism common to all of these services. One outcome is that systems engineers can build accurate dependency maps of services; and that we can ensure new services only depend on other services at the same level or higher in the dependency stack. Risky dependencies — in this case, dependencies which place internal-only backends on the critical path for end users — can be a source of major production outages, because the internal-only backends do not generally have necessary reliability or safety guarantees. For example, you might have an externally-visible service that requires high levels of availability and performance, and this system has an indirect dependency on a backend with no availability or performance SLOs. At Google, we found success preventing major and huge outages by clustering services into categories with distinct properties, clear perimeters, and limited blast surfaces. The properties will depend on the guarantees we want to enforce. In this article, we use Google Maps to demonstrate how risky dependencies proliferate in complex systems, and then showcase how clustering Google Maps services into just two categories ("Internal" and "External") can prevent major and huge serving outages. We also outline how OpenTelemetry is used to identify violations of this clustering, which can be fixed before the violations cause a major serving outage. This article is based on a talk at SREcon EMEA, which you can see here: https://lnkd.in/e54b6G6p.

1

Are you aware of a new tool designed to improve code quality in Spryker projects: Project Architecture Sniffer https://lnkd.in/dieQSK6N? Built on the well-known PHP Mess Detector (PHPMD), this package is tailored specifically for Spryker's architecture. 🔍 It helps developers detect and fix architectural issues early.  ⚙️ Optimized with Spryker-specific rules to ensure adherence to best practices.  ⏱️ Save time by automating architecture validation throughout your development process. The tool seamlessly integrates into your CI pipeline, ensuring your code is always clean and efficient. Stay tuned for updates, and feel free to reach out if you’re interested in using it in your projects or contributing to its development! #Spryker #PHP #CodeQuality #Architecture #SoftwareDevelopment #OpenSource

7

The benefits of AI code assistants are still being evaluated, but here at Deutsche Telekom we are confident that our AI strategy to continually assess COTS products, as well as developing our own products and data foundation is the right approach to yield benefits in the future. Have a look at the post below from one of our leading developers on the topic It’s exciting to think about the capabilities of the product in only a few years from now; perhaps covering all aspects of the SDLC and integration to user stories, more context in relation to existing code repos throughout the enterprise (particularly useful for very large enterprises), models optimized for dialects of the languages (GoogleSQL vs PostgreSQL etc)….to think of a few examples Regardless, the developer experience will be greatly enhanced in the next few years and at Deutsche Telekom we’ve got a front row seat! 👏

16

1 Kommentar

If LinkedIn post trending I've seen is to be believed: TDD seems to be making a HUGE comeback. It reminds me of when JS came back into fashion (a long time ago, kids) after being relegated to the pile of joke languages (an even bigger joke back then, JS-haters). For the longest time, it was "TDD solves everything and any opinions to the contrary are wrong". Then you heard nothing about TDD, not a peep. I think it was right around the time of DHH's post about TDD (below). Now, tada, it's back, and just like before, you're wrong if you don't have `I ❤️ TDD 4-EVA` tattooed on your lower back. Me and my team break all the rules and it would be hard (but not impossible) to convince me otherwise: - We only test end-user facing UX, full-stack/integration level. I'm not maintaining a test for MyServiceObject#convert_this if the method signature changes. I only care about the user experience. - Each daily PR must include coverage but big features behind a flag get coverage near the end. Each team member can do what they want but I'm not burning a day of complex mocking just so Product can say "whoops, that's not needed now". Coverage when it's showtime before the curtains go up. We are currently on Playwright + axe-core (for a11y compliance) and we love it. Migrating away from rspec + capybara (flakier than a bowl of frosted flakes). More on Playwright in another post (it's amazing). I don't think TDD is bad. I just want to mock things as few times as possible before a release, because test env data bootstrapping is a giant pain. To each their own, as long as your UX is protected.

9

4 Kommentare

The revolution and all the hate Agile gets these days seem to be coming from bad integration of Agile in companies, which leads to bad experiences. But what needs to be separated in this equation is Agile methodology and bad experiences with bad implementation by managers in the same company. 💡🤔 Gojko Adzic makes an excellent point here — the normalization of Agile practices isn’t a sign of their decline; rather, it highlights their maturity. It’s easy to confuse the quiet efficiency of practices like automated testing and continuous integration with a lack of innovation, but in reality, these systems have become the bedrock of modern software development. Agile, in many ways, has succeeded so thoroughly that we no longer notice it. The fact that "agile" is in the background of our daily workflows should be seen as a win. It's a testament to the adaptability of teams that Agile and Scrum no longer need to be front and center in every conversation—they've done their job of empowering us to focus on delivering value rapidly and efficiently. This opens up opportunities to reflect on our processes and make incremental improvements while riding on the strong foundations Agile built. This isn't the end of Agile—it's its evolution into a natural state of being for teams. #agileisdead #agile #scrum

1