quanticle

By that logic `perl` is a tool that does "one thing", where that "one thing" just happens to be "everything".

    The only thing I really take away from the UNIX philosophy nowadays (I used
    to be a dyed in the wool fan of UNIX/Linux) is #1) do one thing and do it
    well. I see #2 as an ideal goal to reach but not always required.

If you have a number of programs, each of which does one thing and does it well, those programs will need to exchange data between themselves in order for the overall system to be useful to the user. To go back to the `ls` example I used in my post above: `ls` should just list files. Why should `ls` have anything to do with sorting, when `sort` exists? The reason, as it stands right now, is that `ls`'s plain text output is too much of a pain to parse, and so it's more convenient to build sorting into `ls` itself. If you start with "do one thing and do it well", but ignore interoperability, then your program will inevitably grow additional options and subcommands until it does one thing well, and quite a lot of things mediocrely. Instead of a collection of small sharp specialized tools, you'll end up with, e.g. `find`.

    The M x N interoperability problem is SOLVED BY building on top of bytes /
    plain text, not solved by moving AWAY from it!

I never argued that we should move away from plain text. Indeed, one of the examples I cited of an interoperability format, JSON, does exactly that: it takes plain text and adds structure to it to make it easily parseable by machines. Overall, I'm not sure what part of my post you're arguing against. I'm suggesting that instead of having a many different ad-hoc formats, Unix utilities should agree on a few accepted serialization formats and pass information around using those. This would make our shell pipelines less complex and more robust because we wouldn't have to worry about e.g. random spaces or newlines breaking the ad-hoc parsers we write with `grep` and `cut`.

It seems like you agree with that, with the caveat that that serialization format should be built on top of plain text. That's fine. We can agree on JSON as a serialization format. It's not ideal, but it's better than the myriad of ad-hoc formats that we have now.

    The beauty of UNIX to me is the interoperability of the text stream

What interoperability? Look at the man page for any simple Unix utility (such as `ls`), and count up how many of the listed command line flags are there only to structure the text stream for some other program. "Plain text" is just as interoperable as plain binary. "Just use plain text" is the Original Sin of Unix.

The Unix Philosophy, as stated by Peter Salus [1] is

1. Write programs that do one thing and do it well

2. Write programs that work together

3. Write programs to handle text streams because text is a universal interface.

The problem is that, in practice, you can only pick two of those. If you want to write programs that work together, and do so using plain text, then, in addition to doing its ostensible task, each program is going to have to provide a facility to format its text for other programs, and have a parser to read the input that other programs provide, contradicting the dictum to "do one thing and do it well".

If you want programs that do one thing and do it well, and programs that work together, then you have to abandon "plain text", and enforce some kind of common data format that programs are required to read and output. It might be JSON. Or it might be some kind of binary format (like what PowerShell uses). But there has to be some kind of structure that allows programs to interchange data without each program having to deal with the M x N problem of having to deal with every other program's idiosyncratic "plain text" output format.

[1]: https://en.wikipedia.org/wiki/Unix_philosophy

    But most everyday tasks don't need a deadline

I think that's the crux of our disagreement. I think most everyday tasks do indeed have a deadline. Even if that task specifically doesn't have a deadline, it's often in service of a broader task which does. The premise that all agile methodologies are built on is that customers are going to be more willing to drop features rather than add days to the schedule. I think experimental evidence has proven that premise false.

And frankly, it was kind of a ridiculous premise to begin with. Can you imagine if other professions adopted "agile" methodologies? Can you imagine your auto mechanic telling you, "Okay, well, putting the dashboard back on is going to take me until tomorrow, actually, but, if I only attach half the bolts and leave the speedometer disconnected, I can get it to you by the end of the day. Would that be all right?" Or a home-builder saying, "Okay, well, the drain pipes are proving trickier than anticipated to install, but I can give you the bathroom without the drain pipes, and install those in the "version 2.0" release. Would that be okay?"

    At some point all I can suggest is "don't work for a liar". Of course that
    may be easier said than done.

The point of my anecdote was to illustrate how Agile makes it easier to lie, and makes it difficult for honest people to call out liars. If a manager tells me that the deadline is Wednesday, and the deadline passes without anything bad happening, then he or she looks bad. If a manger estimates a "3", and I estimate a "3", and then it turns out that our definitions of what a "3" is differ, then I look bad, regardless of whether the work was, in reality a "3", a "5", or a "3.1415926".

    But that doesn't mean that good practices are worse than bad practices!

