Conversation

Notices

1. Embed this notice
   Insecurity Princess 🌈💖🔥 (saraislet@infosec.exchange)'s status on Monday, 14-Jul-2025 20:44:28 JST Insecurity Princess 🌈💖🔥

   One of the problems with vibe coding is that the hardest part of software engineering is not writing the code, rather it's *choosing* what to code, and designing the system (and, later on, maintaining the code/operations/etc)

   The barriers and investment cost to writing code is itself a *desirable* aspect of software engineering because it forces you to make careful, good choices before you invest in building something

   Because the majority of the time spent writing, say, curl, is not writing the original tool but rather maintaining it over time, it's important to make good choices from the beginning, and at every major version change

   • Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Monday, 14-Jul-2025 23:48:36 JST Rich Felker

     in reply to

     @saraislet While GenAI is the current Big Evil, I think it's important to remember even the earlier applications of TensorFlow and the like were committing big harms. Recommendation engines were the core of the nazi radicalization pipeline, and automated labeling has perpetuated harmful biases in all sorts of ways (labeling picture of doctor as a nurse if she's a woman, assigning genders to YouTube accounts based on stereotypes of viewing habits, then reinforcing those by declaring 100% of viewers of a particular video are male, etc.)

     IMO the whole field of applying any kind of statistical model to things that intersect with human behavior is rotten, dehumanizing, and destructive to our shared future. At most this stuff belongs at the level of modeling physics, chemistry, and biochemical processes not complex emergent phenomena.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Insecurity Princess 🌈💖🔥 (saraislet@infosec.exchange)'s status on Monday, 14-Jul-2025 23:48:37 JST Insecurity Princess 🌈💖🔥

     in reply to

     Writing software involves considerations across many areas (including and beyond design, maintenance, operations, and security), all within collaborative sociotechnical systems.

     Writing software has evolved SO much since my mother was punching stacks of cards in Assembly! We have higher level languages and compilers that optimize code, memory safe languages, cloud computing, Infrastructure-as-Code, etc.

     A good example of how software engineering has evolved: One of the hardest problems 15 years ago was "which part of this complex distributed system is broken?" And although tracing methods go back to basic print debugging (in the 1960s if not earlier), open source products like OpenTelemetry is what turned this virtually overnight into a solved problem.

   • Embed this notice
     Insecurity Princess 🌈💖🔥 (saraislet@infosec.exchange)'s status on Monday, 14-Jul-2025 23:48:37 JST Insecurity Princess 🌈💖🔥

     in reply to

     OpenTelemetry and generally distributed tracing techniques have been transformative for software engineering in exactly the way that GenAI has not been.

     I'm a mathematician, and I've loved machine learning since I first learned about Markov chains. Some of my earliest code was machine learning…back in the 1990s when we called it mathematical modeling.

     In my opinion, one of the most transformative advances in machine learning is having cloud-based tools that make it easier to develop and iterate on models, handle data, etc. That and tools like TensorFlow nearly democratized development of relatively good ML capabilities like recommendation systems or automated labeling.

   • Embed this notice
     Insecurity Princess 🌈💖🔥 (saraislet@infosec.exchange)'s status on Monday, 14-Jul-2025 23:48:38 JST Insecurity Princess 🌈💖🔥

     in reply to

     2. On the order of 60 tools were historically maintained by about 8 people for most of the last 10 years.

     Granted, half of those tools are glorified scripts, tiny little things. But it was manageable to operate and maintain 60 tools by 8 people because they were built for reliability and resilience, within a resilient platform that made it easy to operate software, redeploy instances and entire clusters, etc.

     And it continues to be reasonable to maintain and operate because the code is written with clear logging, errors, monitoring, etc. (Okay, most of it. There are gaps, so this also involved a lot of luck 😅.)

     So it's important to be thoughtful from the design stage and regularly in maintaining it about how software will be operated and maintained — and retired! — in the long-term over the years.

   • Embed this notice
     Insecurity Princess 🌈💖🔥 (saraislet@infosec.exchange)'s status on Monday, 14-Jul-2025 23:48:38 JST Insecurity Princess 🌈💖🔥

     in reply to

     3. We think about when to RETIRE software! We probably haven't retired enough.

     Merge the useful parts into newer systems (or rewrite then if that makes sense). Hand off tools or systems that are no longer part of a team's scope, maybe to more relevant teams or to the downstream teams that depend on it, or to upstream teams who are a better fit for owning that product, etc.

     Whatever the direction should be, retirement of software is a topic to think about intentionally and regularly.

   • Embed this notice
     Insecurity Princess 🌈💖🔥 (saraislet@infosec.exchange)'s status on Monday, 14-Jul-2025 23:48:38 JST Insecurity Princess 🌈💖🔥

     in reply to

     4. Infrastructure platforms are intricately collaborative sociotechnical systems of systems, with interactive intertwined layers of domains, teams, and expertise across networking, security, hardware/cloud, developer-facing interfaces, and the many abstractions of/by/for each of these.

     So all of the above and below aspects of software happen within these collaborative sociotechnical systems. We design, implement, maintain, operate, retire, and so on, all through collaboration to think about and plan in advance around things like downstream dependencies if something were to go wrong or if we consider retirement, or how we're affected by upstream decisions/incidents/etc.

   • Embed this notice
     Insecurity Princess 🌈💖🔥 (saraislet@infosec.exchange)'s status on Monday, 14-Jul-2025 23:48:38 JST Insecurity Princess 🌈💖🔥

     in reply to

     5. Within security (with insecurity?), we always consider how the ever-evolving threat landscape may affect these systems.

     With all the complexity being discussed here, security can seem intimidating—but through tools (and abstractions) like threat modeling, we can focus on the most likely goals of threat actors, what we most want to protect or prevent (e.g., confidentiality/integrity/availability), and the steps of an attack chain where we can most effectively prevent or detect.

   • Embed this notice
     Insecurity Princess 🌈💖🔥 (saraislet@infosec.exchange)'s status on Monday, 14-Jul-2025 23:48:39 JST Insecurity Princess 🌈💖🔥

     in reply to

     1. Those tools are maintained by security software engineers many years after the original authors left the company

     So it's rather important that those tools are easy to understand and maintain. Readable code, composable parts, unit and integration tests, etc.

   • Embed this notice
     Insecurity Princess 🌈💖🔥 (saraislet@infosec.exchange)'s status on Monday, 14-Jul-2025 23:48:40 JST Insecurity Princess 🌈💖🔥

     in reply to

     Early in my career, I built a system for a customer that made it easier for their university to automate sending invitations and login instructions for new users.

     I missed some key differences in some user environments that weren't covered in my testing, and I ended up sending thousands of malformed login invitations... twice.

   • Embed this notice
     Insecurity Princess 🌈💖🔥 (saraislet@infosec.exchange)'s status on Monday, 14-Jul-2025 23:48:40 JST Insecurity Princess 🌈💖🔥

     in reply to

     If I'd been forced to write separate login invitations manually for each segment of the user population, I would also have been forced to do more fine grained testing and take more care to ensure it works and think through the details.

     But as a starryeyed new engineer, I was too excited by the idea of automating the whole thing in one go. I made it too easy to distribute the impact of my mistake, and I wasted the time of thousands of users.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Insecurity Princess 🌈💖🔥 (saraislet@infosec.exchange)'s status on Monday, 14-Jul-2025 23:48:40 JST Insecurity Princess 🌈💖🔥

     in reply to

     I have a much wider and wiser perspective now: The tools developed by my teams are operated by them day in and day out, used by thousands of engineers daily, maintaining products that are used by hundreds of millions of customers night and day around the world