1. 68

  2. 17

    Instead of changing my tools or workflow, I change my design. It’s like designing a house so it’s easy to build, instead of setting up cranes typically used for skyscrapers.

    I loved this. I feel that the current mindset of software builders is infected with a “I can, therefore I will” mindset. Since all the cranes and scaffolding is ‘free’, the pull is irresistible. This is epecially visible in the sector formerly known as Operations (→DevOps→SRE→..). Engineers exhibit an innate pull towards solving the larger problem, generalizing, and aiming for the ‘one fell swoop’ that will complete both the current task and all subsequent ones.

    In my personal experience, doing one thing and doing it well is the only way to get software products off the ground. This applies not only to actual sofware artifacts, but also to chunks of work, or processes. If you need a website, just code up the website. Having to learn how some library author looks at the problem domain is a waste of time in many cases. (Not all, or course. You can learn a lot by studying the work of talented engineers).

    I thought it would be useful remind everyone that the easiest and cheapest strategy for dealing with complexity is not to invent something to manage it, but to avoid the complexity altogether with a more clever plan.

    The author is pretty much channeling the old unix wizards.

    1. 8

      Is anyone aware of the kind of “slow and subtle” niches the author hopes for? Any slow and simple and modern design philosophies, techniques, tutorials, communities, etc?

      1. 16

        I’ve been doing simple web development on the side off and on. I’ve heard of the handmade network. I also like the how the Go community tends to build things, from an operational standpoint. You have the big things, like Docker, Kubernetes, and Mattermost which are big corporate things, but then you have smaller things, like linx, Hugo, or the various things built on boltdb.

        I’d start by removing “modern” as a hard requirement and look at how older, stable tech works.

        Any community where web development has mostly been in one place over the last 7 years probably has a lot of the basics covered already, and isn’t likely to be piling on the complexity in droves. My experiments in doing websites in Erlang (as opposed to Elixir) suggest that is one place where things seem to move slower. I suspect the Python web development is similar.

        Learn some old, mature tools, like make, bash, python, awk, graphviz or TCL/tk, and use them when you have task that fits them

        Build websites with as little JS as possible, just to see how far you can take forms and pages. Take time to evaluate how it works out over time, how the maintenance holds up, and so on.

        You might see what sorts of things the modern stacks are trying to compensate for, or realize that there is an easier way to solve a certain set of problems. Mining the past for ideas allows you too get a notion of the fundamental vs incidental complexity

        1. 5

          I’d start by removing “modern” as a hard requirement and look at how older, stable tech works.

          “Modern” means having options anyway.

          Back in the Old Days, large computers were the only option. They were great for large institutions with large problems or, at least, large endowments to effectively allow young programmers to build games on them, but if you wanted a small computer for something like process control or home office work or similar, you didn’t have that option. Vacuum tubes, and then discrete transistors, only got so small.

          ICs allowed us to make small computers, but they also allowed us to make big computers more efficient, because some problems require big computers, large amounts of compute concentrated in one location to grind away at a task, or large amounts of RAM or storage to handle huge amounts of data, or both.

          Similarly with graphics: We’ve gone from having command lines as the only option to having command lines coexisting with GUIs, each allowing the other to do what it does.

          Do some older practices get replaced? Yes, particularly in hardware. Nobody but a hobbyist would build a computer out of vacuum tubes these days. Cardstock is no longer a valid input mechanism. CRTs are no longer RAM. But progress is more about having options.

          1. 8

            To be fair, I’m not against using modern tech, just that if you want something simpler, sometimes older stuff is where it’s at. Not always, of course, but by comparing the old against the new, one can find where real progress has been made, and where something might just be the fad of the year.

            React, for example, seems to be acknowledged as a real improvement in the state of SPA in JS. It is certainly unlike most things that came before it on the JS side of things, though it seems kinda similar to IMGUI, and some people have drawn similarities to old Win32 code.

            1. 2

              Thanks, I’ll check these out.

            2. 3

              I’ve heard of the handmade network.

              What does “handmade” mean? I read their manifesto, but I have no idea what criteria would be used to define which software falls under their umbrella. Is metafont handmade? Linux? The front page of Google? What about wordpress the software (and not the innumerable wordpress blogs)? All of these were created by a large amount of human effort over years of development. What would disqualify one of the other?

              1. 2

                The way I’ve understood is as a loose analogue for “artisnal”. Projects that can be created by a small team, rather than massive one. But I don’t speak for the group, so YMMV.

          2. 7

            Quite a good article. For me, building things on the web has been very much a “looking it up as I go along” process, even to this day. I do like building simple things, however

            1. 7

              This is a mess.

              • Much of the technical complexity of the web has been generated by web designers who refuse to understand and accept the constraints of the medium. Overhauling the design when the implementation becomes intolerably complex is only an option when you are the designer. This luxury is unavailable to many people who build websites.
              • Suggesting that CSS grid is somehow the reincarnation of table-based layout is astonishingly simple-minded. Yes, both enable grid-based design. CSS grid achieves this without corrupting the semantic quality of the document. They’re both solutions to the same problem. But there are obvious and significant differences between how they solve that problem. It’s hard to fathom how the author misses that point.
              • The fetishization of unminified code distribution is really bizarre. The notion that developers should ship uncompressed code so that other developers can read that code is bewildering. Developers should make technical choices that benefit the user. Code compression, by reducing the bandwidth and time required to load the webpage, is very easily understood as a choice for the user. The author seems to prioritize reliving a romanticized moment in his adolescence when he learned to build websites by reading the code of websites he visited. It’s hard not to feel contempt for somehow who would prioritize nostalgia over the needs of someone trying to load a page from their phone over a poor connection so they can access essential information like a business address or phone number.
              • New information always appears more complex than old information when it requires updates to a mental model. This doesn’t mean that the updated model is objectively more complex. It might be more complex. It might not be more complex. The author offers no data that quantifies an increased compexity. What he does offer is a description of the distress felt by people who resist updating their mental model in response to new information. Whether or not his conclusions are correct, I find here more bias than observation.
              1. 8

                CSS grid achieves this without corrupting the semantic quality of the document.

                When was the last time you saw a page that is following semantic guidelines? It is so full of crap and dynamically generated tags, hope was lost a long time ago. It seems to be so crazy that developers heard about the “don’t use tables” that they will put tabular data in floating divs. Are you kidding me?! Don’t even get me started about SPAs.

                The fetishization of unminified code distribution is really bizarre.

                The point is, I think, that the code should not require minifying and only contain the bare minimum to get the functionality required. The point is to have 1kbyte unminified JS instead of 800kbyte minified crap.

                1. 4

                  New information always appears more complex than old information when it requires updates to a mental model.

                  I feel like you completely missed his point here. He isn’t just talking about how complex the new stuff is. He even said flexbox was significantly better and simpler to use than “float”. What he is resisting is the continual reinvention that goes on in webdev. A new build tool every week. A new flavor of framework every month. An entire book written about loading fonts on the web. Sometimes you legitimately need that new framework or a detailed font loading library for your site. But frankly even if you are a large company you probably don’t need most of the new fad of the week that happens in web dev. FlexBox is probably still good enough for you needs. React is a genuine improvement for the state of SPA development. But 3-4 different build pipelines? No you probably don’t need that.

                  And while we are on the subject

                  CSS grid achieves this without corrupting the semantic quality of the document.

                  Nobody cares about the semantic quality of the document. It doesn’t really help you with anything. HTML is about presentation and it always has been. CSS allows you to modify the presentation based on what is presenting it. But you still can’t get away from the fact that how you lay things out in the html has an effect on the css you write. The semantic web has gone nowhere and it will continue to go nowhere because it’s built on a foundation that fundamentally doesn’t care about it. If we wanted semantic content we would have gone with xhtml and xslt. We didn’t because at heart html is about designing and presenting web pages not a semantic document.

                  1. 3

                    Nobody cares about the semantic quality of the document.

                    Anybody who uses assistive technology cares about its semantic quality.

                    Anybody who choses to use styles in Word documents understands why they’d want to write documents with good semantic quality.

                    You still can’t get away from the fact that how you lay things out in the html has an effect on the css you write.

                    That’s… the opposite of the point.

                    All of the cycles in web design – first using CSS at all (instead of tables in the HTML) and then making CSS progressively more powerful – have been about the opposite:

                    How you lay things out on the screen should not determine how the HTML is written.

                    Of course the CSS depends on the HTML, as you say. The presentation code depends on the content! But the content should not depend on the presentation code. That’s the direction CSS has been headed. And with CSS Grid, we’re very close to the point where content does not have to have a certain structure in order to permit a desired presentation.

                    And that’s my main issue with the essay: it presents this forward evolution in CSS as cyclical.

                    (The other issue is that the experience that compelled the author to write the article in the first place – the frenetic wheel reinvention that has taken hold of the Javascript world – is wholly separate from the phases of CSS. As far as that is concerned, I agree with him: a lot of that reinvention is cyclical and essentially fashion-driven, is optional for anyone who isn’t planning on pushing around megabytes of Javascript, and that anyone who is planning on doing that ought to pause and reconsider their plan.)

                    If we wanted semantic content we would have gone with xhtml and xslt.

                    Uh… what? XHTML is absolutely no different from HTML in terms of semantics and XSLT is completely orthogonal. XML is syntax, not semantics. It’s an implementation detail at most.

                    1. 3

                      If you are a building websites, please do more research and reconsider your attitude about semantic markup. Semantic markup is important for accessibility technologies like screen readers. RSS readers and search indexes also benefit from semantic markup. In short, there are clear and easily understood necessities for the semantic web. People do care about it. All front end developers I work with review the semantic quality of a document during code reviews and the reason they care is because it has a real impact on the user.

                      1. 2

                        Having built and relied on a lot of sematic web (lowercase) tech, this is just untrue. Yes, many devs don’t care to use even basic semantics (h1/section instead of div/div) but that doesn’t mean there isn’t enough good stuff out there to be useful, or that you can’t convince them to fix something for a purpose.

                        1. 1

                          I don’t know what you worked on but I’m guessing it was niche. Or if so then you spent a lot of time dealing with sites that most emphatically didn’t care about the semantic web. The fact is that a few sites caring doesn’t mean the industry cares. The majority don’t care. They just need the web page to look just so on both desktop and mobile. Everything else is secondary.

                    2. 7

                      Meta: Would this not be considered a rant? Although the tone of the article is lighthearted and not incendiary, the author is definitely ranting about how complex webdev is today, and not attempting to educate or inform the user on a technical solution.

                      I think it’s important to tag rants as such, because that tag has a hotness demod, and this kind of story is easily upvoted because people generally can agree on common complaints.

                      Edit: Since this comment is getting a few upvotes – if you agree with my comment, please use the “suggest” link beneath the story to suggest tags as you see appropriate.

                      1. 4

                        Last month, I had to install a package manager to install a package manager.


                        1. 4

                          At the other end of the spectrum, I feel like everything that used to be hard is pretty easy now, or at least way easier. Compilers, debuggers, static analysers, programming languages… writing systems software and embedded stuff is so much easier than it used to be (very possible that I was just doing it wrong before, too.)

                          1. 6

                            His article is primarily about webdev which seems to be uniquely on a fast moving treadmill of continual change and reinvention. The areas you mention are older and more established and most people agree on the right way to do them which means we’ve automated the right ways quite a bit. In the browser and JS worlds the right way changes every few months which means the tools and automation changes every few months too. That’s a lot of mental overhead that’s not directly related to the problem you want to solve usually.

                            1. 2

                              Oh, yes, I know and agree. I keep up with web stuff even though I don’t do it often. I guess my comment was only tangentially related.

                            2. 2

                              Great point. Even in web, it wouldve been way harder to achieve the current level of functionality. There would be an uphill learning process for components without StackOverflow or Javascript-based testbeds for practice. The Web 2.0-style functionality also required native proxies/plugins on client, stuff like Perl on server, and so on. Let’s not forget how hard the portable, auto-updating, look/act-same-everywhere, native apps they effectively replaced are still hard to build if wanting experience similar to native apps on each platform.

                              It was always hard to balance these conflicting goals in or outside of a browser. The trick was building manageable solutions to problems that we then stick with. The churn and endless reinvention of basics are what makes web a pain in many places. I say many places since some take saner approach.

                            3. 3

                              As someone retiring after 40 years in software development, I find this article quite poignant. My conclusion on leaving is that each new generation learns essentially nothing of the lessons of the past. No progress in software development technique and methodology is really made.

                              As evidence of this, let me state that today it is no more likely that a complex, team-based, software project will be successful [1], than it was 30 years ago. I’m particularly referring to the largest software sector:- applications in business, commerce and industry where domain knowledge and requirements are outside of the software team.

                              [1] On time, on budget, and to specification. I reject the new “agile” benchmark that “the software be ‘satisfactory’” as an acceptable measure of success.

                              1. 2

                                Honestly, I don’t see why this post is resonating with people so much (which it clearly is!) Most of the author’s technical points are incorrect, or fail to acknowledge the objective superiority of the newer solution. And most of his issues appear to be self inflicted.

                                No one is saying you need all these fancy new build tools and package managers for brochureware sites. But they are extremely handy when building actual applications.

                                1. 9

                                  objective superiority of the newer solution

                                  Is that so? Even though it were somewhat different topics (Object Oriented Programming, Syntax Highlighting, etc.) a lot of things that people used to call objectively superior turn out to be “subjectively superior” at best if one actually bothers to look at it in an objective way.

                                  Other than that I am inclined to claim that it’s really hard to define superiority of software or even techniques. Few people would argue about the superiority of an algorithm without a use case, yet people do the same thing with technologies and call them better, without mentioning the use case at all.

                                  I think a problem of our times is that one loses track of complexities and anatomies of problems, seeing only a very small port of a problem. Then we try to fix it and on the way move the problem to another place. When that new problem bothers us enough we repeat the process.

                                  This looks similar to looking for something like the perfect search or index algorithm for every use case, even disregarding limits such as available memory. It’s good that people love to go and build generic abstractions. It’s of extreme importance in IT, but it’s easy to end up in a state where progress kind of goes in a circle, when disregarding limitations and trying to find a “one size fits all”.

                                  In web development this would be a framework for both real time, non real time, for rest based microservice architectures, but also supporting RPC, real time streaming, as well as being a blog engine and what not, while both being very low level, going down to the HTTP or even TCP level and a blog at the same time, making all of that equally easy.

                                  This sounds great, and it’s certainly not impossible. However, it still might not be the right way to go and someone will always find some use case that they don’t see covered well enough. Something that isn’t easy enough for their use case out of the box and something that can be done in a more easy way by simply writing it from scratch, maybe just with some standard library.

                                  I don’t say that projects like that are bad. However, since they get reinvented over and over I think it would make sense to instead of trying to invent tools for everything it might be worthwhile do strive for completing or extending the tools to pick from.

                                  And I think that is what’s starting to happen more and more anyway. I even would say that the frameworks we see today are a symptom of it. The set of tools is growing and instead of being multitools like they used to be a decade ago (therefor also not working well with others) they nowadays seem more to be like tool belts, with many already available tools in them.

                                  Or to say it in more technical terms. Frameworks nowadays (compared to a decade or so ago) are less like huge libraries forcing you into a corsett, but more software or library distributions with blueprints and maybe manuals on how things can be done.

                                  1. 7

                                    No one is saying you need all these fancy new build tools and package managers for brochure-ware sites. But they are extremely handy when building actual applications

                                    Except that I see people say that all the time. I see them say it at work. I see them say it on social media. I see them say it at conferences. There’s always some reason why that fancy new tool is needed for the static site they are working on. They need it so they can use LESS or SASS for the CSS. They need it so that they can use react to build the html statically before they serve it… (Yes. I’ve really heard someone say that.). They need it because that one metrics javascript tracking library is only available from npm and they can just use that other build tool to ensure it’s in the right place.

                                    This post resonates with people because while they understand that it should be the way you say it is. They can see people saying clearly silly things with a whole lot of unreasonable excitement everywhere they look. It’s so prevalent that when they see someone in web-dev saying something so eminently reasonable they can’t help but stand up and applaud. It’s not a problem with the technologies themselves. It’s more of a problem with the way the culture looks to the people observing it.

                                    1. 1

                                      Except that I see people say that all the time.

                                      Have an example? I’ve not seen that. I’ve seen lots of tutorials showing how to do $simpleThing with $complexTool, but that’s just because small examples are necessary. I’ve not seen any claims that $complexTool is required for $simpleThing.

                                      1. 2

                                        It might be a matter of emphasis. But when the only examples you can find for your responsive static brochure site are the examples you reference above then it sends a perhaps unintended message that this is how you do those things. I can’t point to specific examples around in person conversations for such things for obvious reasons. But in a way you make my point for me. It’s the reason why when you go to many sites that should be just html css and small amount of javascript you end up downloading MB’s of javascript. From the outside looking in it certainly appears that as an industry we’ve decided that this is how you do things, so why fight it?