4 ms·

Yes. We are increasingly working with a model where we have resources for free, and the most valuable resource happens to be developer time. If our tooling and

by vkaku 3y ago

Yes. We are increasingly working with a model where we have resources for free, and the most valuable resource happens to be developer time. If our tooling and efficiency is getting better, why would we not be able to automate a wide variety of efficiency improvements as mere compiler tasks and get away with it? It's not. The life cycle prioritizes process over product and real-life constraints, thereby making software engineering a drive-by operation. Many of our software engineering methods today are discardable and thus unsustainable as well. We need to bring back the notion of developer attention and stop relying on mere tooling for improving our software. Our tooling is only as good as we are, and tools are also written by oblivious software developers, after all. We need to have ways where software developers look to perfect their art, understand the basics, dive bit-by-bit and get back to improving their applications. As opposed to simply complaining that their Electron based application is slow. They have to work with employers and teams who allow them to do that, at least once in their careers. That may get them to understand a lot of issues better and will lead to better outcomes for themselves and everyone around they write software for. There are many things a disciplined person could do, yet discipline is hard: picking a few places to do this sort of work is a great way to start this transformation.

ajmurmann 3y ago
Is there any indication that any actual consumers of software care enough to justify the cost for increased quality? The market seems to reward features more so than reduced resource consumption, so it seems that that's what users want. I get that we as software developers want to use all the tools of our craft and build something beautiful and elegant, but it seems that few of anyone outside our craft care how the car looks under the hood. Sustainability and maintainability are a huge issue though that can kill products as development gets slower and slower. However, that at best orthogonal to things like resource consumption
- vkaku 3y ago
  If you're spurning customers away, very few will come back and tell you they are leaving. This is often the reason why developers seldom get it and embrace that signal. More features do not necessarily translate to better outcomes. Features will often be measured at a point in time. It has to be good enough for people to use a product and not inconvenient enough for people to run away. More development does not mean more usage. Imagine someone in utilities connected your home to a power supply and then decided to periodically change it just because they need to show that they work - and not to be useful to you. Would you like that? That sort of active development thing is found seldom outside the subscription based SaaS business. Case in point: AWS, you have dozens of services launched every quarter and maybe its developers there get bored and launch new services, yet most people use those few key services a lot and are happy to stick around as long as things don't break terribly. The issue is that we've come to liken features and bloat with usage. Then we assume our customers want that bloat and can afford to do so. Mostly at that point, companies are optimizing for their own development over customers needs. Over a period of time we get disillusioned that our bloated software is often what our customers need. Then when that doesn't work well, try explosive methods such as platform obsolescence. Thus leading to loss of sustainability.
- movpasd 3y ago
  I think consumers are trapped in a feedback loop precipitated by the rise of ad-driven software. From the perspective of an engineer, "consumers don't care about quality" — but what's really happening is that consumers have no reason to trust the quality of the software they use. Grab a person off the street and ask them about how they feel about the quality of the software they use at work, at home, on their phones, and I bet they would be quite unhappy with it, but feel that this is just the way software is. What consumer would risk paying £100 for software when they expect it to suck anyway? Without a demand for good software, suppliers are constrained to turn to alternate value streams like retention or data collection, creating worse experience for the users, and perpetuating the cycle. So this is all you say that you can't look at the market at a surface level and immediately draw conclusions about what people fundamentally value, because the structure of the market is path-dependent. What may seem like end-users caring or not caring about something might be more of a reflection of choices made within systemic constraints.

by vkaku 3y ago

ajmurmann 3y ago

Is there any indication that any actual consumers of software care enough to justify the cost for increased quality? The market seems to reward features more so than reduced resource consumption, so it seems that that's what users want. I get that we as software developers want to use all the tools of our craft and build something beautiful and elegant, but it seems that few of anyone outside our craft care how the car looks under the hood. Sustainability and maintainability are a huge issue though that can kill products as development gets slower and slower. However, that at best orthogonal to things like resource consumption

vkaku 3y ago
If you're spurning customers away, very few will come back and tell you they are leaving. This is often the reason why developers seldom get it and embrace that signal. More features do not necessarily translate to better outcomes. Features will often be measured at a point in time. It has to be good enough for people to use a product and not inconvenient enough for people to run away. More development does not mean more usage. Imagine someone in utilities connected your home to a power supply and then decided to periodically change it just because they need to show that they work - and not to be useful to you. Would you like that? That sort of active development thing is found seldom outside the subscription based SaaS business. Case in point: AWS, you have dozens of services launched every quarter and maybe its developers there get bored and launch new services, yet most people use those few key services a lot and are happy to stick around as long as things don't break terribly. The issue is that we've come to liken features and bloat with usage. Then we assume our customers want that bloat and can afford to do so. Mostly at that point, companies are optimizing for their own development over customers needs. Over a period of time we get disillusioned that our bloated software is often what our customers need. Then when that doesn't work well, try explosive methods such as platform obsolescence. Thus leading to loss of sustainability.
movpasd 3y ago
I think consumers are trapped in a feedback loop precipitated by the rise of ad-driven software. From the perspective of an engineer, "consumers don't care about quality" — but what's really happening is that consumers have no reason to trust the quality of the software they use. Grab a person off the street and ask them about how they feel about the quality of the software they use at work, at home, on their phones, and I bet they would be quite unhappy with it, but feel that this is just the way software is. What consumer would risk paying £100 for software when they expect it to suck anyway? Without a demand for good software, suppliers are constrained to turn to alternate value streams like retention or data collection, creating worse experience for the users, and perpetuating the cycle. So this is all you say that you can't look at the market at a surface level and immediately draw conclusions about what people fundamentally value, because the structure of the market is path-dependent. What may seem like end-users caring or not caring about something might be more of a reflection of choices made within systemic constraints.