The worst practice of all is a bad practice that masquerades as a good practice. I'd much rather that people be honest and up-front about the deadline (even if it is BS) than try to hide behind some overly complicated poker-game kabuki.

    Imagine if software with large inherent risk was developed using formal
    methods, and the massive remainder of software was developed using rapid
    development methods.

Imagine if we could tell the difference between use-cases with large inherent risk and the massive remainder of use-cases and avoid using software designed for low-risk situations in high-risk applications.

    then add additional specifications to clarify ambiguity when observed

That's such a clean, almost clinical way to describe, "After the software has caused several billion dollars in trading losses, bankrupting the entire company." (https://en.wikipedia.org/wiki/Knight_Capital_Group#2012_stoc...)

Fake or not, at least you were told what the deadline was. The agile approach to this dysfunction is for you to be pulled aside at some point and told, "You're not delivering enough points," with the manager remaining extremely vague about how many points is "enough".

That brings to mind the other issue I have with fibonacci estimation: it makes improvement impossible.

In any high-performance organization, there is periodic self-reflection and self-improvement. Professional sports teams will, for example, sit down and "watch the tape", reviewing video of their most recent game(s) to see what they've been doing well and what they've been doing poorly, drilling down into specific areas where they need further practice.

Agile pays lip-service to this practice with its end-of-sprint retrospectives, but I've never seen an agile team do anything approaching a ticket-by-ticket breakdown, going over why the estimate was wrong, and what could be done to improve estimation in the future. One of the reasons that teams don't do this is because Fibonacci estimation makes it impossible to do this sort of thing. If I estimate that a task was a "3", and it took me two days to finish, did I estimate correctly? How could I have estimated better? These questions don't even make sense without a common baseline for what these numbers mean.

That's what I find most frustrating about Agile, as it is practiced. It's not the fact that the estimates are wrong. It's the fact that the estimates are so meaningless that they're not-even-wrong, in a way that makes it impossible to find and adjust for biases.

    They mentally convert the points to some "X days" and then beat you in the
    head with it.

That's actually why I really dislike Fibonacci estimation. If we just estimated days or hours, then I could say, "Okay, this is going to take me until Wednesday," my manager would reply with, "Wednesday? It's going to take that long?" and then we could have a discussion about why it's going to take so long. Or, worst case, manager says, "quanticle, I really need this to be done by Tuesday," and I know I'm going to be staying late until it's done.

But with Fibonacci numbers, it's like, I estimate a 3, manager nods and agrees that this task is a 3, and then it turns out that when I said 3, I meant that it'd take until Wednesday, but manager thought that a 3 point task would be done by Tuesday, and now manager is mad at me, and I don't know why.

The old way sucked, but at least it sucked in an up-front and transparent way.

The problem I have with CloudFlare is that their definition of "undesirable customer" includes forums engaging in hateful, virulent, but ultimately legal speech, but does not include forums that are selling methamphetamine and stolen credit card numbers.

    but a core and critical functionality of your entire OS such that any
    attempt to sidestep or evade it would be met with ruination?

Was Internet Explorer ever actually a core and critical part of Windows? Sure, Microsoft claimed that it was. But of course, they would have done that, given that the alternative was to admit that the Justice Department's argument was correct, and that Internet Explorer was being bundled in an anti-competitive manner to deprive Netscape of sales.

Exactly. When I hear that someone has done the same algorithms book three times, I think of the Brazilian physics students that Richard Feynman encountered [1]:

    After a lot of investigation, I finally figured out that the students had
    memorized everything, but they didn’t know what anything meant. When they
    heard “light that is reflected from a medium with an index,” they didn’t
    know that it meant a material such as water. They didn’t know that the
    “direction of the light” is the direction in which you see something when
    you’re looking at it, and so on. Everything was entirely memorized, yet
    nothing had been translated into meaningful words. So if I asked, “What is
    Brewster’s Angle?” I’m going into the computer with the right keywords. But
    if I say, “Look at the water,” nothing happens – they don’t have anything
    under “Look at the water”!

Someone who's ground through an algorithms textbook three times, but doesn't have significant project experience is like a physics student who can name every equation, but cannot calculate the polarization angle of light reflected off water.

[1]: https://v.cx/2010/04/feynman-brazil-education

    Someone self-studies a pretty challenging book on data structures and
    algorithms and you don't think that makes them curious and motivated to the
    point that you'd not feel comfortable working with them?

Not really, no. There are plenty of grinders who will pick the most difficult book and study it, not because they think it will make them better at solving problems, but because they think it will elevate them above their peers. Why you study is as important as what you study.

There's a saying: "There's a big difference between ten years of experience, and one year of experience repeated ten times."

