Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sensible Software Engineering

scriptcrafty.com

Post reply on HN
Print view View original

31–40 of 77 posts

Re: Sensible Software Engineering

#31

Post by Aeolun »

pytester wrote: post #11
leetrout wrote: post #9

Earlier quoted context omitted.

I am a big fan of Nomad's scheduler and the code is easy to pull in to an existing Go project. It doesn't have everything Kubernetes has but I don't think it needs it, either. Kubernetes has for sure won the popularity contest but the overhead involved in running it The Right Way™ on your own is a lot. Given what I've seen I would advocate for OpenShift if you like RedHat products / projects or sticking with Kubernet…

I have a sneaking suspicion that Kubernetes is another Ruby on Rails waiting to happen: https://trends.google.com/trends/explore?date=all&geo=US&q=r...

We’re still in the popular phase.

https://trends.google.com/trends/explore?date=all&geo=US&q=r...

Re: Sensible Software Engineering

#32

Post by james_s_tayler »

>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 everything as basically an n-dimensional vehicle with an interface to control it and the control mechanism is used to set all the parameters relevant to the system then a few things follow:

  every system has a safe operating envelope
  parameters are usually linked to eachother such that turning one up turns another down
I find there is a lot of mileage to be had about thinking about which parameters are linked to eachother and when you get excited about turning one of them up (ie you bring in TDD or a Kubernetes type solution) what is the effect you are having on the other parameters? That's where a new source of pain is going to come from. The biggest mistake I see in reasoning about these kind of things is being blind to the negative side of the trade-off due to the overwhelming excitement of finally being able to jump on the bandwagon and join the cargo cult. You have to train yourself to hunt for the parameter that is being affected indirectly as that's the most important side of the trade-off. You need to reason about whether or not the indirectly affected parameter's new value would take you outside of the safe operating envelope.

With every decision we make about systems we build and run we are essentially trying to steer them, albeit clumsily, in this manner.

Re: Sensible Software Engineering

#33

Post by Aeolun »

gav wrote: post #16
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.

The majority of issues I see with Agile and Scrum is that it's a process added by people external to the teams and it's treated as a rigid process to be followed. I've worked with teams who have had to suffer through a 45-minute standup every morning that was immensely painful. They were just following the process as best as they understood it from a couple of days with an "agile coach" and didn't really understand w…

Just the fact that a manager doesn’t code doesn’t mean they’re providing their teams with any support.

Re: Sensible Software Engineering

#34

Post by pintxo »

gjm11 wrote: post #28
userbinator wrote: post #21

Earlier quoted context omitted.

The question that always comes to mind whenever testing is discussed is "how do you know the test code is itself free of bugs?" I distinctively remember once posing that question in a meeting about testing, and a manager replying --- seriously --- with "then perhaps the test code should itself have tests." Someone else must've come up with that before too, because (at a different job) I've also worked on a codebase w…

You don't know that the test code is free of bugs. You don't need to. Case 0: No bugs in the test code. All is well. Case 1: Bug in the test code that causes some bugs in the real code not to get caught. That's bad, but you're no worse off than if you didn't have the test at all. Case 2: Bug in the test code that causes correct real code to look buggy. Result: the test fails, you look for problems, most likely you fi…

I see 5 cases:

    Code  | Test  | Result
    --------------------------------------------------
    fine  | fine  | a) We have a regression test, yay!
    fine  | buggy | b) Someone breaks the code to make 
                       the test work. Oops.
                    c) Someone fixes the test, we have 
                       a regression test, yay!
    buggy | fine  | d) We'll fix the code, and we have 
                       a regression test, yay!
    buggy | buggy | e) Bug remains in code. Oops.
If the probability of introducing an error is p,

    Code  | Test  | Probabilities      | p = .01 (one in ten)
    --------------------------------------------------
    fine  | fine  | a) (1-p) * (1-p)   | .9801
    fine  | buggy | b) (1-p) * p * .5  | .00495
                    c) (1-p) * p * .5  | .00495
    buggy | fine  | d) p * (1-p)       | .0099
    buggy | buggy | e) p * p           | .0001
