Sensible Software Engineering • Hacker News Board

Re: Sensible Software Engineering

#51

Post by sidlls » Mon, Mar 04, 2019, 2:14 AM UTC

peteradio wrote: post #41

gilbetron wrote: post #36

Earlier quoted context omitted.

> Instead, it reduces that number to c' * N with c' That is unproven conjecture. It feels right, but just because it is written as a formula doesn't automatically mean it is correct.

It is an axiom. If your testing is such that this isn't true then you are doing testing wrong, in a self-evident sort of way.

That's about as useful as observing that if your code is such that it doesn't produce the correct result then you've written the code wrong, in a self-evident sort of way.

Re: Sensible Software Engineering

#52

Post by oldgradstudent » Mon, Mar 04, 2019, 2:17 AM UTC

james_s_tayler wrote: post #32

>So here’s the punchline: if you want to be a good programmer then learn a technology and language agnostic formalism. Logic, statistics, and game theory are probably good bets. I think in an abstract sense control theory is a reasonably good bet. https://en.wikipedia.org/wiki/Control_theory I can't say I know it deeply, but a lot of the ideas resonate when I think about software engineering. If you think of everythi…

Spotted the control theorist.

We all think our pet subjects are the right lens to view the world with.

Re: Sensible Software Engineering

#53

Post by p1necone » Mon, Mar 04, 2019, 2:18 AM UTC

neo2006 wrote: post #49

p1necone wrote: post #42

Earlier quoted context omitted.

The other fault in that reasoning is that usually test code is much much simpler than product code. It's a lot harder to write bugs when the structure of the code is just 1. call single function with some input data 2. verify that output data/side effects meet expectations 3. repeat for more sets of inputs.

One of the mistake I see a lot around this is when people start to write intelligent mocks. Usually this is where test bugs reside.

The best is when someone writes an entirely new implementation of something just for tests, and only calls that from their tests instead of the actual product code!

Then you just get blank stares when you try to explain why what they've just done is completely pointless.

Re: Sensible Software Engineering

#54

Post by peteradio » Mon, Mar 04, 2019, 2:20 AM UTC

sidlls wrote: post #51

peteradio wrote: post #41

Earlier quoted context omitted.

It is an axiom. If your testing is such that this isn't true then you are doing testing wrong, in a self-evident sort of way.

That's about as useful as observing that if your code is such that it doesn't produce the correct result then you've written the code wrong, in a self-evident sort of way.

> observing that if your code is such that it doesn't produce the correct result

Hmm. Sounds like you are doing some sort of testing.

Re: Sensible Software Engineering

#55

Post by mynegation » Mon, Mar 04, 2019, 2:41 AM UTC

I enjoyed reading it and agree on many points. One thing that does not seem right is the claim that introduction of formal specification will increase the number of programmers. Yes, it takes a special kind of a person to be interested in fiddling with the code, but I believe the threshold for enjoying creation of formal specifications is even higher.

Re: Sensible Software Engineering

#56

Post by wildmanx » Mon, Mar 04, 2019, 2:44 AM UTC

gilbetron wrote: post #36

Aeolun wrote: post #30

Earlier quoted context omitted.

Arguing from the point of logic and formalisms the author is talking about, this would seem to be true.

> Instead, it reduces that number to c' * N with c' That is unproven conjecture. It feels right, but just because it is written as a formula doesn't automatically mean it is correct.

Maybe we have a disconnect in our definitions of "testing".

How do you define the meaning of it, and could you illustrate how it could, on average over a code base, increase the number of bugs in the product code under test?

Re: Sensible Software Engineering

#57

Post by james_s_tayler » Mon, Mar 04, 2019, 3:13 AM UTC

oldgradstudent wrote: post #52

james_s_tayler wrote: post #32

>So here’s the punchline: if you want to be a good programmer then learn a technology and language agnostic formalism. Logic, statistics, and game theory are probably good bets. I think in an abstract sense control theory is a reasonably good bet. https://en.wikipedia.org/wiki/Control_theory I can't say I know it deeply, but a lot of the ideas resonate when I think about software engineering. If you think of everythi…

Spotted the control theorist. We all think our pet subjects are the right lens to view the world with.

I've never formally studied it. My pet subject is CS tbh. It's just a lens I found one day, picked it up and started inspecting things through it, found it useful, pocketed it and moved on. Comes in handy a lot along with several others I've collected over the years.

Re: Sensible Software Engineering

#58

Post by foobarchu » Mon, Mar 04, 2019, 4:17 AM UTC

wildmanx wrote: post #23

> Bugs are correlated with lines of code and TDD forces writing more code so how can it reduce bug counts? If the test code has no bugs then just write the rest of the code in the same style Nobody has pointed out the fault in this reasoning yet, so I will. The linear relationship lines-of-code vs. total-bug-count is based on independence of bug introduction in different parts of the code. That is, introducing a bug…

I think this holds for well written tests, but if one is not talented in writing them then more tests will simply bolster the bugs in the main code. For example, if a developer generate test data by running the program and copying it's output (something I see far more often than I'm comfortable with), they can tell themselves that section was tested thoroughly and must be bug free. Thus when someones notices an end result someplace is wrong, the first place checked may not be that "well tested" function. Tests are only as good as the domain knowledge of the person writing them.

Re: Sensible Software Engineering

#59

Post by jasonm23 » Mon, Mar 04, 2019, 4:28 AM UTC

painful wrote: post #6

I agree with the part that says Agile (and Scrum in particular) is drinking the koolaid. Managers who don't themselves write any code, but micromanage their workers with their version of Scrum, are the worst.

Effectively Scrum is a poor fit because it's not based on engineering practices first.

XP is better simply because it's based on engineering practices first.

The trouble with any approach is that it's a template and some teams / people rest on those templates in place of actual thought.

Re: Sensible Software Engineering

#60

Post by AdieuToLogic » Mon, Mar 04, 2019, 4:36 AM UTC

From the article:

  So here’s the punchline: if you want to be
  a good programmer then learn a technology
  and language agnostic formalism.

No.

If you want to be "a good programmer", then learn how to define the problem for which you are tasked to solve. The technology is irrelevant. The "language agnostic formalism" is irrelevant.

Unless a person/team knows what must be done, then the rest really doesn't matter. Techniques which help to elicit repeatable delivery certainly are worthy to learn, even to advocate for. But without understanding what is needed, what use are they?