1.  

    I don’t understand the obsession with tacky Geocities sites. To each their own, but I was on the internet back then, and that’s certainly not the “internet of old” that I miss.

    Also, I find it highly ironic that this is linking in scripts from Google, Facebook, and Cloudflare.

    1. 5

      Agreed. For me, the “old internet” is sites like this:

      http://www.mir.com.my/rb/photography/companies/nikon/nikkoresources/index.htm

      Densely packed with info, links are made up as you go along… basically one person’s drive to put all that info out there.

      1.  

        I dug through my bookmarks and found a few more examples that are still up:

        http://paulbourke.net/geometry/

        https://agner.org/optimize/?e=0#0

        https://www.sandpile.org/

        https://www.adahome.com/

        Like your example, there’s no advertising, tracking, third-party spyware, “monetizing”, or “sign up for my newsletter”, just lots of information in an easy to read format, shared just to share.

        1.  

          “Firefox prevented this site from opening a pop-up”

          Old Internet indeed!

        2.  

          I kind of understand it. I don’t miss it, but geocities, tripod and the like let people experiment at no cost and gave them a platform they could control. That energy was special, IMO, and seeing celebrations of it like this makes me remember the energy and the excitement about the potential of this new thing. Even if I don’t care for the aesthetic, personally.

          It was different from some of the gopher spaces, newsgroups and BBSes that I do really miss, but still seems to reflect a part of the spirit of the time that’s worth preserving.

          You’ve also got some of the kooks that were suddenly published and discoverable when the web and search engines came into being. Like the timecube guy and several less benign ones.

          I think Project Gutenberg might be one of my favorite “internet of old” things that is still really alive and useful.

        1. 6

          CICS is one of the most successful pieces of software in the world: there are over 30 000 licences, and most of the world’s top companies use it.

          Ooof. Looks like the book is from 1996, so it’s a bit of an extravagant claim even at the time.

          Fun fact: Daniel Jackson got so fed up with Z that he invented Alloy just to fix the shortcomings!

          1. 4

            CICS was the primary reason I worked on porting Swift to z/OS. COBOL interaction was the holy grail. (I left before we got to that point and I don’t know the status of things since then.) Point being that CICS plays a large role in finding the IBM compiler efforts.

            It should also be noted that the book was written on OS/2, so maybe they were getting those numbers from the IBM sales team. ;)

            1. 1

              Swift-COBOL interaction reminds me of the time I got multiprotocol routing set up between IP, IPX, AppleTalk, and SNA.

              it worked, somehow.

            2. 2

              It’s most successful, for suitably small values of “most”.

              1. 2

                The small most hypothesis.

            1. 2

              Sometimes, title alone is not enough to uniquely identify a book. This isn’t limited to this particular post, but wouldn’t it be great if, in submissions tagged book, authors were also named? I’m not even mentioning ISBN

              1. 2

                Thanks for the feedback, I added an ISBN-10 for each of the books

                1. 2

                  It is much better to include the author’s name, year of publication or printing, and edition. The ISBN on my copy of On Writing Well doesn’t match the one you listed. Besides, no one remembers ISBNs anyway. They are not used in any academic bibliography I’ve ever seen, either.

                  1. 1

                    Thanks a lot for that! it is now much easier to search for the books :^)

                    I do have to echo some of @GeoffWozniak’s comment here, however. Not sure whether I wasn’t clear enough in my initial suggestion but, alongside a full book title, I would have expected the author(s) to always be mentioned, with an ISBN being an addition to the above. Here’s an example of what I had in mind: https://www.openbsd.org/books.html

                    What I do not agree with, in terms of said comment, is that providing an ISBN is worth next to nothing - I frequently use it to search for books, i.e. in order to identify a particular edition (i.e. newest isn’t always the best and/or what I am after), etc.

                1. 43

                  If you want to heavily invest into GNUisms (bash, RECIPEPREFIX, …) and make your makefile less portable, go ahead and follow the advice in this article. If you don’t, be my guest, use sh(1) instead of bash(1), read the make-standard and test your makefiles with other make-implementations than GNU make.

                  This helped me tremendously with writing good, concise and simple makefiles. We need to stop writing unportable makefiles, and especially stop relying on the bloated GNU ecosystem.

                  1. 11

                    Alternatively, name your makefile GNUmakefile to mark it as “only tested with GNU”.

                    1. 10

                      and especially stop relying on the bloated GNU ecosystem.

                      I know this site likes to hate on GNU, but its make has more useful features than any other make. % rules make writing pattern rules so much easier. The text-manipulation functions make working with variables so much nicer. These are “killer” features of GNU make for me.

                      1. 11

                        I used to be pretty harsh on GNU stuff until I realized how decrepit pure POSIX implementations are. For better or for worse, GNU tools do what people actually want, instead of some religious interpretation of Unix or minimum specification compliance.

                        1. 5

                          Seconded. POSIX make is pretty sparse. GNU Make has a bunch of warts but it has some conveniences that are nice to work with. Reading what automake dumps out isn’t a good way to judge it, either.

                        2. 2

                          I agree. Writing a portable (POSIX compatible) works when you do “regular” stuff, like building .c -> .o -> binaries, but anything more complex ends up having to lash out to shell script, either in them or around.

                        3. 6

                          I don’t agree with the article as well, although for a different reason (that might be added up to yours, really).

                          My standpoint is that shell scripting and makefiles are poorly understood by many people in the industry. Spicing up a makefile like this is likely to end up in wrong makefiles when a colleague having a shallow experience with these tools is going to change something.

                          To give an example, it is expected that individual failures in the recipes will make the whole build rule fail, but setting ONESHELL will change this sematics dramatically, with no change in syntax! Unless you also set SHELLOPTS += -e, error checking will work in an often unexpected way!

                        1. 5

                          I have to pass -trigraphs to a modern version of gcc before this actually works.

                          As soon as I read “trigraphs”, the “WTF” made perfect sense.

                          1. 1

                            Got any bad experiences?

                            1. 4

                              It’s long been known that trigraghs are a disaster. No sane person would design that in today. It’s a vestige from days long gone kept around for compatibility reasons. The intense confusion they cause is why GCC disables them by default.

                              1. 5

                                If you don’t speak up for the trigraph users, will anyone speak up for you?

                                (The amusing parts is that EBCDIC does support these characters, but maybe that’s only on i, and z/OS continues to be a nightmare hell dimension…)

                          1. 1

                            This article is absurd.

                            Exhibit A:

                            <meta name="GENERATOR" content="Microsoft FrontPage 6.0">
                            

                            Can we really take someones arguments about software quality seriously when they are using Microsoft FrontPage 6.0?

                            Now here is an unpalatable truth, twenty years on: most open source code is poor or unusable.

                            He starts with the premise that most open source software is garbage, but misses the point that most of everything is garbage. For example, most books ever written, photos ever taken, and paintings ever drawn are absolute garbage when compared to works of high quality in the same field.

                            This is also true about all software, and all software companies. Most of all software is low quality and most companies will fail.

                            Linux is of course, mostly a copy of Unix, it is deeply unoriginal, being based on ideas going back to the time of the Vietnam War. These ideas were in turn evolved within Bell Labs by its creators who were also well-paid professionals. Linus Torvalds copied an idea whose basis had been funded by university and corporation money and without that basis there would have been no Linux. Early Linuxes were dreadful. My Ubuntu version of 2005 was an absolute crock that wasted the plastic on which it was distributed. Ubuntu was itself a loss-making personal hobby of a entrepreneur who had so many millions that he could afford to run the parent company, Canonical, at a loss for years. The situation in 2019 is better than 2005, but the Linux desktop still lags behind Windows and the interface looks stuck in the 90s.

                            I’d like to go into a deep discussion about the differences between a kernel and everything else but I think the point would be lost on Mark.

                            P.S - the author’s website is served nginx (and is very likely running on a Linux server), which, is open source software.

                            HTTP/1.1 200 OK
                            Server: nginx
                            Date: Sun, 15 Dec 2019 02:13:08 GMT
                            Content-Type: text/html
                            Content-Length: 89626
                            Connection: close
                            Last-Modified: Sat, 26 Oct 2019 13:39:53 GMT
                            ETag: "15e1a-595d066cc3e2a"
                            Accept-Ranges: bytes
                            
                            1. 7

                              Can we really take someones arguments about software quality seriously when they are using Microsoft FrontPage 6.0?

                              Short answer: yes. Longer answer: what the essay was written/published with has nothing to do with the arguments put forth.

                              This [most software is garbage] is also true about all software, and all software companies. Most of all software is low quality and most companies will fail.

                              His point in saying this is to explicitly refute the notion put forth in Raymond’s essay that open source will produce higher quality software. Having worked in and with software for the past 25 years, I can safely say Mr. Tarver is not wrong.

                              I’d like to go into a deep discussion about the differences between a kernel and everything else but I think the point would be lost on Mark.

                              I seriously doubt that. I’ve met Mark. While he’s not the most pleasant person to be around all the time, I’m certain he can grasp the difference between “a kernel and everything else”.

                              1. 5

                                There are plenty of issues with the linked article, from minor ones like the incorrect possessive its, to the misapprehension that ESR wrote “The Cathedral…” in polemic against closed source (he was attacking the GNU/FSF style of development). Nitpicking on what editor might have been used to write the content, or ages-old point-scoring about kernel vs userland, isn’t actually engaging with the content of the piece.

                                There’s a lot of stuff I don’t agree with in the article, but I do agree that “open source” has become more and more of a sharecropping field for developers, where they’re expected to put in unpaid work that makes corporations serious money. It’s a discussion worth having.

                                1. 3

                                  Fair enough, I hear you and I agree that it is a discussion worth having.

                              1. 3

                                I think I see what this is trying to do, but I can’t see it leading to anything but an unmaintainable mess. It feels like it would be the kind of code that you only throw patches and tests at until it starts passing. I will admit that such a style is nice when you’re exploring or prototyping. Not having to care about structure is nice in that situation. I’m not seeing this working with large projects.

                                Key difference is: there is no contact point between modules. They are always oblivious about each-other [sic].

                                Sure, but there are still dependencies between them. Specifically data and behavioural dependencies. It’s not like you can avoid that. For example, is the input() stuff shared across everything? Controlling access to that sounds like a real chore. Based on what I’m seeing here, it seems to be pushing all the structural complexity of a system into the data.

                                I will have to read the research to get a better idea. This introduction only makes me foresee maintenance and debugging nightmares.

                                1. 6

                                  Debugging, by David Agans (2002). There are is no better book on the skill of debugging out there. (Andreas Zeller’s Why Programs Fail is also great, but doesn’t count as “old”.)

                                  1. 11

                                    I’d recommend “Data and Reality” by William Kent. More of a philosophy book geared toward programmers, but it is asking good questions. The book has been updated a few times since the 70s, so the stale content has been removed.

                                    In the non-technical variety, “Zen and the Art of Motorcycle maintenance”, which was published in the 70s also. It’s an introspection into what quality and expertise is made of.

                                    Also published in the 70s, “The timeless way of building”, which args for looking at patterns in the way people build. This and it’s successor, “A pattern languages” are the inspiration for design patterns. The difference between the original thought and what has been made of it make for an interesting read.

                                    1. 3

                                      The only part of Zen and the art… that stuck with me was the beer can shim.

                                      However most of Zen Flesh and Zen bones is permanently wired into my head.

                                      1. 3

                                        I’d recommend “Data and Reality” by William Kent.

                                        Seconded. Great book. I found it went nicely with The Systems Bible, by John Gall.

                                        1. 1

                                          OOH Data and Reality is even availabe on Audible! Woot I am there! :) Thanks for the recommendation.

                                          1. 1

                                            I’d recommend “Data and Reality” by William Kent. More of a philosophy book geared toward programmers, but it is asking good questions. The book has been updated a few times since the 70s, so the stale content has been removed.

                                            While I came here to second Data and Reality, be warned about the third edition. It was updated after Kent died, removed something like half of the original text, and replaced it with the editor’s (Steve Hoberman) own half-baked ideas. And while the book says it put the new stuff in italics, but at least on Safari it often presents The content as the original.

                                            Try to read both the earlier editions: the content is the same but it’s a book worth reading twice.

                                            1. 1

                                              I’m about 3/4 of the way through the most recent edition now on Audible.

                                              I haven’t read the earlier editions (and may not get to any time soon) but I just wanted to say the sidebars by Steve Hoberman are getting on my nerves. They’re mostly breathless generalizations about the author’s original ideas and I’m finding them to be a distraction I wish I could skip.

                                              GREAT book though, so glad I’m reading it. Thanks @laurentbroy for the recommendation!

                                            2. 1

                                              In the non-technical variety, “Zen and the Art of Motorcycle maintenance”, which was published in the 70s also. It’s an introspection into what quality and expertise is made of.

                                              When reading this one I had a feeling that the entire concept could be more succinctly put instead of constant repetition of the same theme.

                                            1. 2

                                              Almost all inline comments are ones that could be removed or moved while making the code more readable and easier to refactor.

                                              I’m in agreement with @hwayne here: there’s usually a lot of nuance to take into account. Boiling it down to this and applying it as such is, to me, unwise.

                                              As an example, here’s some code from GCC that I’ve been digging in around lately.

                                              https://github.com/gcc-mirror/gcc/blob/master/gcc/lto-streamer-out.c#L410

                                              For GCC, this is pretty new code (and easier to work through than, say, the infamous reload). In the linked function I’d say all the inline comments are helpful and there is no need at all to remove them. In fact, the whole file is pretty good.

                                              Refactoring to get rid of inline comments seems to me to be a very weak reason to refactor. There may be a case for it when the code is young, but when it settles, I think that kind of action is disruption for the sake of disruption.

                                              1. 11

                                                I think there’s room for nuance in all of these, and they’re not clear-cut refactoring wins.

                                                [for viewDidLoad] Which version is easier to read? My vote goes for the second one - it’s easier to read as the method is now shorter - and easier to refactor, as we no longer have to maintain the comment when changing the code.

                                                The second version of viewDidLoad is easier to read… but I’d argue it’s harder to understand! In the first version, the logic was all in one place. In the second version, it’s in three different places. I have to keep jumping between viewDidLoad, setupNavigationBar, and setupTableView to get the whole picture. We also have mutations in three different places, which makes tracking the effects harder too.

                                                Writing the function also means other things can use this, too. So do other functions call setupNavigationBar? In the first version, I knew that its logic only happened in one place of the code. Now I don’t anymore. If I modify it, it might inadvertently break a caller I wasn’t paying attention to.

                                                [for willPresentSearchController] The readability of the code is just as good - and the bugfix code is extracted in its own logical item, a method. It’s fine to keep the comment in place - but now it’s obvious that the bugfix method does one thing, providing the workaround.

                                                The original code also did only one thing, and didn’t do anything but the workaround. It has the same understandability issues. More to the point, though, is the name of the new method: preventSearchBarFromDisappearingWhenSearchControllerIsActive. That’s 62 letters long. It’s much harder to read a comment than ten words without spaces.

                                                Finally, in the original method, you’ve remove the why and only left the what. I have to investigate that method to find out it’s only on iOS9. That increases the chances it becomes code rot.

                                                [for setupNativeCalendarAccess] There should be no reason to keep the code in place - this is exactly what source control is there for - if someone will need the original code, they can find it in the commit logs.

                                                That requires them to know it’s in the commit logs. If it’s in the code, everybody knows it’s there, and nobody’s going to forget about it.

                                                The thing with this example is you have a clear scope: uncomment the code when the calendar functionality is removed. If you’re worried about forgetting it, place a timestamp on it and a calendar task to check it in a month or so. Signing and timestamping comments is a good practice, anyway.

                                                1. 3

                                                  Writing the function also means other things can use this, too. So do other functions call setupNavigationBar?

                                                  This why I don’t apply this kind of transformation without having a good reason. Getting rid of a comment isn’t a good reason. Making the function more navigable and readable is a better reason (sometimes that logic can get hairy). In the example provided by the OP I am unmoved. When I do feel the need to refactor this way, I make it clear the new function is subservient to the first; scoped inside is the best, if possible.

                                                  1. 3

                                                    preventSearchBarFromDisappearingWhenSearchControllerIsActive. That’s 62 letters long. It’s much harder to read a comment than ten words without spaces.

                                                    That’s not even the entire problem. Making it a separate method opens up that particular method to be used outside of the context of when it’s appropriate.

                                                  1. 1

                                                    I want this to be good. I really do. But why must they continue to make the settings a JSON file? Can you pick a less navigable/readable format?

                                                    Also, I have an unreasonable fondness for this bug.

                                                    You are currently not able to reorder tabs when running the Terminal as administrator (it will crash if you try).

                                                    1. 2

                                                      Agreed, I keep checking back every few weeks and I continue to be astonished they haven’t added a settings GUI yet. Isn’t Windows development supposed to be easy these days? It’s sending an awfully weird message that a legit Microsoft team can’t put together a GUI that would have been a no-brainer in the Windows 95 era. Bizarre.

                                                      Edit: for what it’s worth, you can see some discussion in issue #1564 on their GitHub repo.

                                                      1. 2

                                                        This isn’t as good as a proper GUI, but there is a JSON schema for the settings file. That means any editor with JSON Schema support (e.g. VS Code) will give you basic error checking, autocomplete, etc of the JSON file. See Scott Hanselman’s post

                                                        1. 5

                                                          JSON schema, eh? I guess that XML train has come full circle.

                                                          1. 1

                                                            😅🤷🏾‍♀️

                                                        2. -1

                                                          Is this a joke? You Know many MS prodocts still use XML right? JSON is way more readable than that. What format are you even wanting? From a programming perspective, id argue JSON is the easiest to code, as you can usually unmarshal it directly into an object or map.

                                                          I find your whole comment strange, as it’s one I would expect from a non programmer. But I assume that’s not the case if you are using a terminal?

                                                          1. 3

                                                            No, it’s not a joke.

                                                            A settings interface is what this should be, like say, iTerm2. Or at least YAML, like Alacritty, so there is at the ability to comment. Not sure what XML being used in other projects has to do with this. (MS didn’t use XML? Doesn’t matter since both are the wrong interface.)

                                                            Also, why do I care if I can (un)marshal a terminal’s configuration file into an object or a map? I’ve been using terminals for 25 years and have never worked with or known anyone who wanted or needed to do this. I don’t want to write a program to manage my terminal configuration. I just want to change a setting, like fonts or keybindings, every now and then.

                                                            1. 1

                                                              I’ve been using terminals for 25 years

                                                              That may be true, but clearly youve never parsed JSON in any meaningful way in that time. Else you would know the benefit of parsing into an object your language can understand.

                                                              1. 1

                                                                I’d actually prefer json to yaml if I had to hand-edit a configuration file. It’s definitely annoying that json strictly requires no trailing commas and disallows comments, but I’m even more annoyed by yaml’s significant whitespace. It’s always felt less intuitive to me. I’m used to the toml format commonly used by rust projects, and that’s what I’d personally prefer as a config file format, although I’m aware that there are people who have issues with it.

                                                          1. 1

                                                            Usecase: User does not want to see colors on their terminal -> Disable colors in Terminal configuration

                                                            Usecase: Program is not writing to a terminal -> Programs should check if stdout is a tty and check for existence of $TERM variable

                                                            Is there something i miss? I don’t get the necessity for this.

                                                            1. 6

                                                              The article goes into this. Users might well want to explicity configure some tools (e.g. an editor) to output color, but don’t want to spammed with useless color output by a package manager.

                                                              (I’m particularly irritated by command line tools whose color output was clearly not tested outside leet darkmode terminals.)

                                                              1. 4

                                                                (I’m particularly irritated by command line tools whose color output was clearly not tested outside leet darkmode terminals.)

                                                                Thank goodness! Someone else who thinks the same thing.

                                                                1. 3

                                                                  I think the term you want is “angry fruit salad”, and I quite concur. The people who choose default colours in terminal programs I use occasionally (but not often enough to bother with configuring) all seem to have a fetish for garish shrieking colours.

                                                                2. 3

                                                                  I use eshell, and ansi-color codes aren’t always supported, but it’s not quite a dumb term either. I stumbled upon this link while trying to find a way to disable unnecessary color-codes being generated by apt (I know there are other ways, but I wanted to know if this was possible). If this were a pervasive standard, I would have a better experience with tools like these, by default.

                                                                  1. 1

                                                                    My predicament is similar: my main working terminal emulator is M-x shell, and some of the newer cli tools completely disregard the fact that it is pretty much a dumb terminal.

                                                                1. 7

                                                                  My https://two-wrongs.com uses Emacs to generate the HTML, and then nginx to serve it. I have used various systems through the years, but this is the one that really stuck with me. Emacs is flexible enough that I’m unlikely to outgrow it any time soon, and the language is convenient enough to script in. I really like it!

                                                                  1. 3

                                                                    how do you use emacs to generate html? I didn’t know it could do that. So you just literally put your html files onto a server and host it. So simple, I can’t believe I never thought of it.

                                                                    Thinking out loud here, what would be the steps to protect your identity in that situation?

                                                                    1. 41

                                                                      So you just literally put your html files onto a server and host it. So simple, I can’t believe I never thought of it.

                                                                      I…

                                                                      wait

                                                                      what

                                                                      1. 9

                                                                        At one point in time the idea of generating HTML from a program seemed odd. It’s amazing that code gen for HTML is so obvious now that the idea of typing it out by hand is not. Surely there’s a word for this phenomenon?

                                                                        1. 9

                                                                          It’s it called “FrontPaging”?

                                                                          1. 1

                                                                            Analogous to machine/assembly code generation, I suppose, although I don’t think the idea of generating them was ever odd, given how difficult they are to work with.

                                                                            “Abstraction ignorance”?

                                                                            1. 1

                                                                              First, there were Frontpage, Dreamweaver, HomeSite like tools that were WYSIWYG, and “purists” used notepad. Then there were the CGI scripts (which typically hand rolled the dynamic content with string bashing), and included headers and footers, and people used SSI. Then, things in the vein of Blogger, MovableType and (probably many that I am forgetting! Including many Perl libraries that formed the basis of these things, surely) introduced “real” languages meant for the types of templates we know of today, that you didn’t have to be super nerdy to use and understand. It was certainly not immediately obvious to most people…

                                                                          2. 6

                                                                            HTML is just normal text, so emacs can just write a pile of bytes and if the file ends in html and the syntax is correct then you’re good to go.

                                                                            As far as identity stuff, the file itself doesn’t have any metadata about you in it (unless you added it), so you’ll just need to make sure your server isn’t broadcasting things about you it shouldn’t and that your domain records are through a company, friend, or privacy guard.

                                                                        1. 10

                                                                          A lot of his argument seems to be “OOP doesn’t help with complexity because you can get all the features in other ways.” Which is true but not really that relevant. First of all, a lot of the “other ways” are going to have different tradeoffs. Like “leading underscore in Python” or “code documentation” aren’t nearly as good at information hiding as private members. Second, no paradigm has a truly unreplicable feature. You could reproduce this all in BASIC if you really wanted to. The tricky bit is making sure all the features mesh well, and enable-and-encourage a useful style of programming with those features. That’s why it’s called a “paradigm”.

                                                                          I could recreate contracts in C, and I might be able to recreate subtype polymorphism in C, but I couldn’t create subtyped contracts a la Eiffel in C.

                                                                          all OOP programs can be translated into C with minimal effort

                                                                          No, they cannot.

                                                                          1. 4

                                                                            Agreed. The author seems awfully dismissive of that one little bugbear of software: maintenance.

                                                                            But almost all the important OOP features are merely syntactic sugar; all OOP programs can be translated into C with minimal effort.

                                                                            I’m not OOP’s biggest fan and didn’t even dislike the essay that much, but this line displays some staggering ignorance.

                                                                            1. 2

                                                                              No. they cannot.

                                                                              Sure they can, for a given understanding of “minimal”… if it runs on a machine then it can be written in C. The only real question is “with how much effort?”

                                                                              1. 5

                                                                                This is the kind of semantic hair-splitting that undermines the article’s argument.

                                                                                1. 1

                                                                                  I’m not sure we read the same article … it’s a discourse about the specific meaning of “essential”; the argument is semantic hair-splitting.

                                                                            1. 1

                                                                              Learning Colemak on my new Ergodox.

                                                                              1. 9

                                                                                Wow, that first link was a trip. The #NoEstimates people weird me out.

                                                                                When it comes to why estimates are difficult, most engineers and engineering leads throw their hands up in the air and say, “Software has too many unknowns! We can’t tell what unknowns we’ll find, even with the simplest task!”

                                                                                This is the second time in two days I’ve seen this “software is special!!!” thinking. We’re not. Nothing makes software essentially harder to estimate than any other large, complex project. We might not have the training, or the tools, or the theories on how to estimate better. But software isn’t special. Either we can estimate software or we can’t estimate anything.

                                                                                1. 19

                                                                                  My dad has worked in construction for many years, and although we don’t know much about each other’s work worlds, we are always able to connect when talking about project planning, estimations, and management. There are so many parallels that I can’t help but believe that there’s some hope for software.

                                                                                  That said, it’s not like it’s a solved problem in civil engineering projects either. Crazy stuff happens there too. My intuition tells me there is a lack of appreciation for the non-physical complexity in software. If someone finds a pipeline no one expected when digging, it seems easier to grasp the gravity of it versus finding a dependency in code that no one knew about.

                                                                                  1. 8

                                                                                    Same setup here, with the experience of construction sites (actually demolishing though) and software.

                                                                                    In construction I’m used to doubling or tripling the original estimate, but never of “oops, it’s 10x the work now”. But that mostly speaks of experience and apparently more “normal” projects, if you look at Berlin’s BER airport disaster, I guess 100x comes closer…

                                                                                    I hate to turn to this age old bad examples, but I’ve never heard of stuff like:

                                                                                    • oh we DO need a basement after all, throw away the ground level
                                                                                    • we decided to use wood and not cement
                                                                                    • wait, nobody told me we need to put lights in there?

                                                                                    What I did hear:

                                                                                    • no, we wanted the other wall to be torn down
                                                                                    • we want the new door exactly here! (turns out it there was a wall at the back, imagine a T - shaped piece of wall)

                                                                                    But yes, sometimes there are known tasks like

                                                                                    • this wall is 3m x 5m, it will take X hours
                                                                                    • this feature needs one new form and 3 database calls, it will take X hours

                                                                                    and then there are things where you simply don’t know from a one sentence description if they want a garden shack or a new mall.

                                                                                    The main problem is that it’s less tangible and a lot more opaque. On the other hand some things that are 10 minute tasks can seem like magic - that also hardly happens in construction. You don’t just get a surprise benefit by discovering a material(library) unknown to you that will save a week worth of work.

                                                                                    1. 5

                                                                                      If I ask you to estimate the weight of all your colleagues and to guess the total weight of the whole team….

                                                                                      I bet you won’t be far out either.

                                                                                      Some probability distributions, especially physically based ones are thin tailed.

                                                                                      Your guesses are very unlikely to be far off, a smallish sample is likely to be representative, nothing is going to be orders of magnitude different, and when you sum (or average) your guesses, the deviations cancel out.

                                                                                      Other distributions, especially non-physical ones like wealth, software complexity, ….. are fat tailed.

                                                                                      ie. You need very large samples to be able to estimate accurately, yes, quite likely there is one story in the backlog that explodes out to 100x larger than the rest, summing ( or averaging) does reduce the deviation but not really.

                                                                                      What really happens in the software world is when that task blows up by a factor of 100x… Odds on we say, Meh, maybe we don’t need to do that in the 1st release… or 2nd or ..

                                                                                      Estimation is not about deadlines, it’s about risk management. When we see a story blowing up… we need to step in and make some hard choices.

                                                                                    2. 2

                                                                                      I work in Chicago so I immediately thought of the much-delayed Jane Byrne Interchange construction.

                                                                                      https://www.chicagotribune.com/news/ct-met-jane-byrne-delays-20190306-story.html

                                                                                      In January 2015 — just over a year into construction — university workers noticed the building had been sinking and shifting, leaving cracks in the foundation and making it impossible to shut some doors and windows, according to court records.

                                                                                      Over the next 1½ years, IDOT blamed engineering firms it had hired for missing the poor soil conditions that contributed to the problem. That led to a redesign of a key retaining wall that boosted costs by $12.5 million and dragged out that part of the project at least 18 more months.

                                                                                    3. 13

                                                                                      But software is, if not special, different to most physical engineering projects.

                                                                                      Building software is like combining the worst cases in renovation TV shows - you have a heritage listed building with unknown structural issues, a homeowner who followers the builders around everywhere, can’t envision what they want until they see it, and constantly change their mind after work has been completed. And they have a strict budget and need to be in before Christmas.

                                                                                      The fundamental reasons why software estimation is hard are:

                                                                                      • most team leads/scrum masters won’t say no to changes in the estimated scope
                                                                                      • team membership changing due to business priorities
                                                                                      • insufficient investment in quality measures across the board

                                                                                      They are, to a degree, our own fault. We don’t say ‘no’. We don’t insist on quality. We don’t insist on team stability.

                                                                                      In my time as a team lead I pushed as hard as I could on those issues. If priorities changed and some new work needed to be fitted into the current timeframe, I made the product owners pick an equivalent sized piece of work to remove. The team already had a great quality ethic, which I protected by making sure that there was enough time allowed to maintain our test suite etc. I couldn’t really stop management from moving people in and out of the team, but I made enough noise that it was at least somewhat uncomfortable for them. Our estimates were not perfect, but pretty decent.

                                                                                      But it was exhausting, and while I think people respected me, it would have been “career limiting behaviour” if I’d been focused at all on rising up the ranks in that org.

                                                                                      After 6 months I left and found a pure dev job.

                                                                                      1. 11

                                                                                        I’ve been interviewing “crossovers”, people who started off as traditional engineers and moved to software. I’m basing all my claims off what they said. The overwhelming consensus is that almost everything we think about “trad” is a misconception.

                                                                                        Building software is like combining the worst cases in renovation TV shows - you have a heritage listed building with unknown structural issues,

                                                                                        In software, if you need to figure out what’s wrong with the codebase, you can inspect the source code. If you need to figure out what’s wrong with the electrical system, you have to tear down the wall.

                                                                                        One former electrical engineer talked about how often mechanical projects would go wrong. Often a supplier had tons of implicit knowledge about their parts- switching to a different supplier for the exact same design could get you something completely incompatible, simply because of slight differences in the tolerances.

                                                                                        a homeowner who followers the builders around everywhere,

                                                                                        Plenty of engineers complained about this. Scope creep and overbearing clients are universal.

                                                                                        can’t envision what they want until they see it,

                                                                                        Also extremely common. It’s less of a problem in most engineering fields, but most of my interviewees think it’s because they just spent more time gathering requirements in trad.

                                                                                        and constantly change their mind after work has been completed.

                                                                                        I talked to one engineer who had to move a bridge. I’d have to go back and check with her, but I think it was something like “The demographics of the area had changed.”

                                                                                        The fundamental reasons why software estimation is hard are:

                                                                                        • most team leads/scrum masters won’t say no to changes in the estimated scope
                                                                                        • team membership changing due to business priorities
                                                                                        • insufficient investment in quality measures across the board

                                                                                        These happen all the time in trad, too.

                                                                                        1. 3

                                                                                          a homeowner who followers the builders around everywhere,

                                                                                          Plenty of engineers complained about this. Scope creep and overbearing clients are universal.

                                                                                          I can attest to that. I’ve trained and worked in software for 20 years now, but I originally trained to be a TV-repairer. One repairshop I had a placement in during training had a notice on the wall, that could be seen by customers:

                                                                                          We charge 300/hour.
                                                                                          If the customer wants to watch, we charge 600/hour.
                                                                                          If the customer wants to help, we charge 900/hour.

                                                                                          To be totally honest I believe it was meant more as a humerous deterrent than to be taken literally, but there’s no smoke without fire as they say :-)

                                                                                          1. 2

                                                                                            I’ve been interviewing “crossovers”, people who started off as traditional engineers and moved to software. I’m basing all my claims off what they said. The overwhelming consensus is that almost everything we think about “trad” is a misconception.

                                                                                            That’s really interesting, and supports a suspicion I’ve long held that the software industry’s “imposter syndrome” with respect to the engineering community causes is to over-glorify physical engineering.

                                                                                            Although I haven’t been interviewing or studying it, I know quite a few tradesmen (and my father was a plumber and builder). I get the impression that, as you say, estimation is not exactly a precise art for them, either.

                                                                                            1. 1

                                                                                              Agreed on all counts. These are the kinds of things I hear from my father, too. One difference might be that in software we’re too eager to deploy what we’ve got and then never change it. Also, software does a lot less work up front. (Sometimes that code doesn’t get examined much!)

                                                                                        1. 4

                                                                                          Why reproduce the links in the story here? They are clearly visible in the Slashdot blurb, and frankly are more meritorious of submission than the “I noticed this doesn’t work” kind of submission to Slashdot.

                                                                                          Furthermore, the claim seems to be false, according to the Github issue that is linked. (See the update at the end of the first comment.)

                                                                                          The one comment in the StackOverflow question seems to be wrong, too, claiming about the Apple forum discussion “It has been actively removed and Apple is not willing to restore it.” Yet, clicking on the link, I’m able to read it.

                                                                                          A cursory glance of the linked discussions shows that it’s not widespread and probably just the usual kind of bug that shows up. This is sensationalist and not worth anyone’s time.

                                                                                          1. 2

                                                                                            Thanks, I updated the title and comment to reflect this bug has been fixed in the Catalina betas.

                                                                                          1. 1

                                                                                            The article talks about RTL as represented in the compiler and how you write it in a machine description, but there’s another form the author doesn’t mention: what gets printed when you’re debugging the compiler.

                                                                                            To generate it, check out the developer options. If you want a flood, try -da (almost a requirement when debugging internal compiler errors! (ICEs)).

                                                                                            RTL is notoriously difficult to read, both in machine descriptions and especially in printed output.

                                                                                            (insn 2 4 3 2 (set (mem/c:SI (plus:DI (reg/f:DI 82 virtual-stack-vars)
                                                                                                            (const_int -4 [0xfffffffffffffffc])) [1 x+0 S4 A32])
                                                                                                    (reg:SI 5 di [ x ])) "t.c":1 -1
                                                                                                 (nil))
                                                                                            

                                                                                            You can kind of figure out what this is, but the particulars can be important, and aren’t all documented.