Posts by doublelayer

World's first RISC-V laptop with Ubuntu preloaded touts AI smarts and octa-core chip

Re: There may be trouble ahead.

"Just get on and release a Pi PC, without any AI BS wasting cycles/amps. It may well be the PC replacement that people want."

It's not. The people who wanted and were able to replace their PC with a Raspberry Pi have done it. A few of them tried to do it with the first few versions. Having used the same models, I doubt it worked very well. As of the Pi 4, it works much better. With the Pi 5, it should be even better. Nobody who wants to do that is incapable of installing that as their PC. I'm not even sure what other steps you think need to be taken to go from where we are now to having "a Pi PC", because it's likely to be a Pi in a box, and people are pretty capable of putting those together.

Meanwhile, the issues for everyone else will not be fixed by a Pi. There are some people who need more performance than that in their desktop. The Pi won't do it. There are some people who must have Windows. It can do that, but not very well, and not without some tweaking. There are some people who don't like some of the compatibility issues that the Pi has, and they'll find that running Linux on something else avoids some of them. Anyone who would know to buy a Pi PC either has considered using a Pi as a desktop or easily could, and having considered it, they either can replace it already or have a technical issue that will prevent them from making that choice.

Rivals and legal action cast shadows over Windows on Arm market

Re: crippled with Windows

Except that most of those applications will work the same. If they want local Office, there's been an ARM build for that for years. More and more tools that have Windows builds have started to have ARM binaries, and for anything open source, you can compile it yourself. Their emulation for X64 is also markedly improved, so if you need an old application that isn't being compiled the chances are high that you can run it in emulation with less battery life, but otherwise little difficulty.

There are a few situations where it won't work. If you need a driver for some old hardware, emulation won't do it for you, so you won't see Windows on ARM devices taking over for old X86 machines attached to even older hardware. If you need a lot of performance out of an application that isn't compiled for ARM, that won't work well either. There will undoubtedly be some people whose use cases would not be possible to run with an ARM machine, but that number is lower than you'd imagine.

I haven't bought any Windows on ARM machines and I don't really want to right now. They have an advantage in battery life, but sometimes I need higher performance than the high-end ARM laptops can provide and don't want to achieve it with a remote connection. I also value being able to run Linux on my hardware, and when I say that, I mean any version I want, not the one that might support my hardware.

I think that's what ARM's been hoping for. Qualcomm is getting a lot out of those designs, so if ARM's license complaints have merit, it wouldn't be surprising for Qualcomm to pay them to let them keep their designs. Qualcomm must either think that they can defend against those license problems more easily than ARM thinks, or they're banking on ARM choosing to give up at the last minute rather than suing a large source of revenue.

Study finds 268% higher failure rates for Agile software projects

Re: Strawman Arguments always win...

And if one doesn't bother to read the counterarguments, one fails to convince anyone that one is correct after all. We've had the "if it didn't work, you didn't apply the magic right" people already.

A lot of the comments here point out actual objections to Agile, as in limited issues that apply in particular situations. Maybe you could explain why those are incorrect? Crazy as it seems, a lot of us have read the manifesto and the list of principles and have a real basis for our critiques. I think many of the bad uses that claim to be Agile are doing things that you and the other authors did not intend. That is not the case for all of the bad applications. Even when it does apply, that doesn't automatically mean they weren't doing Agile. There are many things you wouldn't like which your manifesto does not recommend against.

Re: > it feeds into the suspicion that the Agile Manifesto might not be all it's cracked up to be.

"There is no hook. The manifesto is not required to give precise instructions, period. It's a couple of good ideas that some people wrote down. That's it."

The manifesto is required to explain itself if it wants to be understood. It does not. It is required to give enough detail in its ideas so we know they're good. It did not. Your argument is as easy to defend as saying that it's a collection of bad ideas from people who don't know anything about how software is designed? Do you disagree? You easily can, but not based on the content, because it does not provide enough detail to prove whether they work or not.

Me: Recommendations opposed to plans, documentation, and formal processes in general.

You: No, they are not. The manifesto prohibits neither plans, nor documentation. Nor does it prevent it's implementation as a formal framework

There is a difference between "oppose" and "prohibit". I said "oppose". It does. People have misapplied this by doing even less than the authors probably intended. I say probably because, once again, the authors provided insufficient detail to know. For all I know, this could be exactly what they were going for. All I know for certain is that people claiming to follow Agile are doing an insufficient amount. Whether that was intended or not is not something I or you can prove. If I want to tell people they're doing something wrong, it is incumbent on me to explain what, in detail, they were doing wrong and how to do it differently. A slightly wordier version of "work better" is not sufficient in that regard, nor is saying that anyone who didn't improve was, by definition, not working better and thus that I'm not responsible for what my statement caused them to do.

Re: From what I've seen....

Exactly, and that should be what they do with software as well. Either you need software that has already been written, and if you can't find one then you can ask someone to help you find it. If you can't, you should go to someone who can take your requirements and help design what you need. For instance, I know a guy who needed to have a custom-designed house because he uses a wheelchair. Sure, you can retrofit an existing house and make that work, or you could move to a place where houses are already well-designed for it, but if you don't want to deal with the difficulties each of those brings and you can afford it, then designing one from scratch can work. It would not have worked if he failed to mention that until the first designs were drawn up and someone was building it.

