The right to repair thing is a spectrum. On the one hand you have the John Deere inkjet model. But on the other end you have the normal car manufacturers who don't make it impossible, but who incentivize using 1st party repair. Are we talking about that being against right to repair? Because that feels somewhat hard to legislate.
E.g: A car has 1 year warranty. But the warranty is extended by one year so long as you service it with manufacturer, not a third party. This doesn't prevent me from servicing with a third party for half the price, but it might not be worth doing that. And I would think twice about buying a car which is only a few years old unless it's serviced completely at first party, due to issues that could arise with warranty claims.
Could legislation be made that says "If you repair at a third party, or even repair yourself, and you know what you are doing/do it according to the recommendation, then the manufacturer has to give the same warranty they would have if you serviced it at them"? Because that feels insane. The warranty is just a kickback for using their expensive service, getting you to the service place/showroom regularly etc.
I think something similar applies in many parts of the world, _but_ I also think that the response from the OEMs is basically "fight the warranty claims hard when there is third party service involved, and just honor the warranty with a smile otherwise". Basically malicious compliance is what they have to resort to. And as a car owner I'm lazy and afraid of conflict. So I happily pay X% more for the service to get the no fuss warranty (And the OEM shop is even happier).
In order to deny a warranty claim the US, the manufacturer has to prove the issue has been caused by a modification or servicing.
Why would anyone want to service their call at a stealership? The prices are unfair and the quality of techs is awful. Better to find a small reliable shop.
This is especially nice in the age of AI. I (the graybeard senior developer) does all the risky refactoring. I can take a performance issue and turn it into six regressions in half a day ($100). Then everyone is impressed when I let Opus fix these regressions in 20 minutes and $2 worth of AI.
No one notices when you cut 20% of some expensive process but cause no regressions.
An aerial bomb is equally indiscriminate. You make a judgement about the target value and the estimate collateral damage/civilian casualties and you fire if the equation is reasonable.
Same here. If it's a muddy square kilometer of trenches do you KNOW there are no civilians? No. But it's not indiscriminate. The target area selection is the key. You can't release an indiscriminate autonomus killer drone into a city of course. But I doubt it'll be long before these drones make target distinction of humans (Vehicle recognition is old at this point).
Just like with land mines it's the military value vs risk of civilian casualties that determine if it's a war crime or not. Some countries have signed the Ottawa treaty, but notably not the US or Russia. And the trend isn't going towards states signing the treaty but rather towards leaving it.
>
You can't release an indiscriminate autonomus killer drone into a city of course.
Already used in Gaza, only it operates with a hit list, which is also probabilistic. These Hamas linked operatives are most of the time also civillians most if the time.
> if in average you have 2 cars charging for 5 minutes every hour, you can draw 166kW continuously instead of having bursts of 1MW consumption)
You definitely need to have that to not load the grid with 1MW, but the question still remains what the capacity of the battery is. A charger that promises a 5 minute 1MW charge BUT which can only do it once per hour and then falls back to 200kW doesn't seem as special as a charger that actually charges a car every five minutes.
It's convenient to get going in 5 minutes. But the time you REALLY want the charger to be quick is when you are third in line to charge at that charger.
I was definitely using simplifying assumptions to get my point straight here.
Setting the actual parameters for such systems is an engineering job, I just wanted to illustrate that the goal isn't going to have the charging station off the grid during peak hours thanks to the batteries, and more about managing the burden you put on the grid.
Yeah that's why it probably needs to be more than 1 charge in the battery. Unless you do N back-to-back charges during peak time, the charger isn't utilized enough. And to do N back to back charges you need about N car batteries as buffer.
If you have full usage of your charger, then batteries are pointless anyway because you have steady usage no matter what.
But it's not a realistic assumption, at the very least the driver has to park, get out of their car, plug the car, spend some time on the payment interface, then unplug the car and leave.
So even in the maximum theoretical scenario where drivers are lining up at the charging station, your charger isn't going above 80% utilization. Using a single car battery, you can save 20% in terms of connection to the grid (you “just” need a 800kW connection instead of a 1MW one), and you aren't nearly as much of a nuisance to the grid as if you were having constant ups and down of 1MW.
In practice there will a be a trade off between how much you save in connection infrastructure to the grid and how much you spend on batteries, and this calculation will depends a lot on the usage pattern.
Yes it can't be used 24/7 for 5-minute charges because then the buffer does nothing.
But if there is never back-to-back charges then I'd argue it's also kind of pointless because when the speed most needed (when there is a queue) is when the charger starts going the slowest. The balance is to have N charges (say 3, 5 or 7) in the battery. That way you can churn through the peak with N charges (say 07-09) and then charge for several hours until the peak hour returns at 16-18 when you can once again at least serve the first few cars without falling back to whatever you can suck from the grid continuously.
> then I'd argue it's also kind of pointless because when the speed most needed (when there is a queue)
The thing is: with 5min charging, it reduces the amount of situations where there's a queue at all.
> That way you can churn through the peak with N charges (say 07-09)
Again, 9 batteries is just an hour worth of energy if car are lining up. The goal of such battery is just to smooth the demand spikes, not to get though peak hour.
> The balance is to have N charges (say 3, 5 or 7) in the battery.
I suspect this will depend a lot on the expected usage of the charging station (an maybe adapted later on if the usage doesn't match their expectations), as I said above it's going to be a full time job.
Validation to avoid mistakes is, as they point out, good. I'd even go so far as to extend it so that I reject those without any tld (without any dots) just because it's 99.999% a mistake and I don't care about the person who has ben@net. I'd also reject ip numbers.
Next is the spicy take: I need to consider WHY I am gathering this email?
If I'm gathering it for "marketing purposes" or any such cross correlation to other systems, then I'd also reject bob.smith+dontspamme@gmail.com. Or I'd keep both so you can do cross referencing on both the + address and the "raw" one.
That's not what the UK is demanding. They want client side scanning malware that breaks DRM, circumvents encryption and VPNs, and bypasses other security features in order to scan everything visible on your screen.
It absolutely doesn't. However, the argument doesn't work when it's about connecting the "is the user a kid" bit to the existing and constantly running object recognition (phone cameras already run skin detection all the time to set white balance), so people invent "third parties" and "report people to authorities".
But "Is the user a kid" is already a switch that I (a parent) switch on in the device and that the kid in question can't switch off. That bit seems like a solved problem?
Why would anything else even be needed in that space? The interest of parents and tech companies likely align here.
I spent most of the last two years making a rather large hobby project. A 3D renderer for cad/visualization. It's pretty hard and slow work because getting anything wrong is usually hard to debug. Get a sign wrong and you have a black image suddenly, with painstaking debugging following. I worked on it for evenings and weekends, probably totaling a man-month of work or so.
As a fun experiment, yesterday I asked a model to create this for me. It almost one shotted it. After a couple of iterations and 30 minutes I had made what I made over two years. The total AI cost (deepseek api, so entirely usage based) was $0.5.
Now, I didn't enjoy making this AI guided version. And I didn't learn anything. But terrifyingly it has removed the drive to make another 2 year project "by hand". The end result (the runnihg demo) was never the goal. But still I can't now make myself hand-craft what an AI can spit out in an hour for $1!
This is what bothers me the most. I'm old and senior enough that I don't fear for my job. But the AI thing just swallowed my hobby.
You knew exactly what you wanted, since you already built it. All decisions were already made, all tradeoffs reached. LLMs are definitely helpful, but try exploring something new with them and you'll slow down significantly.
Most of my time these days is learning about domains, not technical skills. I keep programming books around for references, but the books I read most are books that go deep into some domain, either technical like operating systems or network, or soft skills like planning, design and communication.
It’s kinda the old saying about $900/hr expert that only taps with an hammer. The price is not about tapping, it’s about knowing where to tap.
Not to mention the poster understands what the output is, what it's supposed to do, and can judge that it is the thing that they intended to build.
But this has always been a developer's work, it's understanding what is needed, translating it to working software, and judging the result, and doing so at scale, over time, and with other people.
Yes, and that's also why I'm really effective at using AI when the context is one I'm comfortable with. Still - it doesn't feel like I'm actually doing anything. The product was never the goal for me. The craft was. I feel like someone who always loved to be a blacksmith who is now in charge of a production line of 10 CNC mills that produce coat hooks. The fact that I know what makes a good coat hook doesn't really help make it a job I don't really enjoy.
You shouldn’t be bothered that someone else does your hobby better. It’s a hobby, it’s meant to be for you, for no purpose other than fun, experimentation, entertainment, what have you. The outcome isn’t as important as the process.
That’s my take on this, at least. I’ll never be very good at Scythe, or the most creative role-player, certainly never managed to do anything beautiful in pottery class (although the glazing is pretty).
> you shouldn't be bothered that someone else does your hobby better
I don't know, I'd feel this way a little.
if it's something that's not obvious how much effort goes into the underlying process, it can feel pretty deflating if the craft behind it has felt like it's eliminated.
I can't really think of a good example, but if my hobby was glueing precision glueing little 3d models, then suddenly the hobby has exploded because 3d printers have made it easy, it suddenly feels like it's devalued my collection of manually crafted plastic models
3D printing nonsense can be its own hobby! Let’s be happy that more people are getting back into hobbies over doom-scrolling all evening.
Aside: I had to get into puzzling to manage stress, my doctor actually ‘prescribed’ it, and hours go by while you mindlessly hunt for sky-blue pieces. There’s no point thinking about people that puzzle faster than you :)
I think we need to enjoy the process of things more. Life is precious. If someone else does your thing harder/faster/better/stronger, what are you gonna do? Doom-scroll? Nah, enjoy your special little thing.
Imagine taking up a hobby of drawing, then bemoaning the existence of a printer. Or learning spanish, and bemoaning google translate. Or trying out woodworking, and bemoaning IKEA.
I don't think painting and photography (Which was when painters perhaps feared for their jobs at first) are equivalent. If I paint, it's not because I want an exact "photo" of a person or scene. The fact that its painted by hand makes it fundamentally different from a photograph. With software, you can't really see that. It's compiled and you just see the end result.
How many of the learnings over the past two years went into the prompt that you gave the model? Is it possible that you wouldn't have been able to prompt it so well without those learnings?
Some, but actually surprisingly little. The thing is that my hobby projects are usually extremely "prior art". It's like "make a renderer (just like one that 1000 people have made before)". It's not novel. I just needed a renderer and none was suitable. But the AI knows exactly what to do with almost no context and almost no decisions.
I also don't fear for my job, but it's because I was already laid off 1.5 years ago, right at the start of this AI boom. :/
However, I love coding with the AI. I can get it to handle all the crap that I know what it should look like, but don't want to spend the time doing myself. Instead, I get to focus on making the thing work well and do what I want. I am so much happier coding with it than without it.
Now if I can just find a job to do it in, I'll be set. :/
So first off, I mean, of course you didn't, right? You had already learned most of what you were going to learn from this specific project by doing it by hand.
But yes, if you use AI to do projects that might have been at the edge of your abilities pre-AI, you will learn a lot less. The solution, I've found, is to get more ambitious until you're back to the edge of your abilities even with AI. You should be asking the agent questions like "has anyone tried?" and keep pushing until it isn't sure, and you're not sure you have any idea what you're doing. Then ask questions until you feel like you sort of know what you're doing, and verify your understanding by directing the agent to build.
I oscillate around that sentiment. And am very bruised by 2026 LLM capabilities. But at times there was a small positive effect knowing that the LLM found a path to my problem. Without even looking at it, it gave my brain more certainty that there was indeed a path and that I could then keep walking. And a few times it made me try to see if I could even be as fast by optimizing my thinking ans organisation (foolish I know but still).
You may be going through the same crisis that chess masters went through decades ago. But chess didn't die because engines were better, in fact there has never been more people interested in chess as today. Cheaters are annoying though.
> It doesn’t matter that the language you use is memory-safe, if you didn’t design for correctness or have no process that will eventually lead you to fixing all bugs.
After many years in the business I have come to a more pragmatic view. There is no meaningful way of distinguishing features from bugs. It doesn't matter that work tracking software usually does.
Once you realize that the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features", then you also accept that you will never be done.
If you have a bug to fix to weigh against a feature to add, which do you pick? The only correct answer is "The one that provides most value". And again we see that it's very possible - even likely - that fixing the last bug will _never_ be as important as adding more features.
I know this is probably not what the author meant. First of all "having a process" doesn't mean completing the process. Second of all, you can categorize bugs as being of a specific kind (The linked article under [fixing all bugs] actually only talks about failing asserts).
>Once you realize that the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features", then you also accept that you will never be done.
This doesn't make sense at all.
Your email software mangles my email. Or your media player randomly skips. That's a bug. No big philosophy needs to be hidden behind it. That your media player doesn't have the shuffle feature is not a bug. It's just an item on a wishlist.
>If you have a bug to fix to weigh against a feature to add, which do you pick?
Depends on the seriousness of the bug. If your disk backup software corrupts backups, I'd fix that, I wouldn't go add schedulled backups or encryption first.
If what you meant to say is that bugs and features are both items to prioritize when deciding work, sure. But they're not the same thing and are not hard to tell apart, so the metaphor doesn't work.
Grandparent is onto something. You can't define correctness without a spec. And since most business-oriented software, which most of us work with, isn't made against a comprehensive spec, you can argue that anything falling outside it is either a bug or a feature. 'If your disk backup software corrupts backups' has behind it a clean definition that's (pretty) unambiguous and you don't care about, since it's already outsourced to some cloud solution. But 'User finds it easy to buy more stuff' does not.
Also, mandatory Sussman reference [0], where he talks about correctness not being that important and gives Google as example, that just needs to be close enough and not disastrously incorrect + interesting stuff around engineers confusing brittleness with correctness.
>Grandparent is onto something. You can't define correctness without a spec.
Sure you can. Correctness doesn't mean "follows a spec", it means "It does what the developer intended it to do without problems".
I mean that casually and within reason, it's not supposed to be a formal statement checkable by proof checker. z
I don't need a spec to know that e.g. my email client has a bug if it crashes when I try to make something bold. The presense of the "Bold" formatting button means it should support it, spec or no spec.
I did not mention 'formal statement checkable by proof checker' anywhere. Correctness requires some criterion external to the implementation. Write it down and it's a spec. If you do not write it down and the behaviour is not one of the already-standard failure classes like crashing, corrupting data, losing work, then there is no principled way to classify it as a bug rather than an intended feature or tradeoff.
My read was they were not saying they’re actually, literally, the same, but for the purposes of prioritization there’s no point in differentiating feature from bug when you use the same “how does this impact my products value to users” as the deciding factor for what gets scoped.
It’s an interesting insight but I’m also not sure it’s valuable in practice. Sort of like “we’re just bags of chemicals that tricked rocks into thinking”.
>but for the purposes of prioritization there’s no point in differentiating feature from bug when you use the same “how does this impact my products value to users” as the deciding factor for what gets scoped.
Then they could just say that, not that in general "a feature is the same as a bug" without qualification.
There are things that are clearly bugs and clearly features. And a lot of things that are somewhere in between. It’s not black or white and as such perhaps not worth categorizing?
Especially with dramatic processes like ”always fix all bugs before implementing any feature”.
>There are things that are clearly bugs and clearly features. And a lot of things that are somewhere in between. It’s not black or white and as such perhaps not worth categorizing?
I appreciate the exercise of taking a step back and looking at the abstractions built, really I do, sometimes people take a liking to certain bugs, sometimes people despise features as if they were bugs, but this feels a bit of a Loki's wager situation: https://en.wikipedia.org/wiki/Loki's_wager
At the very end of things, bugs and features are just things the software "does", but I reckon it's worth it to sit back and think about the intentional and non-intentional result of the application of a design.
When you're trying to prioritize work, bugs and features are the same - they're both demands for developer time. I don't think they were saying anything more than that.
You want to say that they're not the same kind of work? True. And yet, when you're allocating work, that doesn't particularly matter.
>I don't think they were saying anything more than that.
Well, they did claim something more though though: "the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features".
Well, no. Take TeX as an example. It does what it does. Bug are bugs, and they can fix them. Lack of features are not bugs. They can absolutely close to fixing all bugs. And some small programs can be 100% bug free (or close), without considering any rando's future request (which can expand to the thousands unrelated asks you never planned it do) as "a bug".
A bug means that there is a feature, but it's not behaving as was specified. (Or expected, or as it used to ... but clearly a difference to something, not to nothing)
It doesn't matter whether to the end user that's indistinguishable. It is for us, the professionals.
It's the same as with any other profession and domain-knowledge.
If my heater doesn't work but it used to work, that's a bug, a regression.
If it doesn't integrate with my smart home, that's not a bug. It was never a feature to begin with.
> If you have a bug to fix to weigh against a feature to add, which do you pick? The only correct answer is "The one that provides most value".
I agree.
> And again we see that it's very possible - even likely - that fixing the last bug will _never_ be as important as adding more features.
Depends entirely on the project and the revenue stream. I've open sourced code which I consider done. It does what it should do and I won't any more features to it.
I will however fix bugs within the existing functionalities.
Some times there is, and in many cases there is not. Distinguishing a feature from a bug requires having some kind of spec. In some cases you can have obvious sign the behaviour is unintended/not desired, but in other cases it's not so easy.
For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request.
Customer mumbles and requests the same thing as a feature request, not a bug report. They never understood what the difference was though. They couldn't print. Program bad.
Now you implement the printing feature. There is an infinity of things to handle there. You add the 99.9% case which is basically regular printers, perhaps normal paper sizes. You however don't throw in things like document splitting (sending different pages to different devices based on capability). You have to stop somewhere. None of this is specified, however. None of the limitations are communicated to users. But you added the feature - in some sense.
Then a customer with a 1970's pen plotter files a bug report that your new feature doesn't work on his device. Will you fix his bug? He's the only one on the planet with the problem. Is it a bug or a new feature? To him it's _clearly_ a bug. To you it would _clearly_ be a new feature to support pen plotting. You could argue the semantics of whether this is a bug or a feature until the sun goes down and it doesn't really matter. Either the fixed bug/added feature has enough value to be done, or it doesn't.
A key takeaway here: this isn't merely something that appears in the perspective of the user vs the developer. The argument about whether you actually have a "Bug" because you stopped short of implementing every kind of printing known to man is one you could have with your PM too. He likely didn't even consider that. But does that make it not a bug?
There is a pretty clear and important difference between a program that does something wrong, and a program that just doesn't do something somebody wants.
"You don't support printing", "pressing the print button doesn't print", "pressing the print button crashes the computer" and "pressing the print button lets an attacker get root access to the system" are all different and it makes sense to distinguish them. (The first is a missing feature, the second and third are different kinds of bugs, the last is a special kind of bug we call a security vulnerability.)
That distinction might not be useful to end-users, but it's useful for the people building the system! If you want to care about quality, committing to a strategy like "we will not add features before we fix known bugs" is totally clear, reasonable and effective. There might be some frontier of issues where it's hard to make a distinction, but that just means there are subtle edge-cases, not that the whole concept is undefined. A lot of perfectly cromulent concepts have edge-cases! You can just decide those on a case-by-case basis; if it's actually so close as to be legitimately confusing—it's not just feigned ignorance or political posturing—which side you choose probably doesn't have much of an effect.
This does depend on having a reasonably clear idea of what you're building, but that "reasonably clear idea" does not have to be anywhere near the detail of a "full spec", much less anything formalized. To me, that seems like a baseline you'd need to build quality software at all, and hardly an unreasonable thing to expect. And if most teams can't manage, well, it's just another explanation for why most software is crap.
> There is a pretty clear and important difference between a program that does something wrong, and a program that just doesn't do something somebody wants.
Your argument hinges on all parties agreeing on what "wrong" means. Take a step back and consider that parties do not agree on a common definition of "wrong." Does "wrong" mean a gap between the spec and the implementation or a gap between a reasonable user's expectation and the implementation? If one party assert that it is clearly the former and the other party asserts it is clearly the latter, does that make the situation more clear or less clear?
There are some really obvious things that are definitely bugs. If login doesn’t work if your email address contains the letter “e” when the expectation is all valid email addresses should work, then that is a bug. It isn’t “indistinguishable from a feature”. If clicking a button in your accounting software consumes all the RAM on your computer and causes it to crash, then there is no universe or agreed upon definition that would consider that a feature instead of a bug.
Just because you can't get everyone to agree does not mean that the concept is not well-defined or clear. People can and do disagree over almost anything. That could just mean that one side is wrong and the other side is right, even if it is difficult to determine which is which... or simply difficult to navigate the underlying politics regardless.
Besides, in your example, either kind of gap could be a bug or a missing feature. It's a totally orthogonal question.
>Your argument hinges on all parties agreeing on what "wrong" means
No, it just hinges on common sense. "All parties" are never gonna agree on everything.
There will always be customers that demand whatever and treats its lack as a bug. Doesn't make it a bug anymore than me asking for a free glass of wine with my meal and not being given any is "injustice" - when the restaurant never promised any.
>Some times there is, and in many cases there is not. Distinguishing a feature from a bug requires having some kind of spec. In some cases you can have obvious sign the behaviour is unintended/not desired, but in other cases it's not so easy. For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request.Customer mumbles and requests the same thing as a feature request, not a bug report. They never understood what the difference was though. They couldn't print. Program bad.
Any software has a spec. It might not be publicly written, but you have in mind what you build and which features it supports. And software that's sold has lists of features, presentation pages, and trials for people to see its features.
If some random user can't tell a bug from a feature, that's on them.
You must use some very small software if what it does can be held in the mind alone. Try working on something with hundreds of thousands to millions of lines of code. Have it evolve over 5 different PMs. Have it serve enterprise customers. Even something simple like
* Supports FooBaz
Now means, supports what feature set of FooBaz, what particular versions of FooBaz, does it support the fork FooBar that have the market quickly migrated to, what about the bugs in FooBaz that only show up when using your program.
Users are dumber than you think, and when they pay you a lot it's never on them.
Not even a development team can (or should!) be able to agree on whether something is a bug. Just because there is never a complete spec. It’s a mental state of the team. Or expectations among stakeholders.
> For example a customer reports a bug, your program can't print. Oh, you say, we never even had that feature! Please post again, as a feature request.
As a sidenote, I dislike it when a vendor makes me care whether something is a bug report, feature request, or support query prior to filing it. I'm willing to make an assessment on whether the query is of a public or private (if I'm unwilling to publish publicly, sensitive customer info, potential for vuln et c.) nature but beyond that I don't want to spend any time arguing about classification.
An unuseful-in-99%-of-cases definition of bug would be "any behavior that is not in the spec is a bug". But that would mean not shipping fast and breaking things. And having a spec.
A bug is a feature that does what the code says it should do, not what the requirements say it should do (or shouldn't in the case of most bugs). When you understand that there's no difference between a bug and a feature in the code. They're both just code.
It's a correct statement, but when you're talking about memory safe languages it's true that memory safety helps you avoid writing code that doesn't do what you were expecting, so I'd still suggest memory safety matters for reducing the number of bugs.
> A bug is a feature that does what the code says it should do, not what the requirements say it should do (or shouldn't in the case of most bugs). When you understand that there's no difference between a bug and a feature in the code. They're both just code.
You're twisting very hard the definitions here. A bug is a behaviour different than the one intended, it is not tied to code whatsoever. You can have bugs "in the code" that happen because of faulty hardware, or a solar flare.
Unless you work in an industry where solar flares should be taken into consideration, the code and requirement can match and you still have the (protential) bug
I read it as an argument from the end user’s perspective. Kind of like this:
- trying to do X, getting software error: bug
- wishing the software did Y, even though it’s not implemented: bug
Indeed there are people who think like that, but usually they are people like my grandparents, whose level of software understanding boils down to “the Desktop is where I play Solitaire” and “Internet Explorer is the literal internet”.
That's the simple version of it yes. I outlined a more complex version of it in a parallel answer. In short: lacking a complete specification of what to do, it's often impossible even within software teams to tell whether something is a bug.
And you never have a complete specification of what to do.
And a developer doesn't have to give the same semantics as the user, anymore than a medical equipment manufactured needs to consider its products based on what each random patient wants and what misconceptions or urban legends they believe.
> There is no meaningful way of distinguishing features from bugs.
Especially when you implement it exactly as directed by a project manager. Everyone forgets why it was done the way it was done, and then the same project manager asks for it to be "fixed" despite it being the way they wanted it in your original ticket.
Perhaps you have framed this overly strongly, but I think I get what you mean.
I have worked in companies where "X is not complete" would be logged as a bug. Even beyond that, non-completeness often leads to behaviors, especially as users bed in around non-complete interfaces, that are obviously bugs, crashes and the like.
If software represents a theory, any expansion in that theory (new features) will tend to lead to non-completeness, which will tend to lead to bugs. This is almost a mathematical certainty.
Engineering around this implies restating your theory, and thus performing partial or total rewrites of your software, quite regularly. It's not as crazy an idea as it sounds, I'm sure there are architectural patterns that make this manageable.
By "The one that provides most value", do you mean in the short or long term? Very often, in my experience, prioritizing so-called "quick wins" only quickly wins the codebase more tech debt, that puts the project on a sure path to development hell.
Very few of them have worked on a single system for more than four or five years, and have no idea what their decisions cost after they left. Many have joined a project after four or five years and suffered from those decisions, but they don't actually know why the decisions were made - how things looked at the time those decisions were made - and so they can make the same mistakes in their next greenfield project.
Of course, some systems have to ship at all costs or there won't be a second or third year, so judgement is still required.
But a lot of experienced people still underweight the costs of having lots of "low impact" defects.
"There are two ways of constructing a software design: One way is to
make it so simple that there are obviously no deficiencies, and the
other way is to make it so complicated that there are no obvious
deficiencies."
> I have worked in companies where "X is not complete" would be logged as a bug
I've come to realize it's all about perspective. Something from the engineering stand point may not be a bug because there's nothing to fix.
But the user might be having a bad experience because of that so it must be a bug.
In the end, the user's perspective might be the less-wrong one.
>There is no meaningful way of distinguishing features from bugs.
From a user perspective, a bug is when behavior deviates from reasonable expected behavior.
From a dev perspective, a bug is when the code actions mismatches the mental model (aka spec if it exists, else a reasonable mental model of the system).
A bug becomes a feature when it becomes expected behavior.
When a program clearly deviates from its spec, would you be okay with calling that a "bug"?
There's always a gray area of what's intended by the spec, but a program can absolutely and blatantly deviate from the letter of the spec, and they often do.
This distinction seems worthwhile to me, because it means that something someone already relies on does not work (anymore), even though reasonable people would agree that, according to the spec, it should.
Absolutely would. But if we can categorize 1/3 of defects as ”bugs” 1/3 as ”missing or incomplete functionality” then there is 1/3 in the middle which we can’t decide. So the dichotomy is kind of weird, and making ”rules” and processes about this categorization is probably not worthwhile.
At least not worthwile for the purpose you have in mind. Okay, now I understand better what you mean, something like: for some purposes, there's not much to be gained by distinguishing between "bug" and "feature", one major reason being that there is no clear boundary between the two.
I first read your original comment in a much more absolute way (there is no distinction at all, and it never makes any sense anyway), which is quite easy to disagree with.
E.g: A car has 1 year warranty. But the warranty is extended by one year so long as you service it with manufacturer, not a third party. This doesn't prevent me from servicing with a third party for half the price, but it might not be worth doing that. And I would think twice about buying a car which is only a few years old unless it's serviced completely at first party, due to issues that could arise with warranty claims.
Could legislation be made that says "If you repair at a third party, or even repair yourself, and you know what you are doing/do it according to the recommendation, then the manufacturer has to give the same warranty they would have if you serviced it at them"? Because that feels insane. The warranty is just a kickback for using their expensive service, getting you to the service place/showroom regularly etc.
reply