1. 2

    Looking forward to seeing the final design of 2.0. This looks nice so far!

    1. 1

      I have given it a go on a small side project and it’s definitely a nice alternative to Rails!

    1. 2

      I have created something similar, but working directly on the DB (PostgreSQL).

      1. 1

        Nice! I started down the DB route but switched to tackling the schema file because I realised that in my role I didn’t have the access needed to run such a script on production, whereas I do have access to the schema file.

      1. 11

        You forgot to account for what the code achieves and how that would be impacted by writing more efficient code.

        In your framing even efficient code would be worse than not writing and running it at all. Therefore the question is does it have positive impact that could outweigh its environmental costs and would spending time improving its efficiency instead of on something else be the best way to improve the positive outcome of the whole.

        1. 2

          That’s a really interesting point! A what point does the utility of the code outweigh the disutility of the electricity it provides? I guess you can think of it like so:


          In this case, it would still be beneficial to increase the efficiency of your code, as that would reduce suffering and increase overall utility. There is probably an argument in here as well around how much utility you can produce per unit of work, maybe in 1 hour you can really increase the utility of the code, but only marginally increase the efficiency, so in that case you are probably better off focussing on the utility of the code.

        1. 43

          How much will this save? A few days ago I did a quick calculation how much it would raise the US power usage if every household would have its own 30W server that’s powered on for 24/7 for a different discussion, and it was such an absurd small percentage of the total US power usage that I didn’t feel it was an important point after all. Unless my quick calculations were wildly off, I’m not so sure that “inefficient code” is a major contributor to power usage and carbon emissions, and is so small that it’s essentially in the noise.

          Of course, there’s a difference between inefficient code and not writing/running code in the first place; your Twitter bot was not “inefficient code”, you just decided to not run the code at all. I feel that quite a large numbers of servers could be shut down this very evening and very little of value would be lost (I’ll not name which to avoid controversy and/or an off-topic discussion), but that’s not really the argument you made.

          I also feel your moral reasoning is a little too simplistic; there are many things we do that can increase the suffering of others, ranging from playing music to driving cars to having dogs to what products you buy in the store and/or what food you eat (which goes far beyond not eating meat or animal products, by the way, but that’s a whole different discussion). Living a life that would not increase the suffering of others would be debilitating, and probably also undesirable. The question should IMO not be “does it increase the suffering of others?”, but rather “does it unreasonably increase the suffering of others?” Would a 0.1% difference in global carbon emissions be unreasonable? 0.01%? 0.0001%? There is no clear answer to this of course, but it does highlight the importance of knowing just how much of a difference this will make.

          And the most important point is that I don’t think that the “individual change in daily behaviour”-model to affect such large changes is very effective; I can’t think of a single example from history where it has. While I’m certainly sympathetic to the goals as such, I don’t think it’s an effective strategy for accomplishing much (even if it would be a non-negligible amount of emissions) and I think time and effort is best spent in other ways to solve this problem, such as better energy sources, government restrictions, or throwing those damn “rolling coal” trucks off a cliff.

          1. 14

            The question should IMO not be “does it increase the suffering of others?”, but rather “does it unreasonably increase the suffering of others?”

            It’s important to remember that this is a very particular moral philosophy, one known as utilitarianism, and there are many arguments both for and against it (as do most things in the Great Conversation). There are moral philosophies that disagree about viewing morality as an exercise in maximizing utility, such as Virtue Ethics or Divine Right Ethics.

            https://plato.stanford.edu/entries/utilitarianism-history/ is a good resource for this, and https://plato.stanford.edu is a fantastic resource on philosophy in general.

            1. 3

              There are moral philosophies that disagree about viewing morality as an exercise in maximizing utility, such as Virtue Ethics or Divine Right Ethics.

              I can highly recommend reading up on utilitarianism in the context of disability. There’s a case for it (some read it as encouraging shifting resources to disabled people instead of egalitarian approaches) and a drastic case against it (often interleaved with the “utility” of an individual being inspected). There’s quite some writing around.

            2. 6

              I work on a pretty busy (top 10k) site written in ruby. The entire production load could be handled comfortably by a single 1U server drawing well under 1kw. That’s got to be cooled, too, so lets call it 1.5kw.

              I mean, that’s not nothing, but rewriting it to draw less power would have comparable effect to wearing an extra jumper in winter so I could use less heating.

              1. 2

                Do you mean it’s handled by a single server right now, or that it could be if it was rewritten to a more efficient language?

                1. 2

                  It’s handled by a small fleet of ec2 instances, which - in total - add up to about 1/2 of what you can pack into 1U.

              2. 3

                If we’re optimising on the level of a twitter bot as the poster hints at, we should probably talk about how much more waste is created just by flipping up your notebook, switching that energy sucker called “screen” on and then writing a tweet by hand.

                Also, the post ignores that there are indeed services to grade your energy usage, and people thinking long and hard about the problem.

                One person I can highlight is Chris Adams, who gave a good and practical overview of this at Heart of Clojure: https://www.youtube.com/watch?v=bTPzvX9-6VU

                1. 1

                  Thanks for reading and giving such a considered response!

                  I definitely agree that the point on suffering should probably be something more similar to what you state (“does it unreasonably increase the suffering of others?”), and I think you are right that the key is defining what does reasonable look like here? It is also tricky because what may be plausibly be reasonable for a single actor, becomes unreasonable if everyone does it. A good example is littering. It will have almost no effect on the environment if I threw away this plastic bottle. It definitely does have an impact if 7 billion people throw away their plastic bottles.

                  With regards to how much you would save, the data does seem to suggest that the electricity usage of cloud computing is not insignificant. I think it follows a similar line of argument to the trash example. For an individual, optimising your code may not make much difference, but if the entire IT industry ruthlessly pursued efficiency (as measured my electricity usage) I believe it could have an impact.

                  That said, I believe without systemic change as you described, it is a little like trying to hold back the tide. However, where we are currently at, that systemic change has not been made, so I believe it is our responsibility to behave responsibly with regards to the environment, or at the very least be aware of our impact.

                  1. 5

                    It seems to me that time (and thus money) spent on ruthlessly pursuing efficiency is probably better spent elsewhere if you want to make a difference, for example my ensuring those data centres use better energy sources, campaigning for political candidates/parties who take the problem seriously, lobbying with policymakers, putting pressures on companies, and so forth. Our time and attention is finite, so we need to prioritize where to spend it.

                    However, where we are currently at, that systemic change has not been made, so I believe it is our responsibility to behave responsibly with regards to the environment, or at the very least be aware of our impact.

                    Sure, and something like not having a car makes a meaningful impact, which is why I don’t have one. But this? I’m not so sure that it does.

                1. 12

                  Bernard Suits wrote a lovely book gradually approaching a necessary and sufficient definition of a game as:

                  engaging in an activity directed towards bringing about a specific state of affairs, using only means permitted by rules, where the rules prohibit more efficient in favour of less efficient means, and where such rules are accepted just because they make possible such activity

                  The book is worth reading in its own right, and I think helps understand that neither programming nor software engineering are a game.

                  The key reason is that in a game you erect elaborate constrictive rules that everyone knows exists, and everyone knows everyone else knows, etc., and we act within the confines of the rules to engage in the activity. In software engineering, in my experience, often its the rules themselves that are most in doubt. What does the customer want? What does the customer need? What is a definition of security in this context? Is this system “fast” enough? What does fast mean?

                  In software engineering there is so much doubt about the desired “state of affairs” and “rules” that coding is, to be frank, the trivial part of the exercise. Rather than being a winner (most test coverage! minimize computational complexity!), or being a loser (stop writing bugs! write end-to-end tests!), you spend most of the time defining the problem space, understanding who needs what and why and by when, and then coming up with a set of milestones where you gradually build up confidence and learn more as you build towards a solution.

                  Also software engineering is ruthlessly efficient. If the most efficient solution is to do nothing, or indeed get rid of something, that is the path forward. Haha this reminds me of that classic line from War Games: “Strange game. The only way to win is not to play.”.

                  This may reflect my personal experience, and I definitely did not feel this way as a junior developer when I first started working.

                  1. 4

                    That sounds like it’s a good definition of game in conversational English, but it is definitely not the definition of a game in game theory (one of the core areas of mathematics in computer science), which is how I interpreted the article.

                    1. 2

                      That’s gone straight on my Goodreads list!

                      I think this is a really good point, though one could definitely argue that some project management philosophies can turn “erect elaborate constrictive rules” at times! On the whole, I would agree that software engineering is not a game. I have tried to clarify my thinking on a comment above

                      1. 2

                        coding is, to be frank, the trivial part of the exercise.

                        I think that’s the author’s point. You usually can’t make the business work through brilliant code alone, but you can kill it by failing to meet some floor quality level. It’s a “loser’s game” because returns to excellence are low while the cost of inadequacy are high. This means the outcome is driven by reducing basic errors more than reaching unique accomplishments.

                      1. 20

                        I think it’s a specious analogy. Programming isn’t a game any more than any other art, craft or engineering discipline is a game. You can certainly view “the market” as a game, but the aspects of programming that matter to a programmer aren’t any more relevant to that than they are to the business of selling anything else: fitness for purpose, price point, speed of iteration, customer service, etc. These are not aspects of programming per se, they crop up in programming businesses like they would in any other business. Being a master carpenter doesn’t automatically make you a successful furniture manufacturer either, and being a lousy one doesn’t preclude you from having a successful furniture business either.

                        Over lunch, I realized I actually find the “winners’ vs. losers’ game” concept interesting, so I’m glad I read the article for that.

                        1. 4

                          I agree with this. Software and programming are closer to art than they are game.

                          Modeling software creation as a game quickly results in some obviously bad conclusions, like measuring lines of code output.

                          1. 3

                            This is an excellent point, and I certainly didn’t intend to trivialise programming. Programming is as much an art form as it is anything else. In fact, I think Knuth sums it up nicely in this quote.

                            We have seen that computer programming is an art, because it applies accumulated knowledge to the world, because it requires skill and ingenuity, and especially because it produces objects of beauty.

                            What I was trying to explore in the piece is the idea that, like in a game, as programmers we normally have some sort of goal. In tennis, that goal would be to win the match. For programmers, that goal may be to produce high quality software. In a lot of scenarios, perhaps the best strategy to reaching that goal is to focus on avoiding actions that frustrate your attempts. In tennis, that would be try to avoid hitting the net, rather than focussing on trying to outsmart your opponent with a clever backhand. In programming, that might be try and be extra careful to avoid bugs, rather than implement some very complex algorithm.

                            It is likely not a perfect analogy, but similarly to you, I think the “winners’ game vs. losers’ game” is a really interesting concept, and I believe there is something in there relevant to our field.

                          1. 13

                            Structure your code in such a way that you don’t have to commit to major decisions up front

                            In so doing you have committed a huge decision that will inform the entirely of your design process, and that is the decision to do everything so that you don’t have to make a decision.

                            You could never right if you didnt allow yourself to be wrong.

                            1. 6

                              This implies that the only way to make a code base flexible is to add code that supports any given use case. I don’t agree.

                              To make a code base flexible, simply allow the existing code to be changed when (not if) the reality is different than expected.

                              The code bases that are most suitable for this in my experience, are the ones that are not designed for the future, but are the best match for the current feature set. Until a new feature comes in and the design is changed to match the new feature set.

                              1. 3

                                Strongly concur. I’ve lived through ongoing development of products where someone committed to the decision to make every feature flexible in case it might need changing later and it sucked. Everything was much harder to work with, it was much harder to find out where any given decision was being made in code. To add insult to injury, by and large the places we did find we did need flexibility were not the places where it had been preemted.

                                The one thing I would advocate for is to stick “v1” in your API URLs somewhere so you can do a phased migration when you eventually decide that the first design was terrible and you want to redo the interfaces

                                1. 5

                                  Completely agree those types of codebases tend to be the worst (and it is frustrating that “flexibility” is not a measurable quantity yet people tend to trade measurable performance and readability for it, but that’s a rant for another day…)

                                  However, my take-away from the OP was not to build a flexible architecture (and by consequence, end up with Enterprise Solutions as I like to call them), but to instead treat architecture like a game of Sudoku, where you fill in squares as they become obvious but not beforehand.

                                  (Of course, very hard games of Sudoku (much like architecture) will get to a point where a decision will need to be made which isn’t obvious, and can have drastic consequences down the line, such as an unsolvable game or a complete re-architecture)

                                  1. 5

                                    I like tef’s “build code to be easy to throw away” lecture for making this point unambiguously. <3

                                    1. 4

                                      my take-away from the OP was not to build a flexible architecture (and by consequence, end up with Enterprise Solutions as I like to call them), but to instead treat architecture like a game of Sudoku, where you fill in squares as they become obvious but not beforehand.

                                      Yes! Love the sudoku analogy, really nice way to think about it.

                                  2. 1

                                    That is an excellent point! As soon as you do anything in a software project you are making major decisions - architectural paradigm, choice of programming language etc. I guess I am trying to be a proponent of avoiding making every major decision up front if you don’t have to.

                                    1. 2

                                      I think you can actually go one step further: don’t shy away from changing the architectural paradigm and even the choice of programming language if the changing insight in the functional specification asks for it. If you don’t allow yourself to do this, you will always end up with a sub-par system design. Because as you so eloquently point out in your article, the spec, or at least your understanding of it, always changes during development.

                                      Of course there is a tradeoff to be made between having the perfect system design and the reality of having to actually deploy the system at some point, but that’s a different discussion. The fundamental insight is that in an ideal case, you never design a system upfront but instead let the design evolve along the way.