Unfortunately, that happens all too often when people are describing software. They assume that you know that there is a requirement that they didn't state, or they think they stated it and probably did but not in sufficient detail that you understood what it meant. It doesn't even have to be something as big as my analogy. This is why you either have to figure that out at the start or stick with the customer through the development, constantly getting their approval or feedback on things. A lot of people who claim to do Agile aren't doing that latter version, which Agile recommends, and therefore they don't get what the customer wanted. There are a number of reasons why they don't, and one of the main ones is that the customer doesn't want to. However, they need to recognize that they either need to make the customer do it anyway or they need a process that can work without it, and skipping it but continuing to use the process that requires it leads to substandard results.

Re: From what I've seen....

You can have them as long as you take the management with them. The users have a limited understanding of what they want, which is not necessarily the same as what would be of most benefit to them, but making the time to properly understand what they want and why they want it before I start writing tends not to get prioritized. Fortunately, I'm no longer in the position where I was simply given tasks without anyone explaining who wanted it or why, missing all the important details and I couldn't figure out who to ask for them.

Re: Next Week

When I work somewhere with technical writers to do that, I'll keep that in mind. Where I've worked, there aren't any, and if I ask why not, the same line might get trotted out again. If they can't be bothered to have me write a little of it, even though I don't have to explain it to anyone, why would they hire someone to do it? That would take an extra person and probably at least as much time from me.

Re: Interesting...

"I often wonder whether our use of IT blinds us to the actual effectiveness of the processes it replaced."

Probably, but at least part of that is due to users who use the familiar workflow rather than the better one. Yes, they may be able to demonstrate that the real problem is the software not doing something it needs to, but in other cases, the software can do things but someone won't learn it. Not every system that didn't get switched is because the software isn't fit for purpose. Inertia is a big factor, and there are various things we can do about it, from training to more information about why this improves things. If we assume every failure is a quality problem, we may be punishing ourselves for the wrong thing when what was needed was a better introductory training on the new option. Even if it is a quality thing, it could be due to bad programming, good programming of a bad design, or good design of a bad process, and you won't fix the situation without figuring out which.

Re: What I Have Never Understood About Agile......

It can be very useful if the conditions match, specifically that the software has a lot of user*-facing features and the user is actively working with you to get it. The point is that, although they've specified a new thing and you say they'll get it in a year, you can actually show them parts of it every month or so and get their feedback. If they want something developed in the first month to be different, you can change it in the second month. That works badly if you deliver the whole thing in ten months and they decide they want it changed. In the latter case, you usually have to refuse to change it so they can have their software on time, whereas if you can change it quickly, they can get something closer to what they want and still on time.

The problem comes when the user isn't checking on these things. Every month, you send the next development version to a manager who doesn't use it, the manager forwards the email to someone who either doesn't use it either or does, but they're too busy using the old version to help check on the new version, and the developers think everyone's fine with it when nobody's looked. Doing this well effectively requires that the user has an internal beta team, not to catch massive bugs (although they might and that is helpful too), but to report where they would like things to be designed differently. If they are unwilling or unable to do this, then this method no longer works and the developers need to use a different method to ensure their design matches the requirements.

* User in this case may be internal or external, and it may be at various levels. Other programmers can also be the user. In fact, that sometimes works better because hopefully they understand the importance of testing incomplete versions.

Re: Impartial study or not?

I agree with you there. For all the problems I've discussed about Agile, I'm not convinced that this overwhelming condemnation of it is accurate. I'm pretty convinced that there are at least a hundred different processes being called Agile, so there's no way they can be accurately averaged and compared to anything else.

Re: Software is hard...

This really depends what the criteria are for splitting a task. I can easily split lots of tasks into really tiny pieces, and each of them can be done quickly. I don't often do that because it just adds more work to manage tasks without providing any more feedback.

Consider as an example a project I have been building recently. I am the only programmer on it. In order to reach my last test version, I had to build lots of little components and link them together. It would be very easy to split the task into a list of components, then check each one off. The problem is that, when I have written two components and have seven to go, the code still can't produce a result that it couldn't before from the perspective of the users. Until all nine are written, the intended behavior doesn't work. I can finish each one in a short time, but I can't produce an observable improvement until they're all done.

But fine, we're not just looking at the user's perspective. What if this was a team project and people could see the results of finishing one component? It would work in this case, at least somewhat, because the components could be worked on in parallel. The problem is that, by developing multiple components, it would free me to change the design a bit to make improvements. If I split all of these and told other team members to do some of them, there might be clashes when they either didn't have the room to improve or where they proposed improvements that required us to delay our work to work on the interface. Not to mention that, for more complex software, there can also be tasks where the code is not of use to other developers until all parts are written and dividing it would be counterproductive. If it's just about reporting progress, those dividing lines can be set. If it's about having a new shippable version every sprint, there are tasks that are not served well by imposing that requirement.

Re: Overhyped fad proves disappointing

Possibly the reason you're getting disagreement is that "devops" is another one of those words that a lot of people use but they all mean something different and everyone else doesn't know what it means in any given scenario. I've heard it used to describe the following things at least:

1. The same people build the application and manage the servers on which it runs.

2. The same people build the application and manage the environment in which it runs, but someone else runs the server. The dividing line between server and environment can be figured out at a later point, good luck.

