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

11–20 of 77 posts

Re: Sensible Software Engineering

#11

Post by pytester »

leetrout wrote: post #9
eikenberry wrote: post #7

Earlier quoted context omitted.

I agree that Kubernetes is not the best technology out there, but I'm not 100% on which I would call the best. Did you have a winner in mind (it sounded like it)? If so why that one? Also it may not really matter as you said Kubernetes is the most popular and is only getting more so at this point and the network affect is so strong in tech like this that the "technically best" most likely will become a moot point.

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...

Re: Sensible Software Engineering

#13

Post by jasode »

herge wrote: post #10
jasode wrote: post #2

>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 I'm not advocating for TDD (the programmer methodology in the IDE) but the author's explanation about "test code" isn't correct. Code written for explicit purposes of a test to exercise other code has been shown to increase correc…

Maybe the spry takeaway is that you should write tests for things you want to make sure they will not break. Your UI being off by a pixel won't break your application, so if a test hangs on that, then it is not a good test. However, your business logic, or network protocol routine, those should not break even if you heavily refactor or add new features (especially business logic where a broken behaviour might seem co…

>Your UI being off by a pixel won't break your application, so if a test hangs on that, then it is not a good test.

For brevity in the previous comment, I didn't fully flesh out the background on why fragile UI tests get created. It happens accidentally.

What sometimes happens is the the UI tester uses a "macro recorder" to record mouse movements and clicks. But then, a programmer shifts the position of a zipcode field by one pixel which throws the script off because it expected UI elements in a different spot. Fixing the broken UI tests is time consuming and can leave a bad impression that tests create a lot of effort for very little payback.

The return-on-investment of UI tests depends on the business circumstances. I'm guessing Boeing and Airbus have automated UI tests that sometimes break when programmers change things which causes rework. However, the pain of fixing the UI tests and keeping it sync'd with the UI code is worth it for avionics software.

Re: Sensible Software Engineering

#14

Post by strken »

jasode wrote: post #13
herge wrote: post #10

Earlier quoted context omitted.

Maybe the spry takeaway is that you should write tests for things you want to make sure they will not break. Your UI being off by a pixel won't break your application, so if a test hangs on that, then it is not a good test. However, your business logic, or network protocol routine, those should not break even if you heavily refactor or add new features (especially business logic where a broken behaviour might seem co…

>Your UI being off by a pixel won't break your application, so if a test hangs on that, then it is not a good test. For brevity in the previous comment, I didn't fully flesh out the background on why fragile UI tests get created. It happens accidentally. What sometimes happens is the the UI tester uses a "macro recorder" to record mouse movements and clicks. But then, a programmer shifts the position of a zipcode fie…

Visual diffing in UI tests is something that actually can be solved with more code, see https://github.com/americanexpress/jest-image-snapshot, https://github.com/gemini-testing/gemini, or https://github.com/BBC-News/wraith.

Re: Sensible Software Engineering

#15

Post by greenyouse »

jasode wrote: post #2

>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 I'm not advocating for TDD (the programmer methodology in the IDE) but the author's explanation about "test code" isn't correct. Code written for explicit purposes of a test to exercise other code has been shown to increase correc…

You can tune the pixel difference in Selenium testing so it doesn't fail when under the acceptable pixel change limit. If it's off by one or two no biggie but off by 30 or 50 then maybe there was a structural change to the page, so it should fail. Something like "misMatchTolerance" from wdio-visual-regression-service[0] would allow for tweaking this. I'm sure there are similar tools for other languages.

If the UI tests catch bugs during development or help the team during a data migration, they're probably still worth having.

[0] https://github.com/zinserjan/wdio-visual-regression-service

Re: Sensible Software Engineering

#16

Post by gav »

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 what being agile really meant.

> Managers who don't themselves write any code, but micromanage their workers with their version of Scrum, are the worst.

I don't think anyone would disagree on the evils of micromanaging, but as a manager that doesn't code, I think that managers who do code are depriving their teams of the most valuable thing they have to offer--their support. If you take on a coding task and put yourself on the critical path of that sprint's work, you have to commit to putting the hours in to get it done. This is not a good use of your time.

This is the difference between a manager and a Tech Lead.

Re: Sensible Software Engineering

#17

Post by scandox »

> The bottleneck has always been in understanding all the implicit assumptions baked into the system that for one reason or another are essential to its correctness.

> It takes a particular kind of masochist to enjoy reverse engineering a black box from just poking at it with simple linear impulses.

These are great observations and brilliantly put. In particular the second one I think rightly explains why some very smart people definitely do not take to programming as a profession.

Re: Sensible Software Engineering

#18

Post by gav »

herge wrote: post #10
jasode wrote: post #2

>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 I'm not advocating for TDD (the programmer methodology in the IDE) but the author's explanation about "test code" isn't correct. Code written for explicit purposes of a test to exercise other code has been shown to increase correc…

Maybe the spry takeaway is that you should write tests for things you want to make sure they will not break. Your UI being off by a pixel won't break your application, so if a test hangs on that, then it is not a good test. However, your business logic, or network protocol routine, those should not break even if you heavily refactor or add new features (especially business logic where a broken behaviour might seem co…

> you should write tests for things you want to make sure they will not break

You should also write tests for things that are already broken before you work on the fix so that you can be sure it's actually fixed. Basically the red/green/refactor cycle[1] from TDD.

[1] http://www.brendanconnolly.net/test-driven-testing-red-green...

Re: Sensible Software Engineering

#19

Post by avip »

leetrout wrote: post #3

Really buried the lede here. I get that it was acknowledged as a rant / opinion piece but there's not a lot of really actionable advice for the general population of programmers, IMO. The article has good points, for sure, but the ending has the best part, IMO. > 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…

That's one high-quality rant. The likes of Pretending that the system and the runtime traces of the system are the specification is why there is always a shortage of programmers. That's really insightful. And I think the implied derived actionables are obvious.
Post reply on HN