So we see, probability for:

    no harm done                 .9801  (a)
    bugs found + fixed           .01485 (c,d)
    bugs introduced / not found  .00505 (b,e)
The above completely ignores the fact, that depending on the code base there will be significantly more test code than production code. But then test code is quite often highly redundant, and might actually have a lower defect rate itself.

Also the probability on introducing an error in the production code and the test code, might actually not be statistically independent, which I assumes here. So take with a grain of salt.

[Edit] Actually d) could also end negatively. Guess a working model would have to take into account that on failing test cases, a sensible developer should take a step back and reason about why this happened. So the negative outcomes would be (hopefully) less likely than the positive ones here.

Re: Sensible Software Engineering

#35

Post by paulddraper »

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…

Yeah, it's like saying "CAP says partitions decreases availability/consistency, so putting your app servers in a scale group will make things less available/consistent."

That's really superficial analysis. Yes there is some fundamental tradeoffs. But it is possible to change the properties of a system or combine them in intelligent ways and move the curve.

Or it's like saying that speedometers make your GPS less accurate due the Heisenberg principal.

Re: Sensible Software Engineering

#36

Post by gilbetron »

Aeolun wrote: post #30
gilbetron wrote: post #27

Earlier quoted context omitted.

Do you have an actual source that corroborates that with actual data? It seems true, but I haven't found anything that actually tests the premise. I've found studies that show that code with lots of unit tests tends to be more bug free, but not anything about whether unit tests increases (or decreases) development time or whether test code actually has less bugs. I think it would be interesting if there is also a mea…

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.

Re: Sensible Software Engineering

#37

Post by keithnz »

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…

good recommendation, if the author understood control theory he'd understand that code that feedbacks on code is quite different than code with no feedback loop.

while I find it hard to find anything I'd recommend about the authors article as most of the reasoning seems a little off, I can understand the sentiment of the article .

Agile and TDD are really recognition of control theories ideas of feedback loops keep things in better control and can adapt faster vs long feedback loops going out of control far easier. This is more targeted at the human side of creating software. Nothing to say there aren't better strategies than TDD and Agile techniques, however I think that principle of feedback loops to give confidence will stay in some form. I think there is a LOT more to be said about engineering / designing correct, robust, and secure software.

Re: Sensible Software Engineering

#38

Post by chii »

sombremesa wrote: post #25
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…

Tests don't exist for solving bugs as much as they exist to prevent regression. Writing exhaustive tests is not sufficient to bring c' to zero, because some of those bugs exist because of the developer's own presumptions about how code should behave.

But testing exhaustively means the full range of inputs are used, and therefore, if a bug arises as inputs not considered by the dev initially, it would show up as a failure.

What you're actually saying is that reaching full exhaustive testing is near impossible.

Re: Sensible Software Engineering

#39

Post by WrtCdEvrydy »

danmaz74 wrote: post #29
WrtCdEvrydy wrote: post #22

Earlier quoted context omitted.

Good for me, I must made about 500,000 from moving Rails to other more modern stacks... I'll learn Kubernetes just as it dies off and start moving people's shit to whatever's next.

Out of curiosity, which more modern stacks were those?

Most NodeJS with ReactJS frontends.

Some of them had already started doing React for frontend and just need the backend work.

Re: Sensible Software Engineering

#40

Post by WrtCdEvrydy »

james_s_tayler wrote: post #24
WrtCdEvrydy wrote: post #22

Earlier quoted context omitted.

Good for me, I must made about 500,000 from moving Rails to other more modern stacks... I'll learn Kubernetes just as it dies off and start moving people's shit to whatever's next.

That has to be one of the best strategies out there. So long as you just read the trends right.

Best of both worlds, I can paid to learn the new tech and the old tech...
Post reply on HN