3. Different teams manage these things, but they have frequent meetings.

4. The people managing servers should do it with IaC tools that are more similar to development. Who cares what the application developers do.

It's not surprising given these four that opinions on how good it is might vary widely. There's a reasonable chance as well that you have a fifth definition.

Re: > it feeds into the suspicion that the Agile Manifesto might not be all it's cracked up to be.

"True, because that's not the manifestos goal. It points out an, at the time, alternative and new approach. Its a guideline and Idea, not a Step-By-Step cookbook on how people should do their job."

You're trying to let them off the hook again. It's not a guideline. It's at its most benign a statement of the obvious. It's as if I made a new code of moral ethics which reads in its entirety "be kind to people whenever possible unless absolutely necessary". You can't argue that my code is wrong, even if you think it probably is, because I have not bothered to define "kind", "necessary", or even "absolutely".

At its less benign it continues to be hopelessly vague but does make some recommendations. Recommendations opposed to plans, documentation, and formal processes in general. Without expressing any limit, reason, or details, they should not be surprised when those recommendations are followed too strongly. I'm not even sure if they understand that's a problem.

When I say rules, I don't mean about the structure of the thing. Agile doesn't have to talk about when and how you hold meetings or what the organizational chart needs to look like. That is not in the scope. But if they say that they want people to welcome changes late in the process, they should absolutely specify how they think that should be balanced against the fact that, if you change everything late in development, you will not be done by the original deadline. Should you limit the changes you accept late? Should you be open to moving deadlines? Should you maybe try to prevent there being so many changes by doing something earlier in the process? If so, what should you do and when should you do it? They should have answered these questions if they wanted to be understood. Since they did not, misunderstandings are partially their responsibility.

Re: From what I've seen....

I don't think that's fair either. Users know what they want, but even if you remove the managers and talk directly user to programmer, which I have done, you don't get the information without lots of effort from both parties. They understand in broad terms what they want, but there are two important gaps:

1. They only understand the surface layer of what they want, not all the components needed to build it. By components, I don't mean the technical details, but parts of the plan. They understand that the following pieces of data need to be collected, and stop there. They don't think about what the computer should do with the data once it has been collected. The form to collect it is what they can see, whereas the backend automation is not, so it often slips their mind. You have to remind them and step through the process manually to figure out all the things that should happen to the data once you have it.

2. They understand at least that part of the need, but they are not good at expressing it. Even for the parts they have already planned out, they tend to omit crucial details and assume that, because they know it, the programmer knows it. You have to break this down and ask lots of little questions, or you have to make assumptions to fill in the gaps. In my experience, the best relationships come when the programmers are capable of making those assumptions and it works well, but the worst teams are when the programmers aren't capable of doing it and do it anyway, so you have to be really careful at that line.

There are two approaches that tend to work with this. You can plan out every detail of the program through weeks to months of painstaking, boring meetings between the devs or someone dev-adjacent and various layers of the customer. The customer doesn't really want to do this because they don't understand why so much detail is necessary. It's not the fastest or most efficient, and there will inevitably be some gaps even at the end of this. It does limit the number of gaps at the end.

The other is a more agile method, and one I prefer if you can get it. You have some sessions with the customer to make part of a plan, build that part, and continue to iterate. If you have a customer who works well with this, then you can build things quickly and pivot fast if their requirements are different than you imagined. However, it does require that people who know what they're doing continually test it. The developers or QA if you have one is testing to make sure it doesn't break, but the customer has to test that it does what they expected it to do and that you know if it doesn't. It is easy to just assume that the customer is testing it and take no news as good news, but not the best method.

Re: The comments prove Agile is misunderstood

"TL;DR: Maybe instead of blaming your failure on all the principles you violated, you should blame your incompetence! If your "agile" project fails, you were not Agile."

Are you trying to make people hate Agile? If not, the sentences I quoted were a very bad idea.

A lot of failures in project management are not the fault of the Agile philosophy per se, even when it is used to justify the bad decisions. That doesn't make the principles blameless for the problems they can and do cause. You have attempted to elevate them to a position of faultlessness which nothing can live up to. You have further demonstrated that you are unwilling to consider that there may be any problems whatsoever with them. The rest of the world knows that, even if it's something they think is pretty good, that everything has flaws somewhere and will only improve if those flaws are identified and corrected.

If you want to reply to people pointing out what they see as flaws and explain why, in your opinion, they are not flaws, they aren't related to Agile, or they aren't as bad as we think they are, we might get somewhere. If you reply to every flaw and say that, although we've drawn a direct link from it to something core to Agile, it's totally unrelated but you can't be bothered to explain why, then nobody will be convinced. Here are some examples where you have misconstrued points and ended up in error.

since the primary measure of progress in Agile is working software, how do you manage to never have anything working along the way and expect on-time and successful delivery?

Not what happens. People have working stuff along the way. The customer wants something different, but there's not enough time to change from what they said they wanted to what they actually want. They will either get what they wanted late or they'll get not exactly what they want on time.

For example, one is having self-organizing teams, meaning the teams decide the best process to get the work done. If your "agile" project is failing, then you didn't organize well, did you?

