[HN Gopher] We are destroying software
___________________________________________________________________
We are destroying software
Author : antirez
Score : 397 points
Date : 2025-02-08 14:48 UTC (8 hours ago)
(HTM) web link (antirez.com)
(TXT) w3m dump (antirez.com)
| skybrian wrote:
| This seems rather alarmist because it's so focused on the bad
| things and ignores the improvements that come along with the
| churn.
|
| With each new language and new library, there's a chance to do it
| better. It's quite a wasteful process, but that's different from
| things getting worse.
| the_mitsuhiko wrote:
| You can read it as alarmist, or you can read it as a rather
| sobering reflection on the current state of affairs. The world
| will not end, nothing will explode. What however I think will
| happen is that the next generation of engineers is going to
| judge us by our creations and learn from it.
| pvg wrote:
| I think CJ (Continuous Judging) is already the well-
| established, default practice.
| the_mitsuhiko wrote:
| I only take issue with the "alarmist" part of it.
| jmclnx wrote:
| I agree and you are talking to the choir here :)
|
| Many of these have been an issue since I started programming many
| decades ago on minis. Seems as the hardware gets more powerful we
| find ways to stress out the hardware more and more. This making
| your list true to a greater extent year after year.
|
| BTW, I like your WEB Site format a lot!
| sirnicolaz wrote:
| A bit of incoherence between this
|
| 'We are destroying software telling new programmers: "Don't
| reinvent the wheel!". But, reinventing the wheel is how you learn
| how things work, and is the first step to make new, different
| wheels.'
|
| and this
|
| 'We are destroying software pushing for rewrites of things that
| work.'
|
| But generally speaking I grok it.
| antirez wrote:
| The rewrite line is about "Let's rewrite this big system from X
| to Y", not about experimenting creating new variants.
| Trasmatta wrote:
| I think that's actually pretty pragmatic. Sometimes the answer
| is to reinvent the wheel. Sometimes the answer is to keep
| improving the system that already works.
|
| The problem, IMO, is globally applying either rule.
| Trasmatta wrote:
| > We are destroying software pushing for rewrites of things that
| work.
|
| And sometimes the reverse problem is what is destroying software:
| being unwilling to push for rewrites of things when they
| desperately need one. I think we may have over indexed on "never
| rewrite" as an industry.
|
| > We are destroying software mistaking it for a purely
| engineering discipline.
|
| And I'm also seeing this the other way: engineers are beginning
| to destroy non software things, because they think they can
| blindly apply engineering principles to everything else.
| fouc wrote:
| Reminds me of https://www.ultratechnology.com/1xforth.htm
|
| Arguing against 10x complexity & abstractions, with 1x coding :-)
| mewpmewp2 wrote:
| All the statements in that post are trade offs. In all cases you
| are sacrificing something to gain something else. Therefore in a
| way you are always "destroying" something.
|
| Sometimes it is valid to not reinvent the wheel. Sometimes wheel
| needs to be reinvented to learn. Both actions are done. Sometimes
| the decision was right. Sometimes not.
|
| Overall as a whole we are creating things, more than we are
| destroying. I don't see the need to take a negative stance.
| antirez wrote:
| > Overall as a whole we are creating things, more than we are
| destroying. I don't see the need to take a negative stance.
|
| Fair point: each one of us can think about the balance and
| understand if it's positive or negative. But an important
| exercise must be accomplished about this: totally removing AI
| from the complexity side.
|
| Most of the results that neural networks gave us, given the
| hardware, could be recreated with a handful lines of code. It
| is evident every day that small teams can rewrite training /
| inference engines from scratch and so forth. So AI must be
| removed from the positive (if you believe it's positive, I do)
| output of the complexities of recent software.
|
| So if you remove AI since it belongs to the other side, the
| "complicated software world" what gave us, exactly, in recent
| times?
| mewpmewp2 wrote:
| If we discard the AI, which I don't think we should, but if
| we do - my life has been enriched a lot in terms of doing
| things I want to do vs things I don't want to. Very quick
| deliveries, I never have to go to a physical store, digital
| government online services, never having to wait in any
| queue, ability to search and find answers without having to
| go to libraries or know specific people. Online films, tv
| shows on demand, without ads. There are tons of those things
| that I feel have made my life so much easier.
| antirez wrote:
| Why this is a result of software complexity? I'm not in
| favor of _less capable_ software.
| mewpmewp2 wrote:
| I am not sure I understand you then. The post was saying
| we are destroying something, but I feel like we are
| constantly gaining and that things are getting better.
| LocalH wrote:
| The services that enable the things you desire also create
| harm (Amazon's problems are well documented, digital
| government services are often a divide that sometimes
| exclude freedom-minded indivuduals who don't use a
| "mainstream" OS, to name a couple).
|
| AI has the potential to make the situation much worse, as
| many laypeople confer it an air of "authority" or
| "correctness" that it's not really owed. If we're not
| careful, we'll have an AI-driven Idiocracy, where people
| become so moronic that nobody can do anything about the
| system when it takes a harmful action.
| mewpmewp2 wrote:
| Sure, there are trade offs and risks to everything and
| everything new. Cars made us move faster, but can pollute
| and cause injury or death. But summing all of those
| things together, I would not pick any other time before
| now to live. And same with software development.
| azemetre wrote:
| I'm sure factory owners said the same thing in England in
| the early 1800s.
|
| It needs to be noted that the average person's lot didn't
| improve until 150 years later. There's no reason why
| technology can't be decided by democratic means rather
| than shoved in our faces by people that just want to
| accumulate wealth and power.
| willturman wrote:
| What more could someone want than instantaneous consumption
| and on-demand video? We're truly living in a frictionless
| utopia.
| mewpmewp2 wrote:
| I may have worded it poorly, but everyone can choose the
| content they consume. And activities they do. You can
| choose mindless things or things that allow you to learn
| about the World and understand. Both are easier.
| gmueckl wrote:
| "Destroying software" is broader than the creation of new,
| working software artifacts in the moment. The phrase refers to
| changes in engineering culture in software and it's long term
| effects, not the immediate successes.
|
| Writing a new green field project using 10.000 npm dependencies
| for an electron based front end is shockingly easy. But how do
| you keep that running for the next 15 years? Did the project
| need npm? Or a web browser? How do all the layers between the
| lamguage of choice and the bare metal actually behave and can
| you reason about that aggregate accurately?
|
| The field has come to a point where a lot of projects are set
| up with too many complexities that are expedient in the short
| term and liabilities in the long term.
|
| The current generation of junior devs grows up in this
| environment. They learn that these mistakes as "the right thing
| to do" when they are questionable and require constant self-
| reflection and reevaluation. We do not propagate a hacking
| culture enough that values efficiency and simplicity in a way
| that leads to simple, efficient, stable, reliable and
| maintainable software. On a spectrum of high quality
| craftsmanship to mass-produced single use crap, software is
| trending too much to the latter. It's always a spectrum, not a
| bunary choice. But as a profession, we aren't keeping the right
| balance overall.
| mewpmewp2 wrote:
| World is full of abstractions on many different levels.
| Something being on a lower level doesn't inherently mean
| superior. You can go in any direction on the scale or
| spectrum. Do you know how exactly atoms behave that computers
| are made out of? There are plenty of people working on all
| different sorts of abstractions, new abstractions appear and
| demand for lower level increases when it is needed. You could
| say that as more abstractions are built on top of lower level
| the balance of all the field will go higher in abstraction
| level on average, but that is the natural way to evolve.
| Abstractions allow you to build faster and the abstractions
| are possible because of lower level elements. In the end if
| you are measuring what an average level of abstraction for
| current industry is you can draw the line arbitrarily. You
| could include the people who use website builders and you can
| calculate the average to be even higher. We need people
| working on at all different levels of abstraction. We could
| divide the groups with 2 different naming convention for
| lower level engineers and higher level, then technically you
| could go back to calculating that average is still where it
| used to be.
|
| I definitely use npm (or rather pnpm) because I know it will
| allow me to build whatever I want much faster.
| gmueckl wrote:
| Abstractions are only part of the whole issue. Maybe I
| focused too much on that. But I'll argue that point once
| more.
|
| How much complexity is actually required? What changed in
| software in the last 20 years so that the additional bloat
| and complexity is actually required? Hardware has become
| more powerful. This should make software less reliant on
| complicated optimizations and thus simpler. The opposite is
| happening. Why? What groundbreaking new features are we
| adding to software today that we didn't 20 years ago? User
| experience hasn't improved that much on average. In fact,
| measurements show that systems are responding more
| sluggishly on average.
|
| Intrinsic complexity of the problems that software can
| solve hasn't really changed much as far as I can see. We
| add towers of accidental complexity on top that mostly
| aren't helpful. Those need to be questioned constantly.
| That isn't happening to the extent that it should. Web-
| based stuff is the poster child of that culture and it's
| hugely detrimental.
| mfuzzey wrote:
| > What changed in software in the last 20 years
|
| Backends handling tens / hundreds of thousands or more of
| concurrent users rather than locally deployed software on
| a single machine or a small server with a few 10s of
| users?
|
| Mobile?
|
| Integration with other software / ecosystems?
|
| Real time colaboration amoung users rather than single
| user document based models?
|
| Security?
|
| Cryptography?
|
| Constant upgrades over the web rather than shipping CDs
| once a year?
|
| I'll pass on AI for the moment as it's probably a bit too
| recent.
| gopher_space wrote:
| It's not a personal value judgment, it's a debugging issue.
| tremendoussss wrote:
| I've been a backend engineer for about 10 years, with my last
| job doing an aws lambda stack.
|
| I started a job in manufacturing a few months ago and having
| to think that this has to work for the next 20 years has been
| a completely different challenge. I don't even trust npm to
| be able to survive that so web stuff has been been an extra
| challenge. I landed on lit web components and just bringing
| it in via a local CDN.
| dahart wrote:
| Agreed and well said. Furthermore, a lot of the statements in
| the post are making opposing tradeoffs when you put them
| together. A bunch of them value experimenting and breaking
| things, and a bunch of others value using what we already have
| and not breaking things.
|
| A few of them aren't decisions any individuals have control
| over. Most coders aren't jumping onto new languages and
| frameworks all the time; that's an emergent group behavior, a
| result of there being a very large and growing number of
| programmers. There's no reason to think it will ever change,
| nor that it's a bad thing. And regardless, there's no way to
| control it.
|
| There are multiple reasons people write software fast rather
| than high quality. Because it's a time/utility tradeoff, and
| time is valuable. It's just a fact that software quality
| sometimes does not matter. It may not matter when learning or
| doing research, it may not matter for solo projects, it may not
| matter for one-off results, and it may not matter when software
| errors have low or no consequence. Often it's a business
| decision, not an engineering decision; to a business, time
| really is money and the business wants engineering to maximize
| the utility/time ratio and not rabbit hole on the minutiae of
| craftsmanship that will not affect customers or sales.
|
| Sometimes quality matters and time is well spent. Sometimes
| individuals and businesses get it wrong. But not always.
| ryandrake wrote:
| I guess the rant should be renamed "business is destroying
| software" because several of the tradeoffs he mentions can be
| root caused to a commercial entity cutting corners and
| sacrificing everything on the altar of "developer time" in
| order to save money. Only a business would come up with the
| madness of "Move Fast And Break Things."
| zifpanachr23 wrote:
| These are all complaints specific to a particular attitude and
| kind of web software development that just happens to be most
| prevalent within a place like SV.
|
| I think the situation (loosely, wasting time spinning your wheels
| by modernizing things that are actually fine the way they are and
| may be made worse by adopting "hot new thing") looks worse when
| you see it through that lens than it actually is throughout the
| industry as a whole. There are plenty of opportunities for
| modernization and doing some of the things described in this
| article that actually make some sense when applied to appropriate
| situations.
|
| In other words, I totally understand the vibes of this post, it's
| one of the reasons I don't work in the parts of the industry
| where this attitude is most prevalent. I would never feel the
| push to write a post like it though because the poster is I think
| being a bit dramatic. At least that's the case looking at the
| industry from my (id argue broader) vantage point of being an
| expert in and working quite a bit with "legacy" companies and
| technologies that maybe could stand to have a new UI implemented
| and some tasteful modern conventions adopted at least as options
| for the end users.
| Syzygies wrote:
| Yes. There are better and worse ways to lead a team, just as
| there are better and worse ways to prompt AI.
|
| This post reads as a description of how the wheels come off the
| wagon if you don't do things well.
|
| With the evolution of AI agents, we'll all be virtual CTOs
| whether we like it or not, mastering scale whether we like it
| or not. We need to learn to do things well.
|
| Managerial genius will be the whole ball of wax.
| talles wrote:
| > We are destroying software mistaking it for a purely
| engineering discipline.
|
| This one packs a lot of wisdom.
| ks2048 wrote:
| This was one of the few that didn't resonate. What does it
| mean?
| mceachen wrote:
| If I had to guess, antirez was describing engineering
| managers and tech leads that have (mis)read "clean code" or
| similar works, and take them as commandments from on high
| rather than tools and approaches that may be helpful or
| applicable in some circumstances.
|
| Or, more generally, the fact that most of what the software
| industry produces is much more in line with "art" than
| "engineering" (especially when looked at from a Mechanical
| Engineer or Civil Engineer). We have so much implementation
| flexibility to achieve very similar results that it can be
| dizzying from the standpoint of other engineering fields.
| consider
| JanneVee wrote:
| In my view it is about design that requires taste and
| creativity. Engineering is about function, design is about
| form. If I build something that solves a problem but if it
| isn't well designed it can mean that no one actually uses
| even if it is good piece of engineering.
| ks2048 wrote:
| Yeah, I guess that's what he meant. In my mind, though,
| good "engineering" would also include good design,
| simplicity, etc.
| Doches wrote:
| I think the final point illustrates this one pretty
| succinctly: 'what will be left will no longer give us the joy
| of hacking.' Personally I build my own version of almost
| every software tool for which I regularly (like, daily) use a
| UI. So for e.g. personal note-taking, continuous integration,
| server orchestration, even for an IDE: I could use Apple
| Notes, CircleCI, Chef, VSCode, but I instead build my own
| versions of these.
|
| I'm not a masochist; they're often built on top of
| components, e.g. my IDE uses the Monaco editor. But working
| on these tools gives me a sense of ownership, and lets me
| hack them into exactly the thing I want rather than e.g. the
| thing that Microsoft's (talented! well-paid! numerous!)
| designers want me to use. Hacking on them brings me joy, and
| gives me a sense of ownership.
|
| Like an idealised traditional carpenter, I make (within
| reason) my own tools. Is this the most rational, engineering-
| minded approach? I mean, obviously not. But it brings me joy
| -- and it also helps me get shit done.
| petermcneeley wrote:
| It means you are an engineer.
| ahofmann wrote:
| While I highly respect antirez, I think this post is full of good
| sounding, short statements, that wouldn't hold in a discussion.
|
| One example: Newbies shouldn't reinvent the wheel. I think they
| should use the tools, that are available and common in the given
| context. When they want to tinker, they should write their own
| compiler. But they shouldn't use that in production.
|
| Another: Backward API compatibility is a business decision in
| most cases.
|
| Also, I think it doesn't help to start every sentence with "We
| are destroying software". This sounds much more gloomy, than it
| really is.
| antirez wrote:
| > When they want to tinker, they should write their own
| compiler. But they shouldn't use that in production.
|
| Why? We should stop saying others how they want to write/use
| their code ASAP.
|
| Many established technologies are a total shitstorm. If it is
| ok to use them, it is ok if somebody wants to use their own
| compiler.
| mukunda_johnson wrote:
| the shitstorms usually have a community behind it. Even if it
| sucks, it's supported and will be maintained to a point of it
| "working." If someone writes their own thing, chances are
| they won't go the extra mile and build a community for it.
| Then, when it comes to maintaining it later, it might grow
| untenable, especially if the original "tinkerer" has moved
| on.
| dpkonofa wrote:
| This would be great if things like open source were more
| supported in the "real" world. Unfortunately, you're
| describing exactly why a community means nothing in this
| situation unless the community is giving back to the
| project. When the "original tinkerer" moves on, everything
| depending on that project breaks when everything else
| changes around it.
| drawkbox wrote:
| These systems also came from tinkering. Most programming
| languages even are really the investment of one person for a
| long time, doing apparently what you aren't supposed to do.
|
| When it comes down to it, whatever works best and is usually
| the most simple, non-breaking, used to win out. That decision
| has been disconnected from the value creators to the value
| extractors. It is impossible to extract value before value is
| created.
|
| Additionally, programming is a creative skill no matter how
| hard they try to make it not one. Creativity means trying new
| things and new takes on things. People not doing that will
| harm us long term.
| dahart wrote:
| >> But they shouldn't use that in production. > Why?
|
| Generally speaking, because that's very likely to end up
| being "pushing for rewrites of things that work", and also a
| case of not "taking complexity into account when adding
| features", and perhaps in some cases "jumping on a new
| language", too.
|
| This is an imagined scenario, but the likelihood of someone
| easily replacing a working compiler in production with
| something better is pretty low, especially if they're not a
| compiler engineer. I've watched compiler engineers replace
| compilers in production and it takes years to get the new one
| to parity. One person tinkering and _learning_ how to write a
| compiler almost for sure does not belong in production.
| vdupras wrote:
| "parity" is the keyword here. Most of the time, the problem
| doesn't come from sloppy execution, but ever widening scope
| of the software.
|
| For example, my own "Almost C" compiler[1] is 1137 lines of
| code. 1137! Can it ever reach "parity" with gcc or even
| tcc? No! That's specifically not the goal.
|
| Do I benefit strongly for having a otherworldly simpler
| toolchain? hell yeah.
|
| The key is scope, as always. Established projects have, by
| virtue of being community projects, too wide a scope.
|
| [1]: https://git.sr.ht/~vdupras/duskos/tree/master/item/fs/
| doc/co...
| dahart wrote:
| Agreed, parity is a strong constraint. Since the premise
| under discussion was "production" environments where some
| kind of parity is presumably required, I think it's a
| reasonable assumption. If there is no baseline and it's
| not a production situation where parity is needed, then
| yeah scope can and should be constrained as much as
| possible. I like the phrase "otherworldly simple", I
| might borrow that!
| Ygg2 wrote:
| > Why?
|
| Those who do not know history are doomed to repeat it. Or re-
| re-reinvent Lisp.
|
| There was this anecdote about storm lamp or something. New
| recruit comes to a camp and sees old guard lighting lamps are
| turned upside down and lit sideways with a long stick. But he
| knows better, he tells them and they smirk. First day he
| lights them the optimal way with a lighter. He's feeling
| super smug.
|
| But next day he finds the fuse is too short to reach so he
| takes the long stick...
|
| Few months later, he's a veteran, he's turning lamp upside
| down using lighter sideways, with a long stick.
|
| And the fresh recruit says he can do it better. And the now
| old guard smirks.
|
| I'm sure I'm misremembering parts, but can't find the
| original for the life of me.
| ahofmann wrote:
| > Why?
|
| If someone would hand me a project, that is full of self
| invented stuff, for example a PHP project, that invented its
| own templating or has it's own ORM, I would run. There is
| laravel, slim or symfony, those are well established and it
| makes sense to use them. There are so much resources around
| those frameworks, people who posted about useful things, or
| packages, that add functionality to those. It just doesn't
| make sense to reinvent the wheel for web frameworks and
| thousands of packages around those.
|
| Writing software is standing on the shoulders of giants. We
| should embrace that, and yes one should learn the basics, the
| underlying mechanisms. But one should make a difference
| between tinkering around and writing software, that will be
| in production for years and therefore worked on by different
| developers.
|
| The JavaScript world shows how to not do things. Every two
| years I have to learn the new way of building my stuff. It is
| annoying and a massive waste of resources. Everyone is always
| reinventing the wheel and it is exhausting. I understand why
| it is like this, but we as developers could have made it less
| painful, if we would embrace existing code instead of wanting
| to write our own.
| bayindirh wrote:
| > Newbies shouldn't reinvent the wheel.
|
| I strongly disagree. They should, and fail and try again and
| fail. The aim is not to reinvent the wheel, but to understand
| why the wheel they're trying to reinvent is so complex and why
| the way it is. This is how I learnt to understand and
| appreciate the machine, and gave me great insight.
|
| Maybe not in production at first, but they don't reinvent the
| wheel in their spare time either. They cobble up 200 package
| dependency chains to make something simple, because that's what
| they see and taught. I can write what many people write with 10
| libraries by just using the standard library. My code will
| become a bit longer, but not much. It'll be faster, more
| robust, easier to build, smaller, and overall better.
|
| I can do this because I know how to invent the wheel when
| necessary. They should, too.
|
| > Another: Backward API compatibility is a business decision in
| most cases.
|
| Yes, business decision of time and money. When everybody says
| that you're losing money and time by providing better service,
| and lower quality is OK, management will jump on it, because,
| monies.
|
| > Also, I think it doesn't help to start every sentence with
| "We are destroying software". This sounds much more gloomy,
| than it really is.
|
| I think Antirez is spot on. We're _destroying_ software.
| Converting it to something muddy and something for the ends of
| business, and just for it.
|
| I'm all with Antirez here. Software came here, because we
| developed the software just for the sake of it, and evolved it
| to production ready where needed. Not the other way around
| (Case in point: Linux).
| ryandrake wrote:
| > Yes, business decision of time and money. When everybody
| says that you're losing money and time by providing better
| service, and lower quality is OK, management will jump on it,
| because, monies.
|
| Often that "saving money" is just externalizing the cost onto
| your users. Especially in mobile development. Instead of
| putting in the tiny amount of effort it takes to continue
| support for older devices, developers just increase the
| minimum required OS version, telling users with older
| hardware to fuck off or buy a new phone.
|
| Another example is when you don't take the time to properly
| optimize your code, you're offloading that cost onto the user
| in the form of unnecessarily higher system requirements.
| bayindirh wrote:
| True. There's no free lunch. Either developer pays it once
| and have happier users, or users pay it everyday and have
| inferior experience.
|
| This is why I believe slow cooked software. Works better,
| easier on the system, and everyone is happier.
| dasil003 wrote:
| > _I 'm all with Antirez here. Software came here, because we
| developed the software just for the sake of it, and evolved
| it to production ready where needed. Not the other way around
| (Case in point: Linux)._
|
| Growing up in the 80s and 90s I understand viscerally how you
| feel, but this take strikes me as willfully ignorant of the
| history of computers, and the capitalist incentives that were
| necessary for their creation. The first computer and the
| internet itself were funded by the military. The PC wouldn't
| have existed if mainframes hadn't proved the business value
| in order to drive costs down to the point the PC was viable.
| Even the foundational ideas that led to computers couldn't
| exist with funding--Charles Babbage's father was a London
| banker.
|
| I think a lot of what you are reacting to is the failed
| promise of free software and the rise of the internet, when
| the culture was still heavily rooted in 60s counter-culture,
| but it hadn't crossed the chasm to being mainstream, so it
| was still possible to envision a utopian future based on the
| best hopes of a young, humanitarian core of early software
| pioneers operating largely from the sheltered space of
| academia.
|
| Of course no such utopian visions ever survive contact with
| reality. Once the internet was a thing everyone had in their
| pocket, it was inevitable that software would bend to
| capitalist forces in ways that directly oppose the vision of
| the early creators. As evil as we thought Microsoft was in
| the early 90s, in retrospect this was the calm before the
| storm for the worst effects of tech. I hear Oppenheimer also
| had some regrets about his work. On the plus side though, I
| am happy that I can earn enough of a living working with
| computers that I have time to ponder these larger questions,
| and perhaps use a bit of my spare time to contribute
| something of worth back to the world. Complaining about the
| big picture of software is a fruitless and frustrating
| endeavour, instead I am interested in how we can use our
| expertise and experience to support those ideals that we
| still believe in.
| trinsic2 wrote:
| I think what he is trying to say is that the value or focus
| was better when it was placed on the endeavors, not the
| means behind the endeavors. I don't think anything has to
| be inevitable. What matters is what we decide to do when
| challenges like these present themselves and how can we
| have more of a positive impact on the world when things go
| awry.
|
| I take issue with your use of the word "utopian" being used
| in this context. Its not a lost cause to see the world from
| the perspective of making the world better, by finding our
| way though this with a better mindset on the future.
|
| And while you are taking the time to ponder these questions
| because you earn enough to take the time, the world is
| burning around you. Sorry if my tone is harsh, but these
| kinds of statements really rub me the wrong way. It feels
| like you are saying everything that is happening is how its
| suppose to be and I am strongly against that. We have
| enough of that perspective, we really don't need it, IMHO.
| dasil003 wrote:
| Fair criticism, but saying "we are destroying software"
| is not actionable. I want us to do better, but I also
| want to be effective, and not just sit around impotently
| wringing our hands about how bad everything is.
| trinsic2 wrote:
| Fair point. I agree with you. Some times it just takes
| one person to say whats wrong with the world, to make
| people realize something can/has to be changed.
| bayindirh wrote:
| I'll kindly disagree. For me, seeing or accepting where
| we are currently is enough to gently motivate me to do
| whatever I can do to change the current state.
|
| This gentle motivation is good, because it allows me to
| look inside and be rational about my ambitions. I won't
| go to a blind crusade, but try to change myself for the
| better.
|
| Because, I believe in changing myself to see that change
| in the world.
| JKCalhoun wrote:
| > Another: Backward API compatibility is a business decision in
| most cases.
|
| Agree. That statement/sentiment though doesn't refute the point
| that it's destroying software.
| layer8 wrote:
| I actually don't agree. Maintaining or not maintaining
| backwards compatibility is often a decision made on the
| technical level, e.g. by a tech lead, or at least heavily
| based on the advice from technical people, who tend to prefer
| not being restricted by backwards compatibility over not
| breaking things for relying parties.
| remoquete wrote:
| To the list I'd add:
|
| We're destroying software when we think documentation does not
| matter.
| antirez wrote:
| Well put. And even when we think that writing doc is a less
| important thing.
| JKCalhoun wrote:
| There was the point about "comments" not mattering.
| remoquete wrote:
| Comments are just one bit of the docs.
| contingencies wrote:
| Came to post the same.
|
| I was going to phrase it: _We are destroying software by
| neglecting to documenting it and its design decisions._
| recursivedoubts wrote:
| lisan al gaib!
| nthingtohide wrote:
| This reminds me of Jonathan Blow's talk. Software decays just
| like everything else if we don't tend to it.
|
| Preventing the Collapse of Civilization / Jonathan Blow (Thekla,
| Inc)
|
| https://www.youtube.com/watch?v=ZSRHeXYDLko
|
| Software technology is in decline despite appearances of
| progress. While hardware improvements and machine learning create
| an illusion of advancement, software's fundamental robustness and
| reliability are deteriorating. Modern software development has
| become unnecessarily complex, with excessive abstraction layers
| making simple tasks difficult. This complexity reduces programmer
| productivity and hinders knowledge transfer between generations.
| Society has grown to accept buggy, unreliable software as normal.
| Unless active steps are taken to simplify software systems across
| all levels, from operating systems to development tools,
| civilization faces the risk of significant technological
| regression similar to historical collapses.
| _hao wrote:
| I think that talk might be Jonathan Blow's most important work
| to date actually. I love The Braid and The Witness, but
| "Preventing the Collapse of Civilization" managed to articulate
| what at least me and my circle of devs have talked about and
| discussed for long time, but were never quite able to put into
| words. I'm very grateful for people like him and others like
| Casey Muratori, Mike Acton etc. who continue to point this out
| very real danger in the (at least) last decade.
|
| Unfortunately my stance is that fundamentally things won't
| change until we get hit with some actual hardware limitations
| again. Most devs and people in general prefer a semblance of a
| working solution quickly for short-term gains rather than
| spending the actual time that's needed to create something of
| high quality that performs well and will work for the next 30
| years. It's quite a sad state of affairs.
|
| With that said I'm generally optimistic. There is a small niche
| community of people that does actually care about these things.
| Probably won't take over the world, but the light of wisdom
| won't be lost!
| bathtub365 wrote:
| Oftentimes there isn't a need for something to work for the
| next 30 years as the business will change in a much shorter
| timeframe and software exists to serve the business. While I
| agree that software quality varies wildly if the business
| can't get off, the ground because the software isn't ready,
| the software team will quickly stop existing with the rest of
| the business.
| 1dom wrote:
| The way I interpret the decline of software is that part of
| the problem is because more software has been written with
| the mentality that it doesn't need to last 30 years.
|
| It's a self-perpetuating issue: people build stuff saying
| "it won't/can't last 30 years" for various reasons (money,
| time, skill, resources, expectations, company culture,
| business landscape etc). So then software doesn't last 30
| years for those same various reasons.
|
| The idea that we think systems did used to last longer is
| probably some survivor bias. However, software that has
| survived decades was probably created with a completely
| different set of methodologies, resources and incentives to
| modern software.
| eastbound wrote:
| Linux and Java has survived since 1995-1998, which is the
| dusk of times.
|
| We swap JS frameworks constantly, but when we'll reach a
| good paradigm, we'll stick with it. At one point, React
| might be the final framework, or rather, one of its
| descendants.
| renewedrebecca wrote:
| Or just throw modern web app development with its insane
| ways of trying to work around the fast that JS is a
| broken paradigm and start over.
|
| Develop a good vm that can either be part of the browser
| or can be easily launched from it and get all of the
| browser/OS makers on the same page.
|
| We only have what we have because of a lack of real
| leadership.
| maccard wrote:
| If history had taught us anything in computing it's that
| breaking backwards compatibility/rewriting it isn't the
| panacea. See Perl, python, C++, longhorn, mosaic for
| example. My 4k, 120hz monitor with 32 bit color depth and
| 16 4.5GHz cpu cores attached to it still renders a
| terminal at 80 characters wide and chokes on cat
| bigfile.bin because we're that married to not changing
| things.
| karmakaze wrote:
| There are many large companies running Cobol programs in
| production that wished software didn't last 30 years.
| MonkeyClub wrote:
| Their prospective replacements didn't last the rewrite,
| though.
| asmor wrote:
| That is untrue for almost all software written outside of
| companies who's primary product is tech or software. I work
| for a publisher and while there's a ton of disposable
| microsites and project work (that nobody ever cleans up or
| documents, so you never know if it's okay to remove),
| there's also ancient monoliths written in forgotten
| programming languages that are so important for production
| and have so many hidden dependencies and unknown users
| ("random FTP server" being my favorite), that you can
| barely put on new paint.
|
| I'm writing software with the assumption that it'll be used
| for at _least_ 30 years there, with a lot of guard rails
| and transparency /observability mechanisms, because I know
| the next person working there will thank me.
| dijit wrote:
| I don't mind this philosophy, but in aggregate I think very
| slow applications that are cumbersome and widely deployed
| have cost humanity many human lifetimes because a handful
| of developers were not able (or not given the opportunity)
| to optimise them even a little.
|
| I am aware that capitalism essentially dictates
| externalising cost as much as possible, but with software-
| much for the same reason capitalism loves it (a copy is
| cheap and can be sold at full price despite being
| constructed just once) means that these externalities can
| scale exponentially.
|
| Teams in particular is an outlier as in most cases it is
| essentially forced on people.
| dinkumthinkum wrote:
| It's interesting that all three of the people you mention are
| very concerned with performance, something most programmers
| don't even think about anymore or think they aren't supposed
| to.
| FridgeSeal wrote:
| As a group, we have trained many, many programmers out of
| even considering performance with the proliferation of
| quotes like "premature optimisation is the root of all
| evil" ands ideas like "who cares, just get a faster
| computer/wait for hardware".
|
| Premature optimisation is bad, but there's now so many devs
| who don't do _any _ at all. They don't improve any existing
| code, they're not writing software that is amenable to
| later optimisation, inefficient architectures and
| unnecessary busywork abounds.
|
| Are we surprised that years of "product first, bug fixes
| later, performance almost never" has left us with an
| ecosystem that is a disaster?
| anymouse123456 wrote:
| As someone who used to quote this quote, I've come to
| believe this one line has caused nearly as much damage as
| the invention of NULL.
| _hao wrote:
| Yes, people think that writing performant software is
| something that's nice-to-have when in fact if you program
| with the intention of things being performant then that
| branches out to better overall design, better user
| experience, better quality etc. It means you actually care
| about what you're doing. Most people don't care and the
| results are apparent. We're surrounded by waste everywhere.
| Bad software wastes resources like money, electricity and
| most importantly - time.
|
| The fact that people don't stay long enough in companies or
| work on a long project themselves to see the fruits of
| their labour down the line is a point that is discussed in
| some of the other comments here in this thread. I agree
| with it as well. In general if you job hop a lot you won't
| see the after effects of your actions. And the industry is
| such that if you want to get paid, you need to move. To
| reiterate - it's a sad state of affairs.
| thefz wrote:
| I can't take Blow seriously after his meltdown on how difficult
| it is to test games on different OSes while some developers
| already released on multiple platforms... all in a one man's
| band (i.e. https://www.executionunit.com/blog/2019/01/02/how-i-
| support-...).
|
| Aside, he's treated like a celebrity in the game developer
| niche and I can't understand why.
| jhatemyjob wrote:
| Look up Indie Game: The Movie
| thefz wrote:
| Is that the documentary in which Phil Fish has a part on
| FEZ?
| efnx wrote:
| Yes. There's also Indy game 2, which is ok.
| JasserInicide wrote:
| He has some good takes (like the talk he gave in the OP) but
| also has some questionable ones. How he feels on work-life
| balance comes to mind. He seems to legitimately hate having
| to employ other people to help create his games.
| ryandrake wrote:
| Link to the meltdown? I could use a good chuckle this
| morning.
| the_mitsuhiko wrote:
| It can be difficult and at the same time be possible. Clearly
| he also released his games on multiple platforms. Braid I
| think was everywhere from Xbox 360, Windows, Mac, Linux,
| Switch and mobile phones.
| cableshaft wrote:
| Just because one person is willing to do everything needed to
| test on all platforms doesn't mean everyone should therefore
| be willing to put the time and effort into it.
|
| Depending on what tech you use it can be easier or harder to
| do as well. I'm making a game with Love2D now, which has made
| supporting Mac and Linux rather trivial so far, although I've
| run into challenges with mobile platforms and the web even
| though it support them (it does work, but it takes more low-
| level glue code to support native phone features, and the web
| doesn't seem to be well maintained and my game is throwing
| webassembly errors currently when I try to run it).
|
| And my previous game (which is on the backburner for now) was
| made with Monogame, and while that technically has support
| for Mac and Linux (as well as mobile), I've had quite a few
| issues even just getting the Mac version working well, like
| issues with resolution, rendering 3D properly, getting
| shaders not to break, etc. And they haven't kept up with the
| latest Mac updates the past few years and have had to make a
| special push to try to get it caught back up. I've probably
| sunk a good 20+ hours trying to get it working well before
| putting that aside to work on the actual game again and I
| still might have to rearchitect things a bunch in order to
| get that working.
|
| Meanwhile Unity would probably be pretty dirt simple to port,
| for the most part, but it comes with other tradeoffs, like
| not being open source, and trying to pull a stunt a couple
| years ago where they pulled the rug out from under developers
| with changing licensing to something aggressive (that
| convinced other developers to port their games away from the
| platform), etc.
|
| And there's Godot, which seems to be getting more support
| again (which is great, I even considered it or my current
| game, I just like coding in Love2D a bit better), but if you
| ever want your game on consoles you have to pay a third party
| to port your games to consoles for you.
|
| The guy you linked makes their own engine (and to be fair, so
| does Jonathan Blow, who you're critiquing), which is great,
| but not everyone wants to get that low level. I would rather
| spend more time focusing on building the games themselves,
| which is already hard enough, rather than spending all that
| time building an engine.
|
| It was for that reason that I spent several years focused on
| board game design instead (as I can make a working game with
| drawing on index cards and some colored plastic cubes in less
| than an hour), although that has its own frustrations with
| significant hurdles to get your game signed by publishers as
| an unknown designer (I did get one signed four years ago, and
| it's still not released yet), and large financial risks being
| made for manufacturing and distribution.
|
| Edit: Also the person you linked to isn't even sure it was
| financially worth it to support all of those platforms, they
| just do it for other reasons:
|
| "Do you make your money back? It's hard to say definitely
| which could mean no. Linux and macOS sales are low so the
| direct rewards are also low. ...For Smith and Winston [their
| current game] right now I don't think it's been worth it
| financially (but it will probably make it's money back on
| Launch)"
| williamcotton wrote:
| There are maintenance costs and then there is
| depreciation/amortization.
| alabhyajindal wrote:
| All Jonathan Blow talks, or rants more accurately, are the
| same. He personifies _old man yells at cloud_.
| washadjeffmad wrote:
| That's a feature. Permanent systemization of short term
| worldviews and lenses is pretty horrifying. That's how those
| techno-theocratic civilizations in pop culture happen.
|
| Imagine if a company had been able to systemize the whims of a
| paranoid regime, allowing them to track and spy on their
| citizens with impunity in secret, and the population became so
| inured to the idea that it became an accepted facet of their
| culture.
|
| Or what if a political party dominated a state and systematized
| a way to identify and detect oppositional thought, stamping it
| out before a counterculture could ever arise. Maybe that
| thought was tied to a particular religious, ethnic, and/or
| cultural group.
|
| What if these companies are here today, selling those products
| to the highest (nation-state) bidders, and the methods they're
| employing to keep the conceptual wheels turning at scale rely
| on filtering that selects for candidates who will gladly jump
| through abstract hoops set before them, concerned only with the
| how and never the why of what they're doing.
| jack_h wrote:
| > Software technology is in decline despite appearances of
| progress. While hardware improvements and machine learning
| create an illusion of advancement, software's fundamental
| robustness and reliability are deteriorating. Modern software
| development has become unnecessarily complex, with excessive
| abstraction layers making simple tasks difficult. This
| complexity reduces programmer productivity and hinders
| knowledge transfer between generations. Society has grown to
| accept buggy, unreliable software as normal. Unless active
| steps are taken to simplify software systems across all levels,
| from operating systems to development tools, civilization faces
| the risk of significant technological regression similar to
| historical collapses.
|
| I haven't watched that talk by Blow yet so maybe he covers my
| concern.
|
| I think you have to be mindful of incentives structures and
| constraints. There's a reason the industry went down the path
| that it did and if you don't address that directly you are
| doomed to failure. Consumers want more features, the business
| demands more stuff to increase its customer base, and the
| software developers are stuck attempting to meet demand.
|
| On one hand you can invent everything yourself and do away with
| abstractions. Since I'm in the embedded space I know what this
| looks like. It is very "productive" in the sense that
| developers are slinging a lot of code. It isn't maintainable
| though and eventually it becomes a huge problem. First no one
| has enough knowledge to really implement everything to the
| point of it being robust and bug free. This goes against
| specialization. How many mechanical engineers are designing
| their own custom molding machine in order to make parts?
| Basically none, they all use mold houses. How many electrical
| engineers are designing their own custom PCB(A) processing
| machines or ICs/components? Again, basically none. It is
| financially impossible. Only in software I regularly see this
| sentiment. Granted these aren't perfect 1-to-1 analogies but
| hopefully it gets the idea across. On the other hand you can go
| down the route of abstractions. This is really what market
| forces have incentivized. This also has plenty of issues which
| are being discussed here.
|
| One thought that I've had, admittedly not fully considered, is
| that perhaps F/OSS is acting negatively on software in general.
| When it comes to other engineering disciplines there is a cost
| associated with what they do. You pay someone to make the
| molds, the parts from the molds, etc... It's also generally
| quite expensive. With software the upfront cost to adopting yet
| another open source library is zero to the business. That is
| there is no effective feedback mechanism of if we adopt X we
| need to pay $Y. Like I said, I haven't fully thought through
| this but if the cost of software is artificially low that would
| seem to indicate the business and by extensions customers don't
| see the true cost and are themselves incentivized to ask for
| more at an artificially low price thus leading to issues we are
| currently seeing. Now don't misread me, I love open source
| software and have nothing but respect for their developers;
| I've even committed to my fair share of open source projects.
| As I've learned more about economics I've been trying to view
| this through the lens of resource allocation though and it has
| lead me to this thought.
| MonkeyClub wrote:
| > Consumers want more features
|
| I no longer think that's true. Instead, I think consumers
| want reliability, but more features is a way to justify
| subscription pricing segregation and increases.
| paulryanrogers wrote:
| Everyone has a different a tipping point. But generally I
| see folks want more features and don't value reliability
| unless it's something they use really often and has no
| workaround.
|
| I play games with known bugs, and on imperfect hardware,
| because I unwilling to pay more. Some experiences are rare,
| so I tolerate some jank because there aren't enough
| competitors.
| paulryanrogers wrote:
| Adopting libraries and 3P solutions is like jumping in the
| pool, easy to do. Getting out of the pool is much harder. Or
| in some cases like jumping into quick sand. Sometimes it can
| be hard to tell which before you're in it.
| nradov wrote:
| Most large enterprise IT departments are fully aware that the
| cost of adopting yet another open source library is very high
| even if the price is zero. This cost comes in the form of
| developer training, dependency management, security breaches,
| patent troll lawsuits, etc. There is a whole niche industry
| of tools to help those organizations manage their open source
| bill of materials.
| FridgeSeal wrote:
| > Consumers want more features
|
| I'm not even sure if this is true anymore. We got new
| features foisted on us most of the time.
| gijoeyguerra wrote:
| Not I.
| kibwen wrote:
| The older I get the less stock I put in merely pointing out flaws
| without offering solutions.
|
| You might say "I don't need to be able to propose a solution in
| order to point out problems", and sure, but that's missing the
| point. Because by pointing out a problem, you are still
| implicitly asserting that _some_ solution exists. And the counter
| to that is: no, no solution exists, and if you have no evidence
| in favor of your assertion that a solution exists, then I am
| allowed to counter with exactly as much evidence asserting that
| no solution exists.
|
| Propose a solution if you want complaints to be taken seriously.
| More people pointing out the problems at this point contributes
| nothing; we all know everything is shit, what are you proposing
| we do about it?
| JKCalhoun wrote:
| My rather broad solution has always been: let engineers own a
| part of a stack. Let an engineer own the UI for an app, own the
| database front-end. Let an engineer own the caching mechanism,
| let an engineer own the framework.
|
| You give an engineer ownership and let them learn from their
| own mistakes, rise to the occasion when the stakes are high.
| This presumes they will have the last word on changes to that
| sand box that they own. If they want to rewrite it -- that's
| their call. I'm the end they'll create a codebase they're happy
| to maintain and we will all win.
|
| (And I think they'll be a happier engineer too.)
| asadotzler wrote:
| Defining or clarifying the specifics of the problem is a
| critical step in solving (or not solving) it. We don't have a
| good understanding of all of the factors and how they
| contribute to this problem so having more people take a stab at
| understanding the problem and sharing that is a net positive.
| You may think that "we all know it already" but we don't. I
| discover new and meaningful ways that systems and people are
| fucking up software just about every year and have been for
| 25-30 years so I take strong issue with your "we all know" when
| clearly we don't, and in fact very much still disagree on the
| details of that problem, the very things we need to understand
| in order to best solve the problem.
| Hizonner wrote:
| > Because by pointing out a problem, you are still implicitly
| asserting that some solution exists.
|
| Um, no you're not.
|
| > And the counter to that is: no, no solution exists,
|
| If that's the case, it's probably helpful to know it.
|
| > we all know everything is shit, what are you proposing we do
| about it?
|
| Give up on whatever doomed goal you were trying to reach,
| instead of continuing to waste time on it?
| lupusreal wrote:
| > _by pointing out a problem, you are still implicitly
| asserting that some solution exists_
|
| Weird take.
| snowstormsun wrote:
| We are destroying software by letting non-technical people make
| technical decisions.
| neilv wrote:
| We are destroying software with Leetcode interviews, resume-
| driven development, frequent job-hopping, growth investment
| scams, metrics gaming, promotion-seeking, sprint theatre,
| bullshitting at every level of the org chart, and industry
| indifference.
| onemoresoop wrote:
| You forgot move fast break things
| begueradj wrote:
| I add AI to that list
| shove wrote:
| It's honestly a huge tell that it was omitted
| simonw wrote:
| What does it tell you?
| unification_fan wrote:
| Literally all of that is because capitalism incentivizes short-
| term profit over meaningful, society-benefiting work.
|
| FOSS doesn't have these problems.
| bawolff wrote:
| I feel like resume-driven development is certainly a thing
| that happens in FOSS.
| Ekaros wrote:
| Just how many FOSS projects there are that are dead? Just how
| many different ways to do things have been invented? Say
| Linux desktop environments. Or parts of subsystems.
|
| FOSS is certainly guilty too.
| unification_fan wrote:
| Fair, but then again FOSS is born from individual hackers
| who want to learn how to build X, or who feel like the
| ecosystem doesn't provide the X they would like to have.
|
| It fosters a culture where everyone can hack something
| together, and where everyone is knowledgeable enough to
| make responsible use of technology.
|
| Working as a for-hire developer doesn't let you experience
| all of that because you're building a _product_ that
| _someone else wants you to build_. No wonder one does not
| give a shit about writing good software at that point! You
| 've taken all the fun and personal fulfillment out of it!
|
| We can build anything we put our mind to -- but most of us
| are too busy churning out CRUD boilerplate like factory
| workers. That's depressing.
| _Algernon_ wrote:
| How is FOSS guilty of the same? The code is there free for
| you to take, modify and fix, even if the project is
| otherwise abandoned.
| fullstackwife wrote:
| Computer programs are like sausages. It's better not to see
| them being made.
| swat535 wrote:
| Except at least sausages are enjoyable to consume, unlike
| today's software.. unfortunately, it fails on all fronts.
| vosper wrote:
| I've enjoyed a great many of the games I've played lately
| :)
| dqft wrote:
| If you did then you would know all the tricks to Stephen's
| rare and beautiful thing.
| proc0 wrote:
| And rewarding engineers for "impact" rather than correct,
| reliable, and extensible software.
| efnx wrote:
| Why is it that leadership gets these ideas all at the same
| time?
| esafak wrote:
| They copy the leader. Word spreads instantly on the
| Internet.
| dasil003 wrote:
| Because the software we are paid to write has an external
| purpose. As scale increases, supply chains lengthen, and
| roles specialize, inevitably more and more people are
| missing the forest for the trees--this isn't an indictment,
| it's an inevitable result of the pursuit of efficiency and
| scale at all costs. Many engineers would be happy to polish
| the thing that exists, perhaps adding complexity the form
| of scalability, modularity or reusability that isn't
| actually needed, and in fact may make it harder to adapt to
| broader changes in the ecosystem that the company operates
| in. "Impact" is just a suitably hand-wavy management
| buzzword to be used in lots of different situations where
| they deem ICs to not sufficiently taking the big picture
| into account.
| proc0 wrote:
| > Many engineers would be happy to polish the thing that
| exists, perhaps adding complexity the form of
| scalability, modularity or reusability that isn't
| actually needed, and in fact may make it harder to adapt
| to broader changes in the ecosystem that the company
| operates in
|
| When done correctly it absolutely adds business value and
| should not make it harder to adapt or change, that's the
| point of good engineering. The problem is that you need
| years, if not decades, of technical experience to see
| this, and it's also a hard sell when there is no
| immediate "impact". It's basically something that happens
| because consumers don't know any better, so then it
| becomes low priority for making profit... at least until
| a competitor shows up that has better software and then
| it has a competitive edge, but that's a different matter.
| dasil003 wrote:
| Sure. I'm just explaining why the term exists. Of course
| it is often applied by clueless managers, there's nothing
| you can do about that except go find a better manager.
| Just don't make the mistake of thinking its all bullshit
| because you've only dealt with muppets on the leadership
| side--I see this often with journeyman engineers who have
| never had the privilege of a good management team and
| it's very sad.
| Henchman21 wrote:
| Because they're all in the same tiny social circle and went
| to the same schools, joined the same clubs, intermarried,
| and just generally isolate themselves from the rest of us.
|
| Its called "being out of touch" I believe
| _dark_matter_ wrote:
| If you don't want to have any say in the work that you're
| doing, then sure don't judge based in impact. I'd rather have
| the responsibility and trust of letting me decide what to
| work on, rather than management tell me. The only way that
| works is that my judgement is good, I deliver impact, and I'm
| paid as such.
| esafak wrote:
| You are optimizing for your resume and pay, not the
| product's needs. That's what people are criticizing; what
| constitutes impact, how it is measured, and whether that's
| what's needed to make the product better.
| proc0 wrote:
| There is implicit impact by engineering good systems and
| software. It's like hiring a plumber and telling them "you
| need to improve my house" rather than "you need to improve
| the plumbing in my house". When your objective as an
| engineer is so broad that you need to worry about customers
| and the product, then the engineering itself suffers...
| that said it might not suffer to the extent that it matters
| but that is the point here.
|
| Bad software keeps happening because businesses can afford
| it, as well as hardware improvements. It's a combination of
| consumers not knowing what they are missing and hardware
| advancements allowing for bad software to exist.
| scarface_74 wrote:
| > _When your objective as an engineer is so broad that
| you need to worry about customers and the product, then
| the engineering itself suffers... that said it might not
| suffer to the extent that it matters but that is the
| point here_
|
| If you aren't writing software with the customer and
| business in mind, why are you doing it? That's what you
| are getting paid for.
| moandcompany wrote:
| Rewarding "engineers" for perceived "impact" :)
| ldigas wrote:
| I wonder in comparison what had more impact, a software
| made in the 80s still used today, or an app that will be
| replaced in a year, with an added note of "I don't know why
| I'm using it at all".
| phendrenad2 wrote:
| The users often feel the "impact" like a punch in the gut, as
| their perfectly-fine software has now grown a useless AI
| appendage, or popup ads for an upsell to the next pricing
| tier. But hey, got the promotion!
| leptons wrote:
| You get rewarded?
| proc0 wrote:
| Yes with promotions, bonuses and overall good reviews,
| which are only marginally based on technical achievements
| (when it should be absolutely based on that).
| leptons wrote:
| That sounds amazing. I haven't spoken to my boss in about
| 2 years, haven't had a raise in over 4 years. I guess my
| reward is that I still have a job?
| ajmurmann wrote:
| Sounds like an incredibly incompetent manager
| proc0 wrote:
| Yes, that's part of the reward, but normally you get
| raises, bonuses, etc. based on yearly or quarterly
| reviews. If you are not entry level, and you just focus
| on programming while getting a good pay, and you are not
| seen as underperforming, consider yourself lucky.
| dahart wrote:
| If you want a raise or promotion, you should talk to your
| boss or otherwise figure out how to remind them regularly
| of your value. Ask them for a quarterly or monthly one-
| on-one, and take an interest in what they do and what the
| team priorities are. I don't know about your boss,
| they're not all the same, but managers tend to like see
| initiative, engineers who make other engineers more
| productive, and engineers who have and spread an
| optimistic attitude. Promotions are about taking greater
| responsibility.
|
| An alternative but dangerous approach is to make it known
| you're looking elsewhere for work. Don't do that if it's
| relatively easy to replace you, and definitely assume the
| management thinks it's easy to replace you, _especialy_
| if you haven't been talking to your boss. ;) But there is
| the chance that they know you're valuable and haven't
| given you a raise because you seem content and they
| believe they have the upper hand - which may or may not
| be true.
| scarface_74 wrote:
| If you haven't gotten a raise in four years and inflation
| has been up 21%, your pay is actually decreasing
| scarface_74 wrote:
| Technical achievements that are not in line with business
| objectives are worthless
| scarface_74 wrote:
| A company exists to make money. If you can't describe how
| your work either makes the company money or saves the company
| money? Why should they care?
| chocolatkey wrote:
| What is wrong with frequent changing of jobs? It's one of the
| easiest tools for increasing my compensation. The job market
| ideally should be so flexible you can switch to another company
| any time you want, no noncompetes.
| sfpotter wrote:
| Can't have stewardship without institutional knowledge and
| long-term employment.
| Ekaros wrote:
| That is the problem. That job-hopping is only way to get
| better compensation. The history, the domain knowledge and
| accountability is lost when one who made a programming
| decision is gone.
|
| Why care about quality or maintainability if you are gone in
| year or two anyway...
| bbor wrote:
| You've hit the nail on the head -- the problem is systemic,
| not the implied sudden lack of virtue. People job hob in
| our industry b/c even the giants with _hundreds_ of
| billions in the bank are caught up in absurd quarter-by-
| quarter performances for their shareholders, which sets the
| direction of the whole industry.
| trinsic2 wrote:
| Exactly. On the level the parent is describing, having
| options is a good thing, but the side-effect of this
| systemic problem is that it fragments our ability to
| write good software because the process is not about
| developing good software, its about to profit. Which
| enshitifies the endeavor, devaluing the quality of the
| end result.. Slowly, over time, this enshifitication is
| going to, or already is causing problems in our
| technological infrastructure and maybe other areas of
| society.
| wrs wrote:
| The topic is "we're destroying software", not "we're
| destroying techniques to increase your compensation".
| Individual compensation and collective quality are not
| somehow inherently correlated.
| bluedino wrote:
| I guess you could argue something along the lines of people
| never staying long enough to build complex things from start
| to finish. New people moving in and working on the project
| without the proper understanding, not caring since it will be
| someone else's problem in a few months...
| omgbear wrote:
| It's harder to learn the impact of your design decisions --
| Seeing how software evolves to meet changing business goals
| and how the design choices made play out in the long run
| helped teach me a lot.
|
| Coming up with a neat API that turns out to be difficult to
| modify in the future, or limiting in ways you didn't imagine
| would when writing it is a good learning experience.
|
| Or seeing how long a system can survive growing usage --
| Maybe a simple hack works better than anyone expected because
| you can just pay more for RAM/CPU each year rather than
| rebuild into a distributed fashion. Or the opposite, maybe
| there's some scaling factor or threshold you didn't know
| existed and system performance craters earlier than
| predicted.
| davidw wrote:
| I don't get the downvotes. This is a rational point of view
| for an individual. The problem is higher up, where the
| incentives align to make it rational. It'd be better if
| people could stay longer and still grow their compensation.
| ChrisMarshallNY wrote:
| I was just chatting with a friend of mine, this morning,
| about this kind of thing.
|
| He works as a _highly_ -skilled tech, at a major
| medical/scientific corporation. They have invested _years_ of
| training in him, he brings them _tremendous_ value, and they
| know it. He was just telling me how he used that value to
| negotiate a higher compensation package for himself. Not as
| good as if he swapped jobs, but he really has a sweet gig.
|
| People who stay, take Responsibility for the code they write.
| They will need to face the music, if it doesn't work, even if
| they are not responsible for maintaining it.
|
| They are also worth investing in specialized training, as
| that training will give great ROI, over time.
|
| But keeping skilled people is something that modern
| management philosophy (in tech, at least) doesn't seem to
| care about.
|
| Until corporations improve the quality of their managers;
| especially their "first-line" managers, and improve their
| culture, geared towards retaining top talent (which includes
| paying them more -but there's a _lot_ more that needs doing),
| I can 't, with good conscience, advise folks not to bounce.
| eastbound wrote:
| > But keeping skilled people is something that modern
| management philosophy (in tech, at least) doesn't seem to
| care about.
|
| I'm a founder for 10 people and this is the first thing we
| think about. Except for low performers; except that
| youngsters need a variety of experience to be proficient at
| life; except that the team is not performing well(1). 25%
| or 30% increases for half the workforce are frequent.
|
| (1) The biggest remark from management coaches is that
| giving raises lowers employee performance, which I can
| fully witness in my company. It's not even good for morale.
| I'm just happy that people exit the company fitter and with
| a girlfriend, even a kid and sometimes a permanent
| residency, but business-wise I've been as good as a bad
| leader.
|
| I'm reaching the sad conclusion that employees bring it
| upon themselves.
| ChrisMarshallNY wrote:
| Paying more is not the answer (but it is also _not_ not
| the answer -we need to pay well). Improving the workplace
| environment, into a place people want to stay, is
| important.
|
| My friend could double his salary, moving almost anywhere
| else, but he gets a _lot_ of perks at his work, and is
| treated extremely well by his managers.
|
| They just gave him a _rave_ review, and that did more to
| boost his willingness to stay, than a 10% raise. He will
| still negotiate a better salary, but is more likely to be
| satisfied with less than he might have, if they tried to
| treat him badly.
|
| Treating employees with Respect can actually improve the
| bottom line. They may well be willing to remain in
| difficult situations, if they feel they are personally
| valued.
|
| I know this from personal experience. When they rolled up
| my team, after almost 27 years, the employee with the
| _least_ tenure had a decade. These were top-shelf C++
| image processing engineers, that could have gotten much
| higher salaries, elsewhere.
| trinsic2 wrote:
| Yeah I agree with this. It really depends on the culture
| of the business. If the employee feels valued, giving
| raises increases feeling valued.
|
| The problem is our current form of corporate culture.
| Employees don't feel like they matter, there efforts are
| a cog in a wheel. If you get a raise in this type
| culture, it only matters to the bottom line and there is
| no incentive produce because the employee is already
| unhappy in the first place.
|
| Change your business culture and these problems will
| disappear, IMHO.
| nouripenny wrote:
| Is there any alternative to raises that don't lower
| employee performance, like some kind of bonus scheme? Or
| do you find some unfortunate relation between money vs
| motivation?
| scarface_74 wrote:
| Truly unlimited PTO where you judge employees by their
| performance. I just spoke to my manager at the job I
| started late last year and he said it is customary for
| people to take 5-6 weeks kid a year.
|
| We also have a 401K match with an immediate vest.
| scarface_74 wrote:
| How is paying people less than market value good for
| morale?
| rr808 wrote:
| Sounds like he's lucky though. Many companies are happy to
| let you specialize in their area of business, own the
| special software, get to know all the vendors & business
| contacts then really not pay you well. You dont get to find
| out until 5 years in when you have skills that aren't
| really transferable to a new job.
| ChrisMarshallNY wrote:
| His skills are quite transferable. Many of the company's
| customers would love to hire him away. The company
| doesn't have a noncompete, and he'd probably quit, if
| they tried.
| 7bit wrote:
| > But keeping skilled people is something that modern
| management philosophy (in tech, at least) doesn't seem to
| care about.
|
| If they would care then job hopping would not exist. If
| staying at s company would be more. Beneficial to your
| salary, why would you ever want to change company, if you
| are otherwise happy?
| scarface_74 wrote:
| > _Not as good as if he swapped jobs, but he really has a
| sweet gig_
|
| If your main motivation for working is to exchange your
| labor for the maximum amount of money possible, I don't see
| how that is the positive outcome you think it is.
|
| I personally wouldn't leave my current job if another one
| for $100K more fell into my lap. But the "unlimited PTO"
| where the custom is to take at least 5-6 weeks off during
| the year not including paid holidays and it being fully
| remote is hard to beat.
| ChrisMarshallNY wrote:
| Not sure how you got that from what I wrote.
|
| I mean pretty much exactly what you said.
|
| I apologize for being unclear.
| marcosdumay wrote:
| > It's one of the easiest tools for increasing my
| compensation.
|
| This is the root problem. None of the problems the GP pointed
| up were created by software developer.
|
| Now, if you want to know the consequences, it causes an
| entire generation of people that don't really know what they
| are doing because they never see the long-term consequences
| of their actions. But again, it's not the software developers
| that are causing this, nor are they the ones that should fix
| it.
| pjmlp wrote:
| Not everyone is fortunate to live in regions where that is
| easy doable, nor all cultures see job hopping as positive.
| scarface_74 wrote:
| And when you change jobs, you control the narrative. Unlike
| when you have to deal with promo docs and internal politics
| asdev wrote:
| best Leetcoders generally add the least value business wise
| orochimaaru wrote:
| Most of what is said are symptoms not causes. Leetcode
| interviews: lack of continuous certification and changing
| toolsets too fast
|
| Frequent job hopping: lack of pay upgrades because software is
| considered a cost center
|
| I could go on but in reality it's a disconnect between what
| business thinks the software is worth as opposed to what the
| engineer wants to do with it.
|
| You can say software is an art but commodity art doesn't make
| much money. In reality, the ad driven software has greatly
| inflated salaries (not complaining but it's reality). Now it's
| going to be an ai bubble. But your rank and file business
| doesn't care what software bubble is happening but
| unfortunately they are bound by the costs that come with it.
|
| Have you seen the process that happens in defense or medical
| equipment industries. You probably won't complain.
| dinkumthinkum wrote:
| Why is LeetCode a symptom of a lack of continuous
| certification or changing toolsets? I ask because LC is about
| neither of those things. I agree LC is a symptom of something
| but I think it's something else. I also don't think ad driven
| software has inflated salaries, there are many, many more
| software companies than ad based ones, it even only
| compromises at most half of FANG, which is hardly the only
| game in software. For defense and medical, these are places
| where software is not tertiary concerns.
| dijit wrote:
| Well, take the macro position.
|
| If you didnt have degree requirements and certification
| bodies for:
|
| * accountants
|
| * engineers
|
| * doctors
|
| * lawyers
|
| What do you think hiring might look like?
|
| Do you think they would build a hiring process to validate
| to the best of their ability your aptitude of the core
| fundamentals- except _worse_ than certification and
| education bodies?
|
| I would presume so at least.
| orochimaaru wrote:
| There is a bit of a difference between other professions
| and software. You wouldn't hire an orthopedic surgeon for
| cardiology. Now, the human body doesn't change that fast.
| So both are needed. In software the rate of change is
| much faster. So what happens is tools change and people
| who want to switch streams for better opportunity have to
| tweak resumes. Now the only way to validate basic
| proficiency comes down to leetcode style interviews - for
| better or worse. It's pretty much the only common
| denominator between an interviewer and the candidate.
| scarface_74 wrote:
| What makes you think certifications can't be gamed? Brain
| dumps have been a thing since at least 2008 and just like
| you can have a dozen AWS certifications, it tells you
| nothing about whether they could actually be productive
| in the real world.
|
| Have you ever done any of the various IT certs?
| criddell wrote:
| Do you think gaming is a very big problem with
| accountants, doctors, lawyers, and professional
| engineers?
| scarface_74 wrote:
| Doctors and lawyers specializes. Are you going to have
| specialized non gameable certifications for all the
| different facets of software development?
|
| Doctors also go to school for 8 years and then do
| residencies. Lawyers go to school for 7. Are you
| proposing that?
| hibikir wrote:
| Having spent quite a bit of time around a couple of those
| groups, I find most of those degree requirements and
| certifications as just ways to increase salaries, more
| than ways to increase quality. Many people pass state
| bars and are incompetent. Lawyers that go through
| residency get lazy and kill patients, and they aren't
| magically superior to someone that isn't allowed to work
| in, say, the US, because their medical training was done
| the wrong country.
|
| Realistically, licensing boards are there to protect
| their members, and rarely do political things against
| people in the same body with unpopular opinions. You have
| to be catastrophic for most boards to do anything about
| you: Just like a police union will defend a union member
| that has committed gross negligence unless the evidence
| is public.
|
| When you hire a doctor for something actually important,
| you don't look at the certification body: You look at
| long term reputation, which you also do in software. Only
| the largest of employers will leetcode everyone as a
| layer of fairness. In smaller employers, direct, personal
| references replace everything, which is what I'd go with
| if I needed an oncologist for a very specific kind of
| cancer. The baseline of aptitude from the certification
| body doesn't matter there at all.
| YZF wrote:
| Software may be important in defense and medical but I
| don't think this is reflected in how software engineering
| is done or how software engineers work in those industries.
| readyplayernull wrote:
| LoC metrics instead of QoC.
| airstrike wrote:
| We are destroying software by thinking the web is the only
| platform in which we can write GUIs
| layer8 wrote:
| I can only hope that the tech stack for server-served apps will
| be much more sane in a couple of decades (for the developers of
| the future; it'll be too late for me). We are really in a very
| bad place now in that regard.
| scarface_74 wrote:
| What do you propose? Do you remember how bad it was trying to
| upgrade and maintain windows programs across a large
| organization?
| bdhcuidbebe wrote:
| "we are" not antirez.
|
| Semi-related: Start using profane variable names because
| apparantly it will cause Copilot to stop analyzing your code.
| kittikitti wrote:
| "Don't reinvent the wheel!"
|
| I think people vastly underestimate "the wheel". The wheel was
| something recreated independently over and over again for
| thousands of years across human history. Even your favorite
| programming language or web framework is not comparable to "the
| wheel".
| austin-cheney wrote:
| Holy fuck. I internally explode in anger every time I hear _Don't
| reinvent the wheel_.
|
| To me this is the most sure way to identify the adults from the
| children in the room. People that can actually program, strangely
| enough, aren't bothered by programming.
| ludston wrote:
| The ones considered adults aren't so emotionally disregulated
| that they get angry about sometimes useful idioms.
| austin-cheney wrote:
| The grown ups do sometimes get angry at children that lie
| about their capabilities and equivocate with bullshit
| excuses.
| throwaway81523 wrote:
| destroyallsoftware.com is a excellent web site :).
| nurettin wrote:
| We are destroying software by selling it to greedy corporates who
| try to monopolize all open source clients for that software on
| github.
| stmw wrote:
| He is exactly right. Complexity is eating the world. Faster CPUs,
| larger memories and faster networks have brought great capability
| -- but removed the natural governor on software complexity.
| agumonkey wrote:
| the internet era also changed things - never
| ending upgrades - unstable ui, unstable ecosystems
| - fix it later - shallow business models
| (subscriptions, freemium, adinfested) - social
| everything (it used to be that my computer was a little escape
| space where and when i wanted, now i'm tethered to the web
| noise)
| cedws wrote:
| Capitalism doesn't incentivise building quality software, it
| incentivises building as quickly as possible and covering up the
| flaws because "we'll fix it later" (spoiler: it doesn't get fixed
| later.)
|
| Until the incentives change, the outcome won't change.
|
| Pointless meetings and bureaucracy also doesn't help. Instead of
| giving engineers time and breathing room to build well-defined
| systems, organisations treat them like fungible workhorses that
| must meet arbitrary deadlines.
| moktonar wrote:
| We are not destroying software, money is.
| uses wrote:
| Yeah, 20 years ago when I started building websites I was still
| in my CS major. We didn't have these huge layers of libraries and
| frameworks. I wonder how much I would know now if I didn't have
| to just build everything myself. We would make all kinds of
| things and we did it all from scratch - upload files, log in,
| save stuff in databases using actual sql, entire ecommerce
| experiences, I would write the whole "front end" and "back end"
| by hand. And everything was really fast.
| thomastjeffery wrote:
| We are destroying software to build on top of it over and over
| again. What could we do instead?
|
| When we build software, we answer three questions: "what?",
| "how?", and "why?". The answer to what becomes the data (and its
| structure). The answer to how is the functionality (and the UI/UX
| that exposes it). The answer to why is...more complicated.
|
| The question why is answered in the process of design and
| implementation, by every decision in the development process.
| Each of these decisions becomes a wall of assumption: because it
| is the designer - not the end user - making that decision.
|
| Very rarely can the end user move or replace walls of assumption.
| The only real alternative is for the user to alter the original
| source code such that it answers _their_ why instead.
|
| Collaboration is the ultimate goal. Not just collaboration
| between people: collaboration between _answers_. We often call
| this "compatibility" or "derivative work".
|
| Copyright, at its very core, makes collaboration illegal by
| default. Want to make CUDA implementation for AMD cards? You must
| not collaborate with the existing NVIDIA implementation of CUDA,
| because NVIDIA has a copyright monopoly. You must start over
| instead. This is NVIDIA's moat.
|
| Of course, even if copyright was not in the way, it would still
| be challenging to build compatibility without access to source
| code. It's important to note that NVIDIA's greatest incentive to
| keep their source code private is so they can leverage the
| incompatibility that fills their moat. Without the monopoly
| granted/demanded by copyright, NVIDIA would still have a moat of
| "proprietary trade secrets", including the source code of their
| CUDA implementation.
|
| Free software answers this by keeping copyright and turning it
| the other direction. A copyleft license _demands_ source code is
| shared so that collaboration is guaranteed to be available. This
| works exclusively for software that participates, and that is
| effectively its own wall.
|
| I think we would be better off without copyright. The
| collaboration we can guarantee through copyleft is huge, but it
| is clearly outweighed by the oligopoly that rules our society: an
| oligopoly constructed of moats whose very foundations are the
| incompatibility that is legally preserved through copyright.
| ChrisMarshallNY wrote:
| These all resonate _deeply_ with me:
|
| _> We are destroying software with an absurd chain of
| dependencies, making everything bloated and fragile._
|
| _> We are destroying software by always thinking that the de-
| facto standard for XYZ is better than what we can do, tailored
| specifically for our use case._
|
| _> We are destroying software mistaking it for a purely
| engineering discipline._
|
| _> We are destroying software claiming that code comments are
| useless._
|
| _> We are destroying software by always underestimating how hard
| it is to work with existing complex libraries VS creating our
| stuff._
|
| This one begs the question: "What is 'fast'?". I mean, is it
| high-performance, or quickly-written? (I think either one is a
| problem, but "quickly-written" leads to bad software, and overly-
| optimized software can be quite hard to maintain and extend).
|
| _> We are destroying software trying to produce code as fast as
| possible, not as well designed as possible._
| LargeWu wrote:
| I take "fast" here to mean "written to delivery business value
| as soon as possible"
| swaraj wrote:
| I spent 10 hrs this week upgrading our pandas/snowflake libs to
| latest bc there was apparently a critical vulnerability in the
| version we used (which we need to fix bc a security cert we need
| requires us to fix these). The latest versions are not major
| upgrades, but completely changed the types of params accepted.
| Enormous waste of time delivering 0 value to our business
| parasti wrote:
| Security updates are probably the only type of updates that I
| wouldn't ever call a waste of time. It sucks when they are
| conflated with feature updates or arbitrary changes, but by
| itself I don't understand calling them a waste of time.
| tptacek wrote:
| At my first professional software job, where we wrote C, because
| that was all you could realistically write commercial software
| in, there was one person on our floor who could do software
| builds. He used some commercial build tool the company had
| licensed and he was the only one who knew how to use it or would
| be allowed to learn how to use it. His customers were every
| product team in our division --- about 12 of them. We had to
| petition to get beta releases done. The builds took hours.
|
| I think we're doing fine.
| dgb23 wrote:
| This cracked me up. I love hearing those stories, also from my
| father, where he would talk about "we already did that in the
| 80's and it was called...", and then he would tell me about
| some obscure assembler tricks to patch binaries, in order to
| keep them compatible with some system I never heard about.
|
| But still, I think we can do better. That story you shared
| highlights a gross inefficiency and diminishing of agency that
| comes from dependencies.
| phendrenad2 wrote:
| I kind of agree. I think software has a certain amount of
| "badness" that will always exist, it's a mathematical
| equilibrium. There are a myriad of things that can make your
| process bad, and if you fix all of them, you'll never ship. The
| list Pope gives here are the most common issues, but not all
| teams will check the whole list.
| YZF wrote:
| What year are we talking about here?
|
| Circa 1982 or so (and some years before) IBM was shipping
| mainframe software written in Assembly that anyone could build
| or modify. They had a bug database that customers could access.
| Around the same era Unix was shipping with source code and all
| the tooling you needed to build the software and the OS itself.
|
| So maybe compared to some of that we're doing worse.
| tptacek wrote:
| 1998.
| YZF wrote:
| Circa 1999 I was with a startup. We wrote C and C++ for
| Windows and embedded platforms. We used source control.
| Every developer could build everything on their PC. We used
| Visual Studio.
|
| Also from 2000:
| https://www.joelonsoftware.com/2000/08/09/the-joel-
| test-12-s...
|
| So I think we knew around that time what patterns were good
| ones... But sure, lots of software organizations didn't
| even use source control and failed Joel's test miserably.
|
| EDIT: And sadly enough many orgs today fail Joel's test as
| well. We forgot some things that help make better software.
| tptacek wrote:
| The shop I was at was Network Associates (you'd know them
| now as McAfee).
| pvg wrote:
| _we knew around that time what patterns were good ones_
|
| The source control system I had at one job around that
| time was a dvcs! At a different one, the source control
| system had its own filesystem was generally insane. It
| had its own fulltime maintainer sort of like tptacek's
| build person.
|
| The big difference, really, was that all this software
| cost a lot of money compared to now where it mostly does
| not.
| bbor wrote:
| IMO this is some quintessential false nostalgia mixed with
| uncritical, confirmation-bias driven cynicism. When exactly are
| we pointing to when we express these complaints? I get the sense
| that the answer is invariably either "my first job out of
| college" or "before React", whenever this comes up.
|
| Even more fundamentally, it's built on the ubiquitous mistake
| made by those who make good money in the current status quo: it
| doesn't name the actual cause of rushed work et al., which is
| obviously capitalist cost-cutting, not lazy professionals.
| aredestroyoursz wrote:
| What makes anyone think that anything in the universe is
| protected from the innate natural process of divide, conquer,
| exploit and hoard...
|
| He makes very good points. But he missed one. We are destroying
| software(or anything else) by waiting till something goes wrong
| to fix it. ex: Software Security, US Food Standards and their
| relation to the health of it's citizens, etc...
| nickjj wrote:
| The timing of this is pretty convenient.
|
| I just open sourced a CLI tool for income and expense tracking
| yesterday at https://github.com/nickjj/plutus and I'd like to
| think I avoided destruction for each of those bullets.
|
| You have a choice on the code you write and who you're writing it
| for. If you believe these bullets, you can adhere to them and if
| you're pressured at work to not, there are other opportunities
| out there. Don't compromise on your core beliefs. Not all
| software is destroyed.
| TacticalCoder wrote:
| > We are destroying software with complex build systems.
|
| > We are destroying software with an absurd chain of
| dependencies, making everything bloated and fragile.
|
| > We are destroying software by making systems that no longer
| scale down: simple things should be simple to accomplish, in any
| system.
|
| That's true and I'd say we've got proof for that with the _fact_
| that many software is now run in containers.
|
| I always get downvoted for saying that it's not normal we now all
| run things in containers but _I do run my own little infra at
| home_. It 's all VMs and containers. I know the drill.
|
| It's not normal that to do something simple and which should be
| "dumb", it's easier to just launch a container and then interface
| with the thing using new API calls that are going to be outdated
| at the next release. We lost something and it's a proof we gave
| up.
|
| This containerization-of-all-the-things is because we produce and
| consume turds.
|
| Build complexity went through the roof so we have to isolate a
| specific build environment in a container file (or, worse, a
| specific environment tailored to be accept one build already
| made).
|
| Criticize Emacs as much as you want: the thing builds just fine
| from source with way more lines of code (moreover in several
| languages) than most projects. And it builds fine since decades
| (at least for me). And it doesn't crash (emacs-uptime -> 8 days,
| 5 hours, 48 minutes and that's _nothing_. It could be months but
| I sometimes turn my computer off).
|
| Nowadays you want to run this or that: you better deploy a
| container to deal with the build complexity, deployment
| complexity and interacting complexity (where you'll use, say, the
| soon-to-be-updated REST calls). And you just traded performance
| for slow-as-molasses-I-wrap-everything-in-JSON calls.
|
| And of course because you just deployed a turd that's going to
| crash anyway, you have heartbeats to monitor the service and we
| all applaud when it automatically gets restarted in another
| container once it crashed: _" look what a stable system we have,
| it's available again?"_ (wait what, it just crashed again, oh but
| no problem: we just relaunched another time)
|
| It's sad really.
| edanm wrote:
| This seems like an interesting time to post this. With the rise
| of LLMs, Software development has changed more in the last two
| years than at any time I can previously recall. And I strongly
| suspect that's just the beginning.
|
| I believe we'll soon be looking for "the joy of programming" in a
| totally different way, far more outcome-oriented than it is
| today. (Which is, in my book, a good thing!)
| layer8 wrote:
| I mean, you're the CEO of an AI company.
| edanm wrote:
| Umm, yeah, so? What is the implication of this comment
| supposed to be?
| thebiglebrewski wrote:
| Interesting takes. I got a sort of "Yom Kippur Vidui" vibe from
| this if anyone else in the tribe is reading haha.
|
| _Read responsively_
|
| "We are destroying software by no longer taking complexity into
| account when adding features or optimizing some dimension.
|
| _And we are destroying software with complex build systems._
|
| We are destroying software with an absurd chain of dependencies,
| making everything bloated and fragile.
|
| _And we are destroying software telling new programmers: "Don't
| reinvent the wheel!". But, reinventing the wheel is how you learn
| how things work, and is the first step to make new, different
| wheels. "_
|
| Yie-die-die-die-diiiiieee-dieeee,Yie die die die dieee dieeee
| hacker_homie wrote:
| My take away is that packages were a mistake I have never heard
| anyone happy to deal with packages or versioning. Dependencies
| should be expensive to slow the bloat.
| revskill wrote:
| Enjoying programming is harder than u think.
| kshri24 wrote:
| EDIT: should have read the comments first. Answered here:
| https://news.ycombinator.com/item?id=42983369
|
| I am unable to reconcile these two seemingly contradictory takes
| in the article (rest of it I concur with):
|
| "We are destroying software telling new programmers: "Don't
| reinvent the wheel!". But, reinventing the wheel is how you learn
| how things work, and is the first step to make new, different
| wheels."
|
| "We are destroying software pushing for rewrites of things that
| work."
|
| By rewrite do you mean 1-to-1 porting the code to another
| language because reason is:
| faster/easier/scalable/maintainable/_____ (insert your valid
| reason here)?
| semiinfinitely wrote:
| this person must have never seen a bell curve meme
|
| 50 IQ: haha software is complicated whatever
|
| 100 IQ: (this post)
|
| 150 IQ: software is complicated whatever
| js4ever wrote:
| Amen! I totally agree with Antirez
| IshKebab wrote:
| These are just barely meaningful and dubiously accurate rants
| that are designed to make the author feel superior.
|
| > We are destroying software by no longer caring about backward
| APIs compatibility.
|
| Come on, who believes this shit? Plenty of people care about API
| backwards compatibility.
|
| > We are destroying software pushing for rewrites of things that
| work.
|
| So never rewrite something if it "works"? There are plenty of
| other good reasons to rewrite. You might as well say "We are
| destroying software by doing things that we shouldn't do!"
|
| > We are destroying software claiming that code comments are
| useless.
|
| No we aren't. The crazy "no comments" people are a fringe
| minority. Don't confuse "no comments" (clearly insane) with "code
| should be self-documenting" (clearly a good idea where possible).
|
| Worthless list.
| davedx wrote:
| Depends where you work and what on and who with.
|
| Software engineering is far from a monoculture.
|
| Maybe what I've seen change over the years is the strategy of
| "pull a bunch of component systems together and wire them up to
| make your system" used to be more of an enterprise strategy but
| is now common at smaller companies too. Batteries included
| frameworks are out, batteries included dependencies in a bunch of
| services and docker images are in.
|
| It's true many people don't invent wheels enough. But there are a
| lot of developers out there now...
| johannessjoberg wrote:
| > We are destroying software trying to produce code as fast as
| possible, not as well designed as possible.
|
| Legacy systems are born from rushing into implementation to feel
| productive rather than understanding the problem. Slow is smooth.
| Smooth is fast.
| YZF wrote:
| Though it's not the only way to create legacy systems.
| Sometimes they are of sound design which deteriorates over
| time. Or the requirements shifted such that the design is no
| longer adequate. Or as the article mentions, rewrites for no
| good reason.
|
| When I do a git blame of something coherent, that worked well
| in production, that I wrote years ago, almost none of my
| original code survived, every line is now written by a
| different person. That's the entropy of software systems left
| unchecked. It was not really rushed, there was a ton of time
| debating design before a single line was written.
| foxhop wrote:
| For somebody who cares about software why are you advertising for
| disqus comments? Link in bio to a public domain commenting system
| forn static sites.
| picafrost wrote:
| I don't disagree. But if you want to work as an artisan you don't
| work at a factory. Similarly, you can't expect the products
| coming out of a factory to be at the artisan level.
|
| What is it about software that causes us to search for aesthetic
| qualities in the instructions we write for a machine? Ultimately
| the problems we're solving, for most of us, will be utterly
| meaningless or obsolete in ten years at most.
| futuraperdita wrote:
| I think a lot of software engineers have been in denial that we
| have been working in factories as a lot of the ZIRP-era
| technical structures were constructed in such a way to make it
| seem like we were part of guilds. The average company cares
| about craft only insomuch as it feeds enough product
| reliability and productivity.
|
| That illusion has been lifted a little harshly for a lot of
| people over the past year or so. I still enjoy software-as-
| craft but I don't hold any false belief that my day job does.
| kadushka wrote:
| 2 years from now 99.9% of all software will be written by AI. So
| just put those statements into your system prompt.
| ninkendo wrote:
| > We are destroying software by no longer caring about backward
| APIs compatibility.
|
| My take: SemVer is the worst thing to happen to software
| engineering, ever.
|
| It was designed as a way to inform dependents that you have a
| breaking change. But all it has done is _enable_ developers to
| make these breaking changes in the first place, under the
| protective umbrella of "I'll just bump the major version."
|
| In a better universe, semver wouldn't exist, and instead people
| would just understand that breaking changes must never happen,
| unless the breakage is obviously warranted and it's clear that
| all downstreams are okay with the change (ie. Nobody's using the
| broken path any more.)
|
| Instead we have a world where SemVer gives people a blank check
| to _change their mind_ about what API they want, regularly and
| often, and for them to be comfortable that they won't break
| anyone because SemVer will stop people from updating.
|
| But you can't just _not update_ your dependencies. It's not like
| API authors are maintaining N different versions and doing bug
| fixes going all the way back to 1.0. No, they just bump majors
| all the time and refactor all over the place, never even thinking
| about maintaining old versions. So if you don't do a breaking
| update, you're just delaying the inevitable, because all the
| fixes you may need are only going to be in the latest version. So
| any old major versions you're on are by definition technical
| debt.
|
| So as a consumer, you have to regularly do breaking upgrades to
| your dependencies and refactor _your_ code to work with whatever
| whim your dependency is chasing this week. That callback function
| that used to work now requires a full interface just because,
| half the functions were renamed, and things you used to be able
| to do are replaced with things that only do half of what you
| need. This happens all the god damned time, and not just in
| languages like JavaScript and Python. I see it constantly in Rust
| as well. (Hello Axum. You deserve naming and shaming here.)
|
| In a better universe, you'd have to think _very long_ and _very
| carefully_ about any API you offer. Anything you may change your
| mind on later, you better minimize. Make your surface area as
| small as possible. Keep opinions to a minimum. Be as flexible as
| you can. Don't paint yourself into a corner. And if you really,
| really need to do a big refactor, you can't just bump major
| versions: you have to start a new project, pick a new name (!),
| and find someone to maintain the old one. This is how software
| used to work, and I would love so much to get back to it.
| debeloo wrote:
| >But all it has done is enable developers to make these
| breaking changes in the first place, under the protective
| umbrella of "I'll just bump the major version."
|
| Which is just fine when it is a non funded free software
| project. No one owes you anything in that case, let alone
| backwards compatibility.
| ninkendo wrote:
| The problem is the _normalization_ of breaking changes that
| has happened as a result. Sure, you don't owe anybody
| backwards compatibility. You don't owe anybody anything. But
| then whole ecosystems crop up built out of constituent parts
| which _each_ don't owe anyone backwards compatibility, and
| the result is that writing software in these ecosystems is a
| toxic wasteland.
|
| It's not an automatic outcome of free software either. The
| Linux kernel is famous for "we don't break user space, _ever_
| ", and some of Linus's most heated rants have come from this
| topic. All of GNU is made of software that doesn't break
| backwards compatibility. libc, all the core utilities, etc,
| all have maintained deprecated features basically forever.
| It's all free software.
| colonial wrote:
| This attitude doesn't fix anything. Refusing to ever break an
| interface is how you get stuck with trash like C++'s
| std::regex, which is quite literally slower than shelling out
| to PHP - and it's not like we can just go and make C+++ to fix
| that.
|
| Forbidding breaking changes isn't going to magically make
| people produce the perfect API out of the gate. It just means
| that fixes either don't get implemented at all, or get
| implemented as bolt-on warts that sow confusion and add
| complexity.
| ninkendo wrote:
| Of course, mistakes happen. But the degree to which they
| happen reflects bad engineering in the first place, and this
| sort of bad engineering is the very thing that SemVer
| encourages. Move fast and break things, if you change your
| mind later you can just bump the major version. This attitude
| is killing software. I'd rather have a broken std::regex and
| a working std::regex2 than have a world where C++ code just
| stops compiling every time I update my compiler.
| ongytenes wrote:
| When developers become too dependent on AI to "assist" them in
| coding, they're more likely to be unable to debug "their own"
| code as they won't have a full grasp/understanding of it.
|
| People tend to adapt to technology by becoming more lazy, putting
| less effort in understanding. Look at how after of calculators
| became common, we got generations of people who struggle to do
| basic math.
| sillysaurusx wrote:
| But there have always been people who struggle to do basic
| math. It doesn't seem true that people will be unable to debug
| "their own" code, even if it was generated by AI, because
| people already learn how to debug open source software not
| written by themselves.
| layer8 wrote:
| Maybe we should restrict code generation to the dumber models
| so that we can still use the more lucid models for debugging.
| ;)
|
| (This is an allusion to Kernighan's lever.)
| scarface_74 wrote:
| Old folks (raises hand) said the same thing about "high level
| languages" like C when people don't learn assembly.
| karmakaze wrote:
| It's a good message with poor framing. If anything we're not
| destroying software, we're making much more than ever, of reduced
| quality and scope. Could be adjusted to destroying software
| _quality_.
| mihaaly wrote:
| Related: "We are not dying. That's how we live."
|
| Or others may say: "There are software, and there are things
| remind people of software".
| stefanos82 wrote:
| As soon as I finished reading the article, the very first thing
| that came in my mind is Dieter Rams' "10 Principles of Good
| Design"; I have been following his principles as much as I can,
| as they match, more or less, those of UNIX's philosophy:
| 1. Good design is innovative 2. Good design makes a
| product useful 3. Good design is aesthetic 4.
| Good design makes a product understandable 5. Good
| design is unobtrusive 6. Good design is honest
| 7. Good design is long-lasting 8. Good design is
| thorough down to the last detail 9. Good design is
| environmentally-friendly 10. Good design is as little
| design as possible
| avidiax wrote:
| These don't sound like the UNIX philosophy. My impression is
| that UNIX is more like what's outlined here:
|
| https://web.stanford.edu/class/archive/cs/cs240/cs240.1236/o...
| MonkeyClub wrote:
| It's informally semi-codified:
|
| https://en.m.wikipedia.org/wiki/Unix_philosophy
| scarface_74 wrote:
| And most of that misses the goal of why you write software for
| a business.
|
| _You write software for a company so someone will give you
| money for it or the company can save money_
|
| Everything else takes a backseat to that core mission. The
| first goal when writing software is to efficiently get to a
| point where that goal can be met. It makes no sense to polish
| software if you are going to run out of money before it gets
| released, management cuts funding or you can't find product
| market fit to convince investors to give you money depending on
| what your goal is.
|
| Code doesn't always need to be long lasting, you can't predict
| how the market will change, how the underlying platform will
| change, when a better funded competitor will come in and eat
| your lunch, etc.
|
| Good design doesn't need to be "innovative". It needs to go
| within the norms of the platform or ecosystem it is part of.
| brian-armstrong wrote:
| Seems like maybe antirez has lost the joy of coding, at least for
| a little while.
|
| It's easy to get caught up in what you dislike about software,
| but you have to make yourself try new stuff too. There's always
| more delight to be found. Right now, I think it's good to embrace
| LLM assistants. Being able to sit down and avoid all the most
| tedious parts and focus purely on engineering and design makes
| every session much more enjoyable.
|
| Software itself is better now than it has ever been. We're slowly
| chipping away at our own superstitions. Just because some people
| are fully employed building empty VC scams and software to
| nowhere does not damn the rest of the practice.
| antirez wrote:
| I never lost the joy of coding since I simply do what I want
| and refuse to do what I don't enjoy. But unfortunately most
| people can't because of many reasons and I know many that are
| now very disappointed with the state of software.
| scarface_74 wrote:
| Opposite anecdote, in the 2000s, I worked at a company that had
| dozens of computers running jobs, built out a server room with
| raised floors and built out a SAN to store a whopping 3 TB of
| data and we had a home grown VB6 job scheduler that orchestrated
| jobs across the computers running Object Rexx scripts.
|
| We had our own internal load balancer, web servers, mail servers,
| ftp servers to receive and send files, and home grown software.
|
| Now I could reproduce the entire setup within a week at the most
| with some yaml files and hosted cloud services. All of the server
| architected is "abstracted". One of the things he complains
| about.
|
| As far as backwards compatibility, worshipping at the thrown of
| backwards compatibility is one reason that Windows is the shit
| show it is. Even back in the mid 2000s there was over a dozen
| ways to represent a string when programming and you had to
| convert back and forth between them.
|
| Apple has been able to migrate between 5 processors during its
| existence by breaking backwards compatibility and even remove
| entire processing subsystems from ARM chips by removing 32 bit
| code compatibility.
| worik wrote:
| > As far as backwards compatibility, worshipping at the thrown
| of backwards compatibility is one reason that Windows is the
| shit show it is.
|
| Not entirely, there are other reasons too
|
| But we should respect semantic versioning. Python is a dreadful
| sinner in that respect.
| mihaaly wrote:
| About compatibility.
|
| Windows is a shitshow beacuse the leadership is chaotic,
| dragged all around all the time, never finishing nothing well.
| They only survived because of backward compatibility! Building
| on the unlikely success in the 90s.
|
| Also, why do I have to install new software in every couple of
| months to access my bank account, secure chat, flight booking
| system, etc., etc., without any noticable difference in
| operation and functionality. A lot of things unreasonably
| becoming incompatible with 'old' (we are talking about months
| for f's sake!!) versions. That's a nuisance and erosion of
| trust.
| scarface_74 wrote:
| Apples leadership hasn't always been a light on a shining
| hill, especially during the 90s and they still managed the
| 68K to PPC transition.
| Arelius wrote:
| > worshipping at the thrown of backwards compatibility is one
| reason that Windows is the shit show it is
|
| You say Windows is a shit show, but as someone who has
| developed a lot on both Windows and Linux, Linux is just as
| much a shit show just in different ways.
|
| And it's really nice being able to trust that binaries I built
| a decade ago just run on Windows.
| scarface_74 wrote:
| Linux is a shit show because there is no driver standard
| among other reasons
| smitty1e wrote:
| This gets at the heart of The Famous Article: my pet
| project vs. corporate-grade stuff.
|
| The individual vs. the group.
|
| Where I agree with the author is the need to keep
| individual tinkering possible.
|
| However, generalizing anyone's idiosyncratic tastes is
| impossible.
| scarface_74 wrote:
| Is that a real article? Do you have a reference for it?
| inglor_cz wrote:
| "And it's really nice being able to trust that binaries I
| built a decade ago just run on Windows."
|
| Wouldn't this need be solved by an emulator of older
| architectures?
|
| There would be a performance cost, but maybe the newer
| processors would more than make up for it.
| Rohansi wrote:
| What older architecture? Windows has been on x86 for
| decades. You should be able to run any 32-bit application
| built 20+ years ago on modern Windows, assuming the
| application didn't rely on undocumented/internal Windows
| APIs.
| dpkonofa wrote:
| >Apple has been able to migrate between 5 processors during its
| existence by breaking backwards compatibility and even remove
| entire processing subsystems from ARM chips by removing 32 bit
| code compatibility.
|
| I would consider myself an Apple evangelist, for the most part,
| and even I can recognize what's been lost by Apple breaking
| backwards compatibility every time they need to shift
| direction. While the philosophy is great for making sure that
| things are modern and maintained, there is definitely a non-
| insignificant amount of value that is lost, even just
| historically but also in general, by the paradigm of constantly
| moving forward without regard for maintaining compatibility
| with the past.
| scarface_74 wrote:
| What was the alternative? Sticking with 65x02, 68K, or PPC?
|
| They could have stuck with x86 I guess. But was moving to ARM
| really a bad idea?
|
| They were able to remove entire sections of the processor by
| getting rid of 32 bit code and saving memory and storage by
| not having 32 bit and 64 bit code running at the same time.
| When 32 bit code ran it had to load 32 bit version of the
| shared linked library and 64 bit code had to have its own
| versions.
| dpkonofa wrote:
| >What was the alternative? Sticking with 65x02, 68K, or
| PPC?
|
| No, including an interpreter like they did (Rosetta) was an
| alternative. The "alternative" really depends on what the
| goals were. For Apple, their goal is modern software and
| hardware that works together. That's antithetical to
| backwards compatibility.
|
| >They could have stuck with x86 I guess. But was moving to
| ARM really a bad idea?
|
| I don't think I ever suggested that it was or that they
| couldn't have...
|
| >They were able to remove entire sections of the processor
| by getting rid of 32 bit code and saving memory and storage
| by not having 32 bit and 64 bit code running at the same
| time.
|
| Yes, and, in doing so, they killed any software that wasn't
| created for a 64-bit system. Again, for even a purely
| historical perspective, the amount of software that didn't
| survive each of the instanced transitions is non-
| negligible. Steam now has an entire library of old Mac
| games that can't run on modern systems anymore because of
| the abandonment of 32-bit without any consideration for
| backwards compatibility. Yes, there are emulators and apps
| like Wine and CrossOver than can somewhat get these things
| working again but there's also a whole subsection of
| software that just doesn't work anymore. Again, that's just
| a byproduct of Apple's focus on modern codebases that are
| _currently maintained_ but it 's still a general detriment
| that so much useable software was simply lost immediately
| because of these changes when there could have been _some_
| focus on maintaining compatibility.
| scarface_74 wrote:
| > _No, including an interpreter like they did (Rosetta)
| was an alternative._
|
| The downside of including an interpreter with no end of
| life expectations is that some companies get lazy and
| will never update their software to modern standards.
| Adobe is a prime example. They would have gladly stuck
| with Carbon forever if Apple hadn't changed their minds
| about a 64 bit version of Carbon.
|
| That was the sane reason that Jobs made it almost
| impossible to port legacy text based software to early
| Macs. Microsoft jumped onboard developing Mac software
| and Lotus and WordPerfect didn't early on.
|
| But today you would have to have emulation software for
| Apple //es, 68K, PPC and 32 bit and 64 bit x86 software
| and 32 bit and 64 bit ARM (iOS) software all vying for
| resources.
|
| Today because of relentlessly getting rid of backwards
| compatibility, the same base OS can run on set top boxes,
| monitors (yeah the latest Apple displays have iPhone 14
| level hardware in them and run a version of iOS), phones,
| tablets, watches and AR glasses.
|
| Someone has to maintain the old compatibility layers and
| patch them for vulnerabilities. How many vulnerabilities
| have been found in some old compatible APIs on Windows?
| dpkonofa wrote:
| I'm not sure why you're responding to me. Nothing that
| you're saying is anything that I've mentioned or brought
| up. I know what the downsides are. I'm just saying that
| the goals that Apple has optimized for have resulted in a
| loss of things that many would consider valuable.
| BuyMyBitcoins wrote:
| Plus, the reduced power consumption and battery life
| extension is insanely good now. Whereas I could only get an
| hour and a half from an Intel MacBook Pro, I can now get
| over a days use out of the M4. I have not been affected by
| the lack of "legacy" software support and I am more than
| happy to have this tradeoff.
| dpkonofa wrote:
| I think most people, me included, are more than happy
| with the trade-off. That doesn't mean that nothing of
| value was lost in each transition.
| scarface_74 wrote:
| Engineering is always about trade offs. Microsoft could
| never make the trade offs that Apple has made and while
| it has suffered because of it in new markets, it's gained
| the trust of Big Enterprise. Microsoft should not be
| trying to act like Apple.
|
| There is room for both. But if you are a gamer, the Mac
| isn't where you want to be anyway. Computers have been
| cheap enough for decades to have both a Windows PC and a
| Mac. Usually a desktop and a laptop.
| dpkonofa wrote:
| I never suggested that they should, in either case. I'm
| just saying that there are things that are lost by
| completely ignoring backwards compatibility. There are
| plenty of Mac-only applications that aren't games that
| are now obsolete and unusable because of architecture
| changes.
| 3ple_alpha wrote:
| You can also reproduce it within a week without hosted cloud
| services. What matters is that you don't have to develop custom
| software and instead spend that week writing config files and
| orchestration scripts, be it cloud stuff, docker containers or
| whatever.
| namuol wrote:
| Who is "we"? The forces eroding software quality are
| disproportionately caused by short-sighted VCs.
| portaouflop wrote:
| The less software exists the better.
| sieve wrote:
| Well, I agree with him to a great extent.
|
| The complexity/dependency graph of a random application now-a-
| days is absolutely insane. I don't count everything in this,
| including the firmware and the OS like Muratori does in his
| video[1], but it is close enough. The transitive dependency
| problem needs to be solved. And we need to do something about
| Bill/Guido taking away all that Andy gives.
|
| I consider the OS (Win32 API, Linux syscalls) to be the only hard
| dependency for anything I write in C. Tend to avoid libc because
| of distribution issues. But you have no control over this layer
| once you switch over to Java/Python.
|
| The only thing you can then do is stop depending on every library
| out there to avoid writing a couple of hundred lines of code
| specific to your situation. It definitely increases the
| maintenance burden. But dependencies are not maintenance-free
| either. They could have the wrong API which you have to wrap
| around, or will break compatibility at random times, or become
| abandonware/malware or have some security flaw in them (rsync had
| a major security vulnerability just last month).
|
| My personal max line count for a useful project that does one
| thing is 5-10KLOC of Java/JS/Python. It is something I can go
| through in a couple of hours and can easily fix a few years down
| the line if I need to.
|
| [1] The Thirty Million Line Problem (2015)
| https://youtu.be/kZRE7HIO3vk
| stackedinserter wrote:
| Maybe we are destroying software, but at the same time we can
| deliver product/services to customers.
| et1337 wrote:
| A lot of these points are opposites of each other, so much so
| that it seems intentional. We're to maintain backward
| compatibility, yet eschew complexity.
|
| We're to reinvent the wheel for ourselves instead of relying on
| huge dependency trees, yet new languages and frameworks (the most
| common form of wheel reinventing) are verboten.
|
| The only way I can think to meet all these demands is for
| everyone (other than you, of course) to stop writing code.
|
| And I gotta say, a part of me wishes for that at least once a
| day, but it's not a part of me I'm proud of.
| siev wrote:
| It also reads to me like the contradictions are intentional.
| Something about software today feeling samey and churned-out.
| contingencies wrote:
| Added to https://github.com/globalcitizen/taoup ;)
| aorloff wrote:
| A huge amount of software is not designed. In fact, simply
| actually designing software instead of just allowing people to go
| hack away at things requires a culture around it.
|
| That culture usually starts at the top if you have it in your
| company, but occasionally you will just be lucky enough to have
| it in your team.
|
| So before you write some software, you describe it to your team
| in a document and get feedback (or maybe just your manager).
|
| If you don't do this, you don't really have a software design
| culture at your company. My rule was basically that if a piece of
| software required more than 1 Jira ticket, then create a doc for
| it.
| stego-tech wrote:
| My own version, from the world of IT.
|
| We continue to add complexity for the sake of complexity, rarely
| because of necessity. We never question adding new things, yet
| there's always an excuse not to streamline, not to remove, not to
| consolidate.
|
| We must deliver new features, because that is progress. We must
| never remove old systems, because that harms us. We must support
| everything forever, because it's always too costly to modernize,
| or update, or replace.
|
| It doesn't matter if the problem doesn't exist, what matters is
| that by incorporating this product, we solve the problem.
|
| We must move everything off the mainframe and onto servers. We
| must move every server into virtual machines. We must move every
| virtual machine into AWS. Every EC2 instance into a container.
| Every container into Kubernetes. Into OpenShift. We must move
| this code into Lambda. Do not question the reasoning or its
| value, it _must be done_.
|
| How did our budget balloon in size? Why are our expenses always
| going up? Why is our cloud bill so high? We must outsource,
| clearly. We must hire abroad. We must retain contractors and
| consultants. We need more people with certifications, not
| experience.
|
| Why is everything broken? Why is our data leaking into the public
| realm? How did we get hacked? We must bring in more contractors,
| more consultants. That is the only answer. We don't need internal
| staff, we need managers who can handle vendors, who can judge
| KPIs, who can identify better contractors at cheaper costs year
| after year.
|
| Why is the competition beating us? What vendor should we go with
| to one-up our competition? We must consult the Gartner report. We
| must talk to other CIOs. We must never talk to our staff, because
| they don't understand the problem.
|
| We don't like our vendor anymore. They raised prices on us, or
| didn't take us to that restaurant we liked for contract
| negotiations, or didn't get us box seats for that event this
| year. They _must_ go. What do you mean we can 't just leave AWS
| this quarter? What do you mean we can't just migrate our
| infrastructure to another competitor? That proprietary product is
| an industry standard, so just move to another one. What are we
| even paying you for?
|
| We checked all the boxes. We completed all the audits. We
| incorporated all the latest, greatest technologies. We did
| everything we were told to. So why aren't we successful? Why
| aren't we growing?
|
| ...ah, that's why. We didn't incorporate AI. That must be it.
| That will fix it all.
|
| Then we'll be successful. Then everything will work.
| tqi wrote:
| > We are destroying software by no longer taking complexity into
| account when adding features or optimizing some dimension.
|
| Yet: https://x.com/antirez/status/1885994950875046164
|
| The reality is that man's "unnecessary complexity" is another's
| table stakes feature. The post isn't entirely without merit, but
| most of it reads like a cranky old timer who yearns for a simpler
| time.
| meltyness wrote:
| Is adopting the manifesto a violation of the manifesto?
| FridgeSeal wrote:
| > Don't reinvent the wheel!" But reinventing the wheel is how you
| learn how things work, and is the first step to make new,
| different wheels. >We are destroying software pushing for
| rewrites of things that work.
|
| > We are destroying software by jumping on every new language,
| paradigm, and framework.
|
| Whilst I largely agree with the premise of the post, some of
| these points feel a little bit dissonant and contradictory. We
| can have stability and engineering quality _and_ innovation. What
| I think the author is trying to target is unnecessary churn and
| replacements that are net-worse. Some churn is inevitable, as
| it's part of learning and part of R&D.
| nj5rq wrote:
| > blog comments powered by Disqus
|
| Isn't this kind of ironic?
| meltyness wrote:
| You can't buy proprietary software. You can buy a specification.
| "my computer does this". If you're building software under agile,
| the outputs should be a hierarchical specification clearly
| traceable to code, the specification should remain clean, it
| could be simply the GUI in some rare, simple cases but that may
| be short lived, often the docs are an important part of the
| specification. Ideally, just a handful of high-level user stories
| that do not close.
|
| Without a spec, the world falls into disarray and chance, next
| you need QA tests, and security auditors, and red teams,
| salespeople, solutions engineers, tech support, training, and a
| cascade of managers who try and translate "want" into "does" and
| "when" and to understand and accept the results. Architects and
| seniors who are both domain experts and skilled coders as the
| single truth on what the GUI is even supposed to mean. Taking on
| varying levels of risk with contracts, hires or expanding and
| contracting the previously mentioned R&D units. That's not
| software anymore, that's consulting. It's so expensive and
| unsustainable that it's only a matter of time until you're the
| leg that gets gnawed off, which is inevitably the result, when
| burn and panic (or other negative factors) leads you away from
| turning pain points (like issues, training, or difficult usage)
| into ice cubes for a cocktail.
___________________________________________________________________
(page generated 2025-02-08 23:00 UTC)