1. 5
  1.  

  2. 5

    Quality is not negotiable. […] Our only measure of progress is delivering into our customers hands things they find valuable.

    I once asked Holub on Twitter what you should do if the client doesn’t consider security valuable. His response was something like “then don’t make it secure.”

    Edit found the thread, someone else was taking the hardline, but he was still handwaving away a lot of the concerns. I’ll be honest, I don’t really Holub’s online personality or any of his stances, so that might be coloring how I see this.

    1. 3

      “effective software development” occurs in a realm abstracted away from “software development that people with money pay for”.

      One would assume they were related somehow, but the computer industry has a long history of particularly successful businesses succeeding despite, rather than because, of their development practices. Alas, business success is then equated, by those desirous of business success, with Good/Effective Software Development practices.

      And so life gets worse.

      1. 3

        I think the comparison to radium/asbestos is apt, and ultimately while I try to practice some basic degree of professional ethics myself, I don’t think we can really dig ourselves out of this at scale without externally imposed regulations.

        See also: https://idlewords.com/talks/haunted_by_data.htm

        1. 1

          I’ll be honest, I don’t really Holub’s online personality or any of his stances, so that might be coloring how I see this.

          I appreciate your honesty and share your feelings. I find that Holub’s attitude tends toward the opposite extremes of “idealism” and, at the other end, “give them what they ask for” which can be hard to reconcile. I see shades of that extreme dichotomy of approach in this list.

        2. 3

          All in all a great list, even though it is a bit long.

          1. Outcomes matter more than output. A focus on outputs yields sub-par outcomes.

          Yes, but no. While in the end the outcomes matter for the success of the company, I believe that how it came to be is more interesting for feedback and learning. Outcomes are prone to circumstance and sheer luck, the actual execution is not. In hindsight everything of course looks much clearer (which can be deceiving), but decisions should still be judged in context of the timeframe. From this perspective good feedback can be gathered: Did we have enough data to make this decision? Could we gotten more data and would’ve this influence the decision? Should we update our decision making process? What would we do differently next time? It is totally possible to have a good outcome, but change is needed or to have a bad outcome and everybody would do everything the same the second time around.

          For more information I can recommend “Thinking, fast and slow“ and “Creativity Inc.“

          1. 2

            Simplicity is essential. This rule applies to everything from organizational structure and process to the code we write. We do not waste time building (products or organizations) for a future we cannot predict.

            YAGNI is a very very minor contributor to simplicity.

            By far most complexity arises from kludging new stuff into old stuff and never removing old stuff or pausing and rethinking and redoing the architecture so it fits what we’re doing now.

            “At first I hoped that such a technically unsound project would collapse but I soon realized it was doomed to success. Almost anything in software can be implemented, sold, and even used given enough determination. There is nothing a mere scientist can say that will stand against the flood of a hundred million dollars. But there is one quality that cannot be purchased in this way - and that is reliability. The price of reliability is the pursuit of the utmost simplicity. It is a price which the very rich find most hard to pay.” ― C.A.R. Hoare