So that's the only reason in your mind that a project might fail? I would think that it's pretty obvious that lots of other things could cause project failure. As an extreme example, if an asteroid hits an office building and wipes out some teams, then your organization is not at fault for the productivity decline, is it? As a more realistic example, if you've organized to build something which gets changed late in the process, it is not the fault of those who built what they have now that the final product concept is different and isn't ready.

Re: Next Week

they final assertion in the Manifesto is that there is more value on the things on the LEFT but it doesn't mean there is no value on the things on the RIGHT.

Yes, I know. That has not stopped people from putting too little value on the things on the right, and we shouldn't be surprised because those principles were not elucidated. Never in their list of principles do they explain in detail how to do any of the things they suggest, and when people try to stick too closely to the principles, they end up overshooting the mark.

If good documentation is necessary for success in your project, why would you let a misunderstood "methodology" kill a requirement? (And Agile is principles, not a project management methodology.)

Because people didn't ask me. They decide what they're going to do, and they cite Agile as a reason if I question it. I am just one programmer on the team. I can't change it, not that what we need to change to is a similar thing with an easy name and list of rules. It's not that Agile is itself good or bad, because nobody does Agile the same way, but it makes some things very easy to do wrong.

Re: > it feeds into the suspicion that the Agile Manifesto might not be all it's cracked up to be.

"The Manifesto is fine. The problem is how the methodology is sometimes applied."

I'm not sure I can agree. The application is most definitely responsible for some of it, but the manifesto provides their excuses and doesn't even try to direct them away from those misapplications.

In larger forms, the manifesto says a lot of obvious things. "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." That's great, but it doesn't actually tell you how to do it, so it doesn't tell companies that they're doing it wrong. Where the manifesto does make a recommendation that can be applied, it's things like "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." Of course, a project shouldn't ossify and refuse to make minor changes at the end because it's the end, but this statement is more extreme and is frequently interpreted as "start over whenever the customer asks you to even if it means wasting months of work". Then they act surprised that it's months later than the customer wanted it. This is more likely to happen because they read "we have come to value: [...] Customer collaboration over contract negotiation[,] Responding to change over following a plan" and so they don't bother getting the design right in the first place. The customer's happy, because they don't like doing that design process. They see that there are new builds every few weeks and that seems great because "yay, there's progress", but they don't test them. Developers are happy because the customers are getting what they asked for and surely they're good with it, after all that design's been in the test versions for a couple months now and they've not complained once. Then the project extends six months over asking, everyone gets unhappy, and the contract determines who has to pay for this and someone gets very unhappy.

The manifesto, without being explicit about these things, is at least partially responsible for this. If the people who wrote it knew about these problems, then they failed to describe or even mention them in their writing. If they didn't, then they probably weren't great at designing a new paradigm. The companies who applied it are responsible for each of their failures, but I don't think it is fair to say that they could have applied the manifesto properly and gotten around their problems.

Re: Next Week

I think at least some things can be blamed on the devs. I have met few devs who like to write documentation. While I don't mind doing it too much, I'm always careful not to announce that because I don't want to write everyone else's documentation (so I do mind it at least somewhat), and I've been in a situation where I was asked to do so because I was the only one who documented my stuff without being asked ten times. I think the "working software over comprehensive documentation" line has been among the most damaging, and that sounds exactly like a thing a developer might have inserted.

Re: Correlation or causation?

A lot of the people don't get to choose their paradigm in any case. As a developer, my management decides what things will be, and they don't ask for my opinion. Also, it's not as simple as selecting one from a menu. If choosing something else with an easy name was an option, then maybe we developers could get together and demand that "We refuse to use Agile. We want NewCoding." That doesn't work because there's lots of pieces of Agile and no team actually uses a standard version of them. They use whatever they already want to do and call it Agile.

Re: From what I've seen....

That's when the client has been clear about what they want before construction started. If they haven't, then you have a different situation that more closely matches the typical software development process. Agile and the developers and managers who recommend it can take some of the blame for that, but the customer gets some of it too.

Customers often say "I want X for Y amount in time period Z", but X is often very brief. X might just be "a database to track [something]". The devs have to figure out how to turn a generic request into something that actually does what the customer wants. The analogy to construction is more if I just said "I want a house. Four bedrooms. Get started.", but after they had built something, reacting with annoyance that they hadn't built in the style I had imagined.

The customer can specify all these details up front, but some don't try and some try and fail to do so properly. That's why I prefer to have them in the loop, testing intermediate versions, so that I can build what they want instead of what they said they wanted.

Raspberry Pi stock surges after London IPO

The foundation's goals are not necessarily the same as the company's goals, and depending on the shares it holds, it may not be able to have as much of an effect as you consider. Many large charities have business holdings, but that does not oblige the businesses to act as a charity. In fact, if they did, all other shareholders would have a reason to complain and possibly sue to change it. This doesn't mean that they are legally barred from acting this way, but that in practice many companies in such a position cannot realistically do so without incurring legal risks or, if they try for long enough, shareholder-required changes in management.

Consider as an example Twitter, the old one. The Twitter board of directors and executives did not want to sell to Musk and tried several ways to make Musk go away. They were in charge at the time, and that's perfectly within their rights. There was nothing illegal about taking that attitude, even though it would mean less short-term money for the shareholders, as they could easily argue that they were doing it for better long-term success. Yet, enough of the shareholders made it clear that they would rather have the short term cash, and the directors were then required to change their policy and sell if they could. If the directors did not, the shareholders could sue the company and have the directors replaced. The Twitter board chose to skip that long process and just go along with what they knew the result would be, and the shareholders likely benefited from that decision because Musk ended up paying them more than their shares would have gained for quite a while without him. Nothing prevents Raspberry Pi from continuing to focus on low prices and for the community's benefit, but nor is there a guarantee that they will, even if Mr. Upton would prefer it.