Someone who's just repeated solving the same problems over and over again, has the latter, especially if they've only done it in a single language.

    How long would it take you to 180 and go into the your opposite profession?
    What is your opposite profession? Do you have any friends in that
    profession?

I'm not even sure how to answer that question. Do professions have "opposites"? One of my relatives is in medical school right now, studying to be a doctor. What's the "opposite" of that? Professional assassin?

I scrolled down looking for someone mentioning the Microsoft library. I used it to teach myself Typescript, on the job, there. One of the regrets I had after leaving Microsoft is that I didn't make greater use of the library.

The reason all those examples you cite became as successful as they did is because they spent that extra 20% to get it right. They didn't just ship some MVP out the door. They spent a huge amount of time and energy to get the product as close to perfect as they could before shipping. Steve Jobs, famously, became concerned about the aesthetics of the traces of the circuit board on the original Macintosh [1], spending $5000 (16,330 in 2023 dollars) and a couple of weeks, to have a circuit board created with better aesthetics. Then they threw that board away because, it turned out that aesthetic traces don't actually correspond to good signal propagation.

That's the reason that Apple, especially, has been so successful. It's not because they launched at some perfect time window. It's because they launched damn good products. If the iPhone had launched in 2008, or even 2009, it would have been just as successful. We just would have had another two years of mediocre Windows Mobile/Symbian OS/Blackberry devices.

[1]: https://www.folklore.org/StoryView.py?project=Macintosh&stor...

We're not special [1]. Programming isn't that different from other engineering disciplines. The difference is that, somehow, programmers have developed this anti-intellectual attitude that keeps them from doing the hard work needed to develop the estimation tools that other engineering disciplines take for granted. Step one in developing those tools is tracking.

[1]: https://www.hillelwayne.com/post/we-are-not-special/

    There are many businesses where shipping 20% later leads to ceding first
    mover advantage and losing the game.

Are there? Can you name some examples? Because when I think of technology, first-mover advantage counts for very little. The first successful web browser wasn't NCSA Mosaic. It was Netscape. The first successful portable music player wasn't the Nomad, it was the iPod. The Macintosh long predated Windows, but Windows has by far the larger market share. Same with iOS and Android. Google was far from the first search engine. Facebook was far from the first social network. Amazon didn't invent e-commerce. In automobiles, Ford was first to mass production, but it was overtaken by General Motors by the 1930s, and they both were in serious trouble when the Japanese auto manufacturers, which didn't even really get going until after World War 2, arrived.

So in which business exactly does shipping 20% later lead to "losing the game"? If anything, the real risk is in shipping a half-baked product too soon.

A lot of the discussion in this thread has been about how Privacy Sandbox has been deceptively marketed to users, and I agree that Google's marketing has been deceptive. However, what I really want to know is, what's in it for app developers? Privacy Sandbox is opt-in, but what advantages do app developers gain by opting in? Will they be ranked more highly in Play Store search results? Why should an app developer totally rewrite their analytics code to use Privacy Sandbox when existing methods of tracking already work, and will continue to do so?

Who does Privacy Sandbox benefit? It doesn't benefit users, because it's not mandatory for apps to respect it. It doesn't benefit developers, because it's non-zero work to migrate, and zero benefit (because existing tracking and analytics systems will continue to work). It's doesn't benefit Google, as a whole, because it's one more API that they have to continue to support.

What was the point of all this?

The point of the article is that Google is pitching Privacy Sandbox as the Android counterpart to Apple's App Tracking Transparency, when, in reality, it's anything but. App Tracking Transparency disables tracking unless the user opts in. Privacy Sandbox only disables tracking if the developer opts in. You can see this by reviewing the developer documentation [1] for Privacy Sandbox. It's totally optional on the part of the developer. Pitching Privacy Sandbox as an alternative to ATT deceptive marketing.

[1]: https://developer.android.com/design-for-safety/privacy-sand...

    Is it more important to have perfectly tracked projects or projects which
    ship 20% faster?

It's far more important to have perfectly tracked projects. A perfectly tracked project which is guaranteed to deliver on a particular day is gold. It makes planning for the rest of the organization much easier.

To use a programming analogy, it's like the difference between latency and jitter for real-time systems. Many real-time systems will happily sacrifice considerable amounts of average latency, in order to minimize jitter. It's far better to have a process that completes in 200 ms every single time than it is to have a process that completes in 2ms most of the time, but, occasionally takes 2000ms.

Similarly, from a managerial perspective, it's far better to have a team that gives you good visibility, allowing you to plan for a completion date (even if that date is farther into the future than you'd like) than it is to have a team that mostly finishes projects quickly, but occasionally bogs down and takes a year to finish a project that was initially estimated at two months.

