Software engineering is about managing complexity

Join the discussion

• Hacker News
• Always reminds me of why OOP came about in the first place; it was a way to manage complexity and led to much better and grander software. Now nobody talks about OOP because abstractions are built into just about everything.
  by karim79
• I started to look around the site and opened this: https://hack8s.com/409/ziglings-all-exercises-solve-v0-16-0

  The site just goes into a reload loop on iOS?

  by thi2
• Sometimes these tradeoffs involve half a dozen over a few lines of code. And that’s where I’m hesitant to let an agent work. It’ll do fine with creating correct code. And you can somewhat constrain it to think about one other thing. But it loses track, ignores constraints, cheats, and do you layer complexity on top to prevent this? Or just look at a dozen lines of code to fix it?
  by softwaredoug
• > By algorithmic thinking, I mean defining a set of basic rules to follow and applying everyday...

  This is actually kinda a good suggesting for everyday life as well. Many problem people face are too complex to figure out without systematic analysis, and with this method of thinking, complexity can be simplified.

  Of course you have to do some swaps:

      > Understand data flows                    -> Understand whats, hows and whys
      > Choose appropriate data structures       -> Choose appropriate tools
      > Reason about time and space complexity   -> Reason about cost and effectiveness
  

  BTW: Is this article was about LLMs induced identity crisis? I noticed quite a few blogs written in a similar color trying to realign themselves in the new world of AI.

  Of course that's a reasonable thing to consider, but in addition to that, I think it's also kinda useful to remember why you started as a software engineer to begin with, what were you planning that drives you to select this path? Will AIs be a blocker of that plan, or a enhancer?

  by nirui
• Software complexity grows superlinearly, if not exponentially as you add components.

  There are things an engineer can do to flatten the curve - that is OP's complexity management idea - but complexity growth can never be linear as long as you are adding to the software.

  I made a model/theorem for this that I posted on X: https://x.com/i/status/2027771813346820349

  Code generation has exposed that verification is the central problem of software engineering. And I think it always has been.

  Defining what is "correct" can be hard enough, let alone building a system that lends itself to verification, let alone spending the time to verify. Releasing software and letting users find bugs is therefore a very efficient strategy, because it spreads the burden. But you have to ride the line between losing users and getting enough feedback to find and fix the bugs that matter.

  As we confront whether AI might take our jobs, I take some comfort in the idea that the world might be too complex for even the largest, best trained AI we can imagine. At a certain point, you need to simulate the whole world (or some substantial portion of it) and the cost/benefit of trying to do all that with compute may not be worth it versus using the real world (that is, humans) as your verifier.

  by wyum
• AI can also generate the architecture for you based on the requirements, and ask the necessary clarifying questions.

  It's not as good at system design as writing code, yet. But it feels like it's better than most of my coworkers.

  I think in a few months, system architecture will have its Claude Code moment, and humans will be outclassed.

  by a2ff6eeb0
• Lost me at the first assumption. People can argue about how useful AI is, but it's obviously not essential because we somehow managed to write code without it a few years ago. I would even say the code was better back then.

  The two tasks of writing code and engineering software cannot be separated without damaging the integrity of the mental model of the engineer. Having architects who didn't interact with the code always produced map/territory mismatches.

  by cobbal
• The complexity stuff is all absolutely true.

  However I think it's aggrandizing what human engineers actually do with remarks like "Engineers own tradeoffs." My experience is that certainly less than half of the employed software engineers don't actually give a real analysis to questions like:

  "Given these constraints, this team, this business, this infrastructure, this budget, these risks, and the expected evolution of the product, what is the most appropriate way to implement X, today?"

  Thus I think AI is more able to replace the average engineer more than this article admits, however the inadequacy of "average engineering" will be much more apparent now: codebases can become large/complex enough to be unwieldy in months now when it used to take 5 years [a timescale where accountability is effectively impossible].

  by zug_zug