Uber ex-CSO Joe Sullivan: We need security leaders running to work, not giving up

I'm not sure this is worth arguing, but I'll try at least once.

For starters, you claim that I am misrepresenting you when I said "If you go to jail if anything bad happens, why should you sign up to be responsible for security?"

I got this from this statement from you:

"We also need to make them REALLY respinsible for breaches. If they are the cause of WHY a breach happened because they are clueless idiots, they need to goto jail for a long time."

That seems like a clear call for punishing them with prison time. In my opinion, that is a serious enough punishment that people won't want to be in that position if they know what they're doing. The CSO is, by definition, responsible for the company's security state, and they will inevitably get blamed, at least in part, for any negative event that occurs while they're there. That's not necessarily the wrong thing to do, as quite often, they do have some responsibility. They are not omnipotent, however, and anyone with skills will understand that no level of competence on their part will eliminate the risks. You need a lot to outweigh the risks of "go[ing ]to jail for a long time", and a lot of people who know what they're doing won't take that risk.

"the medical industry and pilots are examples where credentials and skills are checked. Sure they arent perfect but they are a lot better than the zero we get from cxx."

Neither demonstrate the point. Pilots have to be licensed. Doctors have to be licensed. The person who tells the pilots where and when to go does not need to be a pilot. Hospital administrators don't need to be doctors. It's also irrelevant to the point about punishments and responsibility. If you're calling for a licensing test for security workers, that's a separate issue that we could discuss, but using your examples, the person managing the pilot generally isn't the one punished if a pilot flies incorrectly and crashes, nor are they if the finance department has cut down on maintenance to the extent that the plane crashes. If that guy was the one to be punished in both scenarios, you wouldn't find many people willing to be that guy, and the problem would not be solved because bad pilots and bad maintenance would both be very cheap to everyone doing it, because all the cost is paid by that guy. If you want these to stop, you have to actually figure out who is responsible with the chance that's it is a small amount each for lots of people. A license check won't do it,. Lots of punishments when you find a scapegoat you're happy enough with won't do it either.

That is how you guarantee that you won't get someone with technical skills. If you go to jail if anything bad happens, why should you sign up to be responsible for security? Much better to be the person below that, who actually tries to work on security, but make sure you have a scapegoat as the boss in case you fail. You might fail because you don't have the budget. You might fail because your subordinates aren't capable. You might fail because you, personally, are incompetent. But as long as there's a scapegoat above you, who cares?

In any disaster, people rush to find who is to blame. They don't want to go through the long process to figure out what should have been done differently at any level. They just want one person who can get all the responsibility and to see them punished. They most importantly want to make sure it's not them, so they set one up. That's what you have just called for as well.

The problem is that you won't fix anything if you do that. One CSO who doesn't know what they're doing goes to prison (by the way, the reason he was charged isn't exactly this, so I'm speaking in general). The people who didn't secure it are still there. The people who didn't support them are still there. You've removed one link in the middle, a link that was at most incompetent, and you think that will help. They'll find someone else to be a link in the middle in case it happens again, or they'll just continue on without one. Anyone who knows what they're doing won't volunteer to be that link, so there won't be any benefit during that period before the next breech. But people will feel nice that someone was punished.

Re: What Caused the Uber Data Breach in 2022?

It's a good question, but probably not one we can guarantee getting an answer to. It could have been password reuse, and because the email ended in @uber.com the person with the database sold it as having access (tested or not). It could have been a computer with malware on it which keylogged someone as they logged in. It could even be the employee selling it themselves or a colleague selling their coworker's credentials that they shoulder-surfed. The problem is that, although maybe we could figure out the answer in this case, there are lots of cases possibly including this one where that answer has been lost and was never known by any of the people who might want to prevent such a thing happening again.

Fragile Agile development model is a symptom, not a source, of project failure

Working software over comprehensive documentation

Which, to me, means it is better to spend time on making more value, that is, time spent making software work than on documentation no one is going to look at.

I'm afraid this is one of the parts of the manifesto that I take the most issue with, and I'm going to have to use you as an example why. There are many people who interpret that line in the same way. I'm not sure whether that's the same way the manifesto's writers were thinking when they wrote it. I hope not, and I think there's a reason that it might not have been, but as I've said to other defenses of the manifesto, they didn't bother explaining what they meant, so they're either in agreement with or responsible for this attitude when people use the manifesto as justification.

A lot of developers don't like writing documentation. They start finding reasons why they shouldn't have to. Managers also don't particularly want to do it, because it would seem to add time to the development process without making the software any more capable, and if the developers aren't going to do it, then you'd have to hire other people to do it, and that's expensive. Too bad for both groups because it is needed, and they should both know that. I'll tell you who suffers when the documentation's insufficient:

1. The users who read the documentation in order to use the software and get their job done.

2. The users who don't read it, but when they screw something up, can be referred to it, read what they should have done, and use it properly next time.

