Threads for acorkery

  1. 1

    Hmm. A nice theory, but I’m not convinced it adds much. I think each test should be an explicit statement about the intended behavior. Set something up, execute something, check the result. The random “mutation” shouldn’t be considered in isolation - our code doesn’t randomnly mutate > to >=, someone usually intentionally (or indirectly) makes that change. If the test suite is well designed (nothing to do with code coverage), it should catch a case where logic is changed. This should be caught by a responsible code review when the initial code is written - ensuring every branching behavior is documented in the test suite. Focus on the design skills, not relying on a code mangler to simulate how your code base evolves over time. Also, I hope the title is a joke :) Nothing ever dies in the software world, it just goes round-and-round.

    1. 8

      our code doesn’t randomnly mutate > to >=, someone usually intentionally (or indirectly) makes that change.

      The idea is that human beings are fallible, and it is possible that such a change could have slipped through in the code (even under reasonable reviews and static analysis). Say the code with >= was the correct one, and what you have currently is >, the question is: was your test suite sufficient to distinguish the behavior of the correct from the incorrect. Mutation testing has nothing to do with how code evolves over time.

      1. 3

        Just to add on to what vrtha said.

        If the test suite is well designed (nothing to do with code coverage), it should catch a case where logic is changed.

        Exactly. Mutation testing can be a tool for helping identifying if a test or suite isn’t well designed. Mutation testing is for testing your tests if you will. A pathological example might be testcase() { test.assert(true) }, when you have a bunch of mutants (versions of your code where that test still passes), you’re inclined to take a look at the test and realize it’s not really testing anything.

        I have discovered “Real Bugs” by using mutation testing, I think in an environment where it is lightweight enough it absolutely adds value.

        1. 1

          Good points there, I don’t mean to imply it’s a bad idea. It’s a very interesting concept trying to assess the quality of a test suite in an automated way - and technically sophisticated. My point is that writing code is a very human endeavour (for now) - the intent is everything. The code is just an expression of a set of instructions.

          The idea is that human beings are fallible, and it is possible that such a change could have slipped through in the code

          Because it’s humans writing it, of course there will be errors, and more relevant to this discussion, oversights in practically every program. For example, assumptions that are proved invalid under certain conditions. But the combination of descriptive tests and the code itself should be the baseline for assessing the correctness. Altering the code under test to explore gaps in the test suite seems wrong to me as the aim should be to have a test suite that explicitly states the behaviour of the code (bear in mind I’m TDD brainwashed). A human (the developer, the reviewer) should be able to assert whether the test suite meets this requirement.

          when you have a bunch of mutants (versions of your code where that test still passes), you’re inclined to take a look at the test and realize it’s not really testing anything

          I like this idea - identifying tests that provide false positives or don’t add value. I’d say it’s a rare enough occurrence though to justify another level of testing. Sure it happens all the time, but most of these should be caught by regular reviews of the test suite - and may not be causing harm if they’re not caught other than hygiene.

          I’m not against automation. I totally see the value of generating exploratory test data and particularly like the idea of property-based testing (QuickCheck, FsCheck etc.). But changing the code under test is like moving the goalposts. It’s no longer what was expressed at design time, so the test suite is no longer valid, with respect to what is being tested.

          Ultimately I think it’s an intellectually appealing idea, but not that useful in a practical sense for general purpose development. I could see it being useful if you were writing a math library or something very deterministic in nature - something where the range of possible inputs and variations could be huge and not easily expressed in static tests.

          This is all just my two cents, totally appreciate it could be a very worthwhile approach for others. And to be fair I haven’t tried it outside noddy examples. Just jars with my world view :)

      1. 8

        Following any proscriptive approach (agile or otherwise) doesn’t work in my experience. People seem to be completely seduced by the idea that there is a magic methodology that works for all development teams. Appopriating models from other industries (Lean Manufacturing, Kaizen) and selling them as cookie cutter solutions..

        It’s a shame the agile manifesto ever became more than an enlightened discussion-starter. Maybe that happens when you set down a manifesto!

        Organizing the work of a typical development team (of 3-8 people) is not that hard when you don’t fixate on process between deliverables - i.e. trusting competent, motivated people to do what they’re good at.

        The “methodology” should not go beyond:

        1. Define what you need to do - one sentence per feature/capability
        2. Roughly size the tasks and choose a deadline
        3. Prioritize
        4. Do it :)
        5. Assess
        6. Go to step 1

        Sorry if this comes across as arrogant and dismissive, not intended as such. I just think a large portion of the software engineering industry is deluded.

        1. 5

          competent, motivated people

          Hints at your unstated step 0:

          1. Find competent motivated people who focus on solving business problems, build pragmatic maintainable systems, and choose technology based on merit, not resume bingo.
          1. 2

            What of a complex product, where domain knowledge is outside of the development team? Consider the outcome of your approach for say a Payroll System?

            Let’s say I want you to write a simple CLI based double-entry general ledger program. I suggest you could not do either steps one or two of your methodology with success.

            1. 2

              I’m not saying to write one sentence to define all that you need to do to build a general ledger program. Defining what you need to do could be a series of conversations with stakeholders, team brainstorms, requirements gathering - getting an shared understanding of the problem in whatever way works best for the project team. My point is that you don’t need to proscribe how that task definition is reached (appreciate the irony of me proscribing it :) You don’t need a mental model to follow for every project.

              Regarding estimation, this falls out of defining the problem as a series of discrete capabilities of the system. In your example, an accountant could help define what the acceptance criteria for the simplest possible application that could be considered a general ledger. From that a team that understands the domain should be able to break it down to features or capabilities that can be easily described. That may result in more than 1 iterations worth of work, but some experienced heads should be able to give estimates within 20% accuracy for each capability.

              Of course, I’m also not implying that everything is simple. I threw out that 1-6 cycle only as a argument against process-heavy methodologies. In a complex system, that cycle could be very short and only cover a fraction of the final product.

              Hell, much of what I’m rabbiting on about is agile stuff, my only point is that I think agile is only useful as a starting point for a team to find their optimal way of working together. As far as success goes, I’d say it’s far more important to have the right people and attitudes within a team than following the 10 Commandments of Agile. A human project team isn’t a machine to be oiled.

          1. 4

            I’d start with defining what the characteristics of a “good” architecture are. For me it’s things like:

            1. The system is reliable (new features are integrated quickly and without unwanted side effects)
            2. The architecture is easy to describe and understand (minimum complexity).
            3. The system is easily supported (it’s transparent what the system is doing from end-to-end, quick to discover the cause of unexpected errors)
            4. Flexible and easy to extend (think of a dependency graph, is it easy to make small changes without affecting other unrelated parts of the system)

            From thinking through what a “good” architecture means for you and your team, you could do retrospectives or other after-the-fact analysis on development work. e.g. for point 4 above “what % of the dev effort on that feature was related to refactoring the system to support the feature, as opposed to actually implementing the logic directly related to that feature”. I know that seems a bit vague and subjective, but having the conversations with your developers will bring up more opinions about the quality of the architecture.

            1. 15

              I gave it 5 full days

              It took me two days to feel comfortable in Go. After almost 18 years of making websites, and I guess of those years using PHP, it is easy to pick up a new language. The concepts are universal, you only have to learn the new syntax.

              In theory the concepts are universal, however there’s so much learning involved in any stack that it’s naive to think you can jump from one to the other in a number of days (and be equally as productive). Serious bias in his comparisons - he seems so familiar with the PHP tooling that he’s looking for interchangeable features in Go. Sorry, it doesn’t work like that.

              For anyone bored or dissatisfied by their current development tools/platforms, by all means try others. But start small. Build something limited in scope that gives you a feel for the language, runtime, packaging, deployment, tooling, community etc. And don’t make a big deal about it if it doesn’t work out.

              1. 3

                I think coding tests can be useful when it’s a junior role and most of the candidates are recent graduates or have little commercial experience. It gives the candidate a chance to distinguish themselves and can make the subsequent interview less intimidating as they’ll be on familiar ground - discussing how they attacked the problem, why they chose one solution over another etc. Can be revealing.

                Though I agree for more senior hires, it can be almost insulting to ask someone who feels like their resume speaks for itself to spend 2-3 hours of their spare time proving they’re up to snuff. Probably for more senior positions, a detailed technical phone interview might be the way to go.

                1. 3

                  Flash Boys by Michael Lewis. Book about High-frequency trading on Wall Street, rigging markets with routing algorithms etc. Really good so far. Reads a bit like a thriller, doesn’t go too far into the tech side of things but probably a lot more accessible because of that. Would recommend it.

                  1. 12

                    I thought it is pretty obvious that we’re trying to suppress wages. However, that’s where my agreement ends. What we need is dramatically higher taxes for income and inheritance above a certain threshold. I’m thinking like 90% tax (progressive) on individual income exceeding 100x 2000x minimum wage per hour (a nice $3M at $15 an hour) and twice that for inheritance (also progressive). We will need broad agreement to make sure no one has “attractive” tax regime. We then fund basic income with this money and do something which we’ve needed to do for a long time: cut costs.

                    We need to cut costs in education. We need to cut costs in healthcare. We need to cut costs in real estate. Cutting costs is very important for this plan to succeed. No more nimbyism. We make sure nobody starves or dies from simple diseases but no more tax credits or deductions for anything. There well be some pain but it will be worth it.

                    1. 1

                      Well, I agree with increasing efficiency.

                      1. -5

                        Wow.. I know I shouldn’t bother but you’re just too much..

                        You’re basically suggesting that governments everywhere rob “overly wealthy” people super fucking hard, and prevent them from being able to escape that robbery anywhere, and.. somehow you expect them to keep working hard so that the ass-raping can continue indefinitely so that you can sit at home and.. pursue your lifelong dream of finger-painting abstract art, for the betterment of mankind?

                        Look at your country’s budget numbers and do some basic math on what it would cost to give everyone “free money forever”.

                        Then think about things from a productive person’s perspective. If 100% of the fruits of your labour are forcefully taken away, you’re an outright fucking slave. If 50% are taken away, you’re like a 50% slave.

                        You are not the arbiter of how much money is “enough” for anyone else. You can decide how much money is enough for you, personally, but other people are their own, separate, living, breathing individuals.

                        Wake the fuck up from your socialist stupor.

                        1. 9

                          Could we please not use terms like “ass-raping” so lightly? This is a forum for adults and professionals, and at the very least I’d hope we can all be respectful to each other.

                          1. -5

                            Oh gosh golly gee, someone has a potty mouth!

                          2. 5

                            Then think about things from a productive person’s perspective. If 100% of the fruits of your labour are forcefully taken away, you’re an outright fucking slave. If 50% are taken away, you’re like a 50% slave.

                            You probably need to define what you mean by a productive person. And it’s not “forcefully taken away”, “robbery”, “ass-raping”. You declare your taxes and pay them. Most levels of remuneration rise/fall based on effective tax rates. The rules are well understood. Don’t want to pay so much, tough luck.

                            You are not the arbiter of how much money is “enough” for anyone else. You can decide how much money is enough for you, personally, but other people are their own, separate, living, breathing individuals.

                            What about consensus and rules that are aimed at leveling the playing field in terms of opportunity? If you went out for pizza with 3 friends and 1 of them took 9 slices because he decided that was enough for him, would the rest of you be cool with that?

                            1. -3

                              And it’s not “forcefully taken away”, “robbery”, “ass-raping”.

                              Sure it is.

                              You declare your taxes and pay them.

                              You seem to be overlooking the “.. or else!” part, which is what makes it robbery, and to be more precise: extortion.

                            2. 5

                              The super wealthy aren’t generally that way because they ‘work hard’ or ‘are productive’, they are generally that way because of theft* or inherited wealth. So yes, we should tax their income, their wealth itself, inheritances, and so forth, and make sure that there is nowhere they can escape it. Also, taxation isn’t even vaguely similar to slavery.

                              *: Theft here meaning everything from colonial plunder to corrupt self dealing to rentiership to exploiting workers, and so forth.

                              1. 1

                                what you mean by ‘super wealthy’ or ‘generally’? You should be more specific with some references.

                                The only millionaire I know personally, worked hard, but also efficiently, and was very intelligent in the way he did business. He doesn’t work 1000 times harder than others, but he never exploited anyone or stole anything to my knowledge. More importantly, there was nothing stopping another person from doing what he was doing.

                                1. 2

                                  I think 100x minimum wage is generous enough. I’m sorry but I didn’t mean it to sound like taxation as a punishment. I apologize for my poor choice of words. Yes, taxes are involuntary for the individual but it isn’t about taking from Peter to give to Paul.

                                  I oppose the current plan for “free college” in New York. I think no government program should have a ceiling for income.

                                  I think we need better propaganda around taxation. We should try to make people feel proud for paying taxes. This is why I want to reduce government spending (the administrative overhead). I don’t think it will be easy or straightforward but I believe it is possible.

                                  1. -2

                                    For your sake, I hope you’re trolling.

                              2. 4

                                The business takes a percent of my surplus labor that is likely much higher than 50% because they have money, higher taxes would help remedy that. You’ve focused on the government taking your money and have blindly ignored the individual taking your money.

                                1. 4

                                  somehow you expect them to keep working hard so that the ass-raping can continue indefinitely so that you can sit at home and.

                                  Many poor people are working very hard as well. Working 3 or 4 jobs and not making it out of poverty. The idea that people are rich because of hard work doesn’t seem to have much evidence behind it and there is some evidence that many rich people are there because of luck. That isn’t to say they don’t work hard but rather that taxing them doesn’t mean their hard work is being taxed but rather their luck.

                                  1. -1

                                    People don’t seem to realize that tax is letting someone else spend your money in terribly inefficient ways, or they will lock you up. Also, the threshold for ‘wealthy’ is always higher than the person suggesting it earns.

                                1. 3

                                  This article is important. The title maybe doesn’t do it justice as it seems like another “you don’t use facebook, they use you” article. Also, the length will put off some people, but I think it’s really worth taking the time to read.

                                  Lanchester raises an important question around the contradiction between Facebook’s (and Zuckerberg’s) publicly expressed motivations - connecting the world, improving lives - and the traits the company has displayed during it’s brief history. If individuals have invested so much personally in Facebook, and it wields so much power, don’t we have the right to hold them to account as we would a government?