The problem is that far too many organizations have neither. They don't have visibility, and they finish projects late. For these organizations, your dichotomy is a false one — better tracking is how they will ship faster.

Exactly. A lot of developers focus on lack-of-vulnerabilities as the essential aspect of security, when, in reality, for corporate IT, the essential aspect is visibility. It doesn't matter how secure a black-box app purports to be, the mere fact that it's a black box that IT has no visibility into it will (justifiably, IMO) lead IT to treat it as insecure.

I agree that Ars Technica has an anti-Google stance, but in this case, it seems to be accurate, so I'm not sure what the problem is. The "privacy sandbox" on Android is opt-in… on the part of app developers, not users. If app developers want to track users with cookies and device IDs, they can still do that. It's not anything like what iOS does, where tracking is disabled unless the user opts in.

So yes, while the Ars Technica headline may be a bit hyperbolic, I think it's far closer to the truth than a headline which claims that Privacy Sandbox is comparable to ATT.

Given how many times they must've been burned by end users opening infected Microsoft Office documents, can you really blame them?

    What makes SAP secure?

Nothing, inherently. What makes SAP secure is that a lot of IT organizations have experience with setting it up, and know enough about its pitfalls to avoid them. With a new product, IT is going to have figure out the security pitfalls (hopefully by reading documentation, but more likely through testing, hopefully not through breaches). If, as the grandparent post indicates, the product was set up by someone outside of IT, it's quite likely that that person doesn't actually know about security, and may well have inadvertently opened a security hole by, for example, creating an insecure proxy account.

To re-emphasize my point from my original post: far more security problems result from the interaction of systems than result from systems themselves. SAP may be set up in a perfectly secure manner. The new product may be set up in a secure manner. However, their interaction may still result in data leakage or denial of service.

Even if your product is perfectly secure (which it isn't), the mere fact that it's one more component, interacting with all the other components of the company's IT infrastructure, is reason enough for broader corporate IT to be cautious.

Furthermore, it's often the case that when there is a problem, security or otherwise, it's not going to be your customer that's on the hook. It's going to be the company's IT department. Would you like to suddenly support a piece of software that, a week prior, you didn't even know existed, much less deployed at your company?

Another reason that people often overlook is security. Even if each individual software product has a good security model, differences in the way they interact can lead to security vulnerabilities and opportunities for attackers to move laterally through a network. In the case above, it may be that IT knows how to integrate SAP with their Active Directory system in a manner that ensures that users have access to the data that they need, without giving everyone write access to everything. A brand new product from some small startup, even if it's competently engineered, won't have the same pre-set integration playbooks as SAP. The in-house IT will have to figure it out themselves, which adds time and overhead for every operation. New hire? Before, you'd give them a SAP account, and you'd have a playbook that would automatically or semi-automatically provision everything for them. Now, you have to provision accounts in two systems. Compliance? IT already knows how to validate an SAP install for compliance and generate a report for the appropriate regulators. Now they're going to have to learn to do that with your new system. And so on.

I listen to several infosec podcasts, and one recurring theme in those podcasts is managing users who do "shadow IT", i.e. by buying and integrating new products or software that make their day-to-day jobs easier, but do so in a manner that opens up huge gaping security holes that IT doesn't even know about… until the breach happens and the company is all over the news for leaking customer data.

I had a similar experience working for a company that had, essentially, developed their own in-house web templating language and programming system. They'd started before PHP or any of the other server-side programming languages had caught on, and while a decision to use a homebrew system may have been justifiable in the '90s, when the only real alternative was Perl/Mason, by the time I joined (2009), it was long overdue for them to have moved on to an industry-standard solution. PHP. Python/Django. Ruby/Rails. Even classic ASP would have been preferable to the mess of C++ and XML they were using.

Frankly, I think the article, like a lot of Joel Spolsky's writing, has aged like milk. For example:

    If you’re developing a computer game where the plot is your competitive
    advantage, it’s OK to use a third party 3D library. But if cool 3D effects
    are going to be your distinguishing feature, you had better roll your own.

Except, if you look at modern games, even ones with very high performance effects, that's not what they do. They use one of a rather small number of 3D engines, like Unreal or Frostbite. It turns out that developing cool 3D effects is far easier if you have a battle-tested performance optimized framework helping you. CD Projeckt Red abandoned its own in-house engine (REDengine) in favor Unreal 5 for future development, in no small part due to the issues that they ran into trying to extend that engine for a massive open-world game like Cyberpunk 2077.