3. The trainers who need to learn how to use the software in order to teach users, but don't use it themselves. Winging it means training people in at best an inefficient and at worst a wrong way.

4. The support staff, if you're lucky enough to have them, who explain to users how something works even if they don't use it full time themselves. This also includes the tech-savvy colleague who gets a lot of routine questions from the less knowledgeable users.

5. Developers in general when they need to know what behavior is expected, so they know whether a certain change needs to be written differently, communicated to users, or expanded with multiple options.

6. New developers who need some way to learn what this project does and how it does it that's a little faster and more reliable than figuring out where the main function is and trying to read it like a compiler.

7. Me, as an established developer, when I want to help the new developers learn but don't have enough time to hold a complete course on it.

8. Me, as an established developer, when I need to teach someone in great detail or they'll be unproductive and our manager gets unhappy, but the lack of documentation means I have to spend a long time doing this, which means my code production decreases, which means my manager gets unhappy.

Re: Straw Man Argument

"I've skim read the objections in the comments and they don't represent the values and principles in the agile manifesto. I really do wish people would read it."

A lot of us have read it. There are two problems related to it which mean that arguments such as the ones you've made are not convincing:

1. People follow the manifesto in a lot of different ways. They take a lot of the principles to extremes, even when they cause problems. They read "working software over documentation" as "working software, and documentation only if there is spare time", and then apply the continuous development principles in such a way that there almost never is any spare time.

2. The manifesto doesn't prevent them from doing so. I can't point to one of the principles that explains that they've misinterpreted it. I can't prove in any way that their misapplication is not what the Agile creators intended. I can prove that their misapplication is causing problems, but they don't care.

In the last topic on this issue, a couple people started responding to any criticism with "if it didn't work, it wasn't Agile", and this almost religious attitude puts people off because it can be quite clear that sometimes, it doesn't work even though it was Agile, and sometimes, it doesn't work because it is Agile. In my comments, I have tried to point out the benefits of Agile, when it is a good plan, and when it needs alteration, but when people have seen supporters who are unwilling to accept any criticism, blame any failures on others, and adhere to a very short and mostly content-free manifesto as if it answers questions that it either doesn't consider or answers badly, it shouldn't be surprising that they react with hostility. This is especially true if one of those adherents was their boss and applied it, correctly or not, in a destructive way. The manifesto is not blameless in this, nor is the boss, and both will have to be fixed if you want to see attitudes changed.

Re: Study has been debunked.

"For people saying Agile does not work, then you need to abandon some of the solid Agile Engineering Practices created by Agile Manifesto authors. Such as TDD, Pair Programming, Technical Debt, and so on."

No, I don't, and you already know it. For one thing, just because I reject a philosophy doesn't mean that I have to oppose every thing a supporter ever said. That would make for some very odd worlds (let's see, I don't agree with religion X, religion X says murder is wrong, therefore I must become a murderer). Fortunately for me, as I don't want to murder people, that's not how anything works.

Your examples are bad as well. People have been pair programming longer than the Agile Manifesto has existed. Not to mention that it has many limitations and is another one of those things where, if you do it all the time when you don't need to, you are decreasing productivity and irritating the programmers. Technical debt is not a practice, it's a term, and it will exist no matter what you do. You can keep using those words for the concept without adopting the rest of it. As for TDD (test-driven development in case the acronym isn't known), it's not original to Agile either, can easily be used without it, and has been blamed, sometimes unfairly, for quality issues as it means fewer or no people specifically testing rather than developing. That is one which, given the number of times I've seen it done badly, I wouldn't mind abandoning or overhauling.

Re: What I Have Never Understood About Agile.........

It doesn't necessarily mean updating what people use every month, but having more stuff for them to look at every month. For some types of software, this can produce good results. I've worked on these before and kind of have one now. I make a version, send it to some users, and they tell me what they like or dislike about it. It doesn't do everything because the project's not complete, but I have a list of things that do work and a list of recent changes so they can direct their attention. That lets me fix things more quickly, which means I also have time to deal with opinions that aren't necessarily bug reports. The software won't be put into production until it's all complete, but the intermediate versions show the progress and get user input.

If the software isn't as user-facing, this doesn't work. If there aren't any users willing to keep testing intermediate versions, it doesn't work. Sometimes, this is a great method for getting good stuff fast, which is why people have called for it, but they should, and not enough do, consider where it doesn't apply before trying to apply it to everything.

Original: My experience is that when allowed to figure it out for themselves, competent people will evolve a system that works quite well for their project

Reply: This is agile. Not a set of defined processes/outcomes, but a team working to work better for the customer.

No, it's not Agile in the sense of the manifesto. What they could come up with might be similar, but it could be diametrically opposed: "We team members have decided that this won't work well unless we write a full plan and specification right at the start. That's what we intend to do. Then we can build this without getting in people's way". Some projects work best with that. Some projects work terribly with it and can use Agile-type methods. People selecting to do something different than the manifesto are not being Agile, they're making their own decision.

Spam blocklist SORBS closed by its owner, Proofpoint

Re: Double opt-in demands

"So your issue is with amateur admins, and not SORBS."

As they clearly stated, their issues are with both. Their issue with admins was taking a report in an extreme way, and their issue with SORBS was creating a report with insufficient justification, which they allege other lists did not do.

Re: Spamhaus

That's like saying that Microsoft reporting a file as malicious and automatically deleting it isn't blocking it. Imagine, for the sake of argument, that they did that to the Libreoffice installer. Now a Microsoft fan could point out, correctly, that you could disable Windows Defender and the file wouldn't be deleted, or that you could go into the settings and disable the automatic deletion function, then click through a couple warning screens, and that would work. From the perspective of most users, that decision would still be intended as and implemented as a block.

When people use these spam lists without thinking, they're partially responsible for the problems, but people who are labeled possibly spammers by an overeager algorithm will tend to blame the algorithm, especially when a lot of receiving MTAs remove the "possibly" before deciding whether to allow the message in or not. I do not know this case, and I have not had to deal with this in a long time, so I cannot say whether this case did involve a bad decision by the list creator. I don't think it's hard to imagine that there could at times be those bad calls.

When I have run my own mail servers, I found that various lists either blocked or warned about every IP address that could be rented. Since you can get a cheap VPS, so can a spammer, and it's cheaper to block the entire range than to come up with some method of trying to tell the two apart. There is a reason why I stopped running these. It's not that I can't, but the work involved in depolluting an IP addresses is annoyingly sporadic, depending on the goodwill of people who may or may not have any interest in helping you.

When I was looking into this, it seemed that the easiest ways would be to have a corporate network or host in a colo. Their static addresses weren't on lists. Unfortunately, both are expensive and make it harder to host a low-traffic server for a project. Several ended up using registrar-hosted email instead, which wasn't my first choice, but substantially reduced the concern that I would wake up one morning to find that messages were no longer arriving.

New York Times source code leaks online via 4chan

Re: Cheery

"BTW it's time companies started putting their stuff in long-term storage (i.e. tape, [...] That'll make it a lot harder for miscreants to nab it. Most of the stuff isn't needed online anyway."

They should consider using that for backup, but it does little to help with security. Most of that stuff is needed online, or so much of it that they probably need a hot copy. Your repos are much less useful if programmers and sysadmins have to keep asking to get tapes mounted so they can work with the thing. The only thing you can remove from hot storage is the stuff you're pretty sure you won't need soon, and I would define soon as "any time in the next year, from even one person".

They need to modify parts of their code. They need to deploy it to new systems. For both reasons, their code is not something they can just store on tape. Doing that is useful if their hot storage gets damaged and they need to recover, but trying to do it without the hot storage at all will only lead to frustration.

I didn't touch a thing – just some cables and a monitor – and my computer broke

Re: Blonde moments

It could be the kind where you should remove the plastic cover with no release button or slot and the receiver is in there. I prefer that storage method, but if you don't know that they did it, it can be confusing because yanking off a panel is usually not the right policy when you can't find something.

Re: Crows

There are some good organizations that attempt to reuse usable hardware and recycle obsolete electronics. Since they're already reusing plenty of computers, they don't have problems dealing with more ones, even if they end up having to recycle a lot of them. The only tricky part is finding them, as they usually end up being small groups of motivated people and differ from city to city. I've lived somewhere with a good one and am sad that the city I moved to doesn't seem to have such a thing, but I'd try to find if such a group exists where you live.

Re: refused to take responsibility

That might be true, but the person responsible for getting presentations working at a conference is not the same person, or if it is not at the same time, as the person who fixes a computer that's had coffee poured into it. Quite likely, that was going to need to be replaced. If not, it was going to need a painstaking disassembly. Either way, work on that computer was not going to happen quickly.

Big Telco takes aim at renewed net neutrality rules

Re: Information vs telecommunications service

This is unrelated to companies like Facebook. It only covers ISPs, and those don't have liability for the content they transfer due to common carrier legislation. Facebook and companies like them are protected by section 230, so they're not affected either. This change will not alter the situation you describe.

Contrary to its fine print, Google says it won't confiscate repair returns that have unapproved parts

Re: "end up buying new ones"

In many cases, there isn't a lot of choice. So you want to buy an Android phone and you don't want it to age badly, which is why you were trying to repair your current one. The two companies with halfway reasonable software support policies and models available for purchase are Google and Samsung, both of which have this policy. You can hope that Fairphone sell in your region and that you're willing to pay quite a lot for their device, but otherwise, you are left with options that are worse on at least some levels. Refusing to buy from a supplier again works if there are a lot of them available or if you don't really need to buy that type of thing much, but if you do need another one and the choices aren't great, a lot of people will end up buying from companies they dislike because every other option is worse.

Re: Pretty Sure....

I think this would be illegal pretty much everywhere as theft, but in order to prove it, you'd have to file a court claim. I imagine that any company that has and acts on this policy would respond to any filed claim or possibly even the threat that you would file one by returning the device immediately. They're expecting that there will be many people who won't file a claim who will end up buying new ones and that, for those who do threaten it, they won't be at a loss because all they have to do is actually return the broken unit.

Nokia demos upper 6 GHz band for mobile, but UK wants it shared with Wi-Fi

Re: 6GHz Mobile?

The hardware can already use those frequencies, but it just has to turn off some of the bands. WiFi equipment has been doing this to deal with country requirements since the beginning. The original 2.4 GHz band had 14 channels, but only 11 were allowed in North America, and only 13 in most of the world. Almost all hardware requires, at some level, a country code which is used to select the allowed bands before it switches on. I don't know what will realistically happen if you use that to transmit on frequencies you're not supposed to.

London hospitals left in critical condition after ransomware attack

Re: This question should be put to Starmer and Sunak tonight

You might get them to say that, but they're not going to do it.

Prime Minister: Who attacked our power grid with ransomware?

Security consultant: We're pretty sure it's a ransomware group called TheoreticalName.

PM: And who runs that?

SC: We don't know yet.

PM: How can we find out?

SC: They attacked a Brazilian water company, an American school, and a factory in France recently. Does that suggest anything?

SC: Well, you can usually assume that there are at least some people in Russia for any of these big things. We do know that Russia is blocked in the software as a victim country.

PM: So bomb Russia then?

You can suggest anything you want, and if you ask enough times they'll realize that you want a military response and they'll promise you one, but they will have reasons not to do it when it happens. Those reasons are logical. There's a reason why we don't solve every diplomatic incident with bombs.

Re: Plan B. Have one.

"Paper and people to shuffle it are cheap and plentiful."

We live in different worlds. In mine, paper is cheap, and everything else is expensive. People to move forms manually when a computer can move thousands per second are a lot more expensive than that computer. Finding the people who want to do that work is not easy either. Dealing with errors caused by, for instance, someone misreading handwriting is not fast. Space to store all that paper is not free.

Command senior chief busted for secretly setting up Wi-Fi on US Navy combat ship

Re: Should be given a medal

If you are reading it that way, it also means that I should be able to set up as many broadcast stations as I want, even if it means no other radio or TV signals can get through to you, because that is a medium by which one can express opinions. The same logic would apply to standing in your bedroom with a megaphone while you try to sleep. I think it's clear that that is not what they intended when they wrote that.

Checkmate? AI's pawn-pushing prowess proves partly pitiful, partly promising

Re: Confusing about what Prelovac believes, expects or hopes for

"But what does comparing their chess-playing ability do for us?"

It demonstrates that they are not general intelligences. And I don't agree that he believes they have one. I think he was attempting to demonstrate the extent to which they can solve problems that weren't the purpose of their training data, because that's what a lot of LLM-based products claim to do. By pointing out how often they fail at something that is relatively easy to make a computer do, it demonstrates the failure in a simple, practical, easily-understood way. That might be more convincing to someone who believes that LLMs can reliably solve problems than a theoretical discussion.

Re: A real test

"But seriously, is anyone actually surprised at the complete failure of ML to play chess?"

Was that a typo? ML, as in machine learning, does play chess well. A specific model trained on the rules of chess to play actual chess moves is quite good and routinely beats the most skilled of humans. LLMs, on the other hand, are crap at that because they weren't intended to play chess, but there are lots of people who think that they're something that they're not. I don't think many of us are surprised that an LLM can't play chess, but there are some people who might, but probably won't, understand why this means their conception of an intelligent program is flawed. They see a program write a paragraph with correct grammar that looks to be answering a question, and since they can't answer that question, they assume it must be intelligent. Also because they can't answer the question, they may do that even if the provided answer is wrong. It looks convincing and that's good enough for them. I'm hoping we can show them what the tool can actually do before they unleash some LLM-powered thing on us which annoys everyone with constant wrong answers.

Windows 11 tries to escape Windows 10's shadow with AI muscle

Re: For what stats are worth...

I think it's even simpler. I think people just don't care. They see nothing that Windows 11 has that Windows 10 can't do. I've been running Windows 11 for years now, and it's fine, but there's not much that is different from Windows 10 that affects what I do with it. People will replace broken things and get updates that way, and they won't care at least until security updates stop. I predict that there will be a spike after those updates end from people updating the Windows version on machines that could have supported it any time since 2021, but even then there will be lots of people running 10 because they see an optional update and always cancel it.

Millions forced to use brain as OpenAI's ChatGPT takes morning off

Re: Good to see the cloud is as robust as ever

Your argument might work if their problem was a server capacity error, although not very well because, as everyone including you must know by now, putting your resources on a cloud service doesn't automatically provide resiliency, just provides you more tools so you can have it cheaper. However, with the internal server error messages, you have to wonder if maybe their problem is that they screwed something up. Cloud does not save you from configuring something the wrong way.

Crooks threaten to leak 3B personal records 'stolen from background check firm'

Re: That 'opt out link'

There are two options:

1. You are right, they get it from a UK organization that is breaking GDPR and is liable for it. The Florida people have no requirement to identify who that UK entity is, so unless you can find out in some other way, how are you going to file a complaint?

2. They do it to UK citizens who have provided some information and collect it, with permission, from a UK company that has legitimate reasons under GDPR to process it. Then, unlike that company, they keep it and thus your objection only applies to them. Theoretically, you can still hold them liable under GDPR, but if they don't have operations in Europe, they will likely not pay a penalty.

US standards agency reports back on just how good age verification software is

Re: 3.1 years

"Does NIST not understand that 'region of birth" has only tangential bearing on physical attributes,"

It doesn't matter. If you put region of birth into your analysis and it points out that accuracy is different on that basis, that indicates a problem. Whether that problem is due to a racial difference or if there is some other regional factor is important if you're the writer of the thing wanting to improve it, but as a user wanting to know if it's good enough, you don't need to care, because either way the answer is that it is not good enough.