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

How SQLite is tested

sqlite.org

Post reply on HN
Print view View original

41–50 of 87 posts

Re: How SQLite is tested

#41

Post by stouset »

lateforwork wrote: post #38
stouset wrote: post #36

Earlier quoted context omitted.

The person who signals that some task works and is finished is you . You have way more control over this than you are giving yourself credit for. If you spend your career acquiescing to every request to “just ship it” then, yes, slowing down a second to do a quality pass will seem impossible. But you really can just do it.

> The person who signals that some task works and is finished is you. That's not how it works in most big companies. You can't take arbitrarily long to finish a project. Before the project is greenlit you have to give an estimate for how long the project will take. If your estimate is too big or seems unreasonable the project dies then and there (or given to someone else). Once the project starts you're held to the e…

Nobody is saying take three years to complete a week-long task. If you could do a task in one hour, estimate and take two. If you could do it in two days, estimate and take a third day to complete it. Or better yet, estimate three days and take two and a half.

I have never seen a software development shop where estimates were treated as anything other than loose, best guesses. Very infrequently are there actually ever genuinely immutable, hard deadlines. If you are working somewhere where that's repeatedly the case—and those deadlines are regularly unrealistically tight—failure is virtually inevitable no matter what you do. So sure, fine, if you're on a death march my suggestions won't work. But in that kind of environment nothing will.

Re: How SQLite is tested

#42

Post by dang »

Related. Others?

How SQLite Is Tested - https://news.ycombinator.com/item?id=38963383 - Jan 2024 (1 comment)

How SQLite Is Tested - https://news.ycombinator.com/item?id=29460240 - Dec 2021 (47 comments)

How SQLite Is Tested - https://news.ycombinator.com/item?id=11936435 - June 2016 (57 comments)

How SQLite Is Tested - https://news.ycombinator.com/item?id=9095836 - Feb 2015 (17 comments)

How SQLite is tested - https://news.ycombinator.com/item?id=6815321 - Nov 2013 (37 comments)

How SQLite is tested - https://news.ycombinator.com/item?id=4799878 - Nov 2012 (6 comments)

How SQLite is tested - https://news.ycombinator.com/item?id=4616548 - Oct 2012 (40 comments)

How SQLite Is Tested - https://news.ycombinator.com/item?id=633151 - May 2009 (28 comments)

(Reposts are fine after a year or so; links to past threads are just to satisfy extra-curious readers)

Re: How SQLite is tested

#43

Post by dvratil »

antonymoose wrote: post #34
tzone wrote: post #31

I am surprised to see that there isn't a lot of information about performance regression testing. Correctness testing is important but the way SQLLite is used, potential performance drops in specific code paths or specific type of queries could be really bad for apps that use it in critical paths.

While I’ve worked in HFT and understand the sentiment, I can’t recall any open-source project I’ve used coming out with performance guarantees. Most use license language setting no guarantee or warranty. Are there notable projects that do include this consideration as their core mission?

I believe every sensible open-source developer strives to keep their software performant. To me, a performance regression is a bug like any other and I got and fix it. Sure, there's no warranty guaranteed in the license, yet no-one who takes their project even a little seriously takes it as "I can break this any way I want".

Re: How SQLite is tested

#44

Post by tracker1 »

epolanski wrote: post #21
bastardoperator wrote: post #8

Over a decade ago, the maintainer of SQLite gave a talk at OSCON about their testing practices. One concept that stood out to me was the power of checklists, the same tool pilots rely on before every flight. He also mentioned Doctors Without Borders, who weren't seeing the outcomes they expected when it came to saving lives. One surprising reason? The medical teams often didn't speak the same language or even know ea…

I've always found an enormous amount of good practices (not just engineering ones) in aircraft operations and engineering that would be applicable to software engineering. I've always day dreamed of an IT organization that combined those with the decision-making procedures and leadership of modern armies, such as the US Army one. I've re-read multiple times FM22-100 which I find strikingly modern and inspiring: https…

In some areas, I absolutely agree... I think when it comes to vehicles, medical devices and heavy equipment, it would be better to see much more rigorous practices in terms of software craftsmanship. I think it should be very similar in financial operations (it isn't) and most govt work in general (it isn't).

In the end, for most scenarios, break fast, fix fast is likely a more practical and cost effective approach.

Re: How SQLite is tested

#45

Post by stouset »

steve_adams_86 wrote: post #40
stouset wrote: post #13

Earlier quoted context omitted.

You can literally just do this. I’ve never gotten fired from a software engineering job for moving slower and building things that work well, work predictably, and are built to last. Over a career of working at it, you get dramatically better at higher levels of quality even in earlier passes, so the same level of added effort provides increasing levels of reward as you gain experience. Nobody ever complains about th…

> Nobody ever complains about the person who’s leaving everything they touch a little cleaner than how they found it. This should be true, but it's not in my experience. Even small, clear improvements are rejected as off-mission or shunted to a backlog to be forgotten. Like, "cool, but let's hold off on merging this until we can be certain it's safe", or in other words "this is more work for me and I'd really rather…

Do it as part of ticket work you're already doing. There is always a way to leave things better than how you found them.

I have worked across a wide gamut of roles (full-stack eng, infosec, deploy infra, devops, infra eng, sysadmin), companies (big and small, startups and huge multibillion-dollar players), and industries (finance, datacenters, security products, gaming, logistics, manufacturing, AI) over a thirty year career and I have never felt the level of helplessness that people seem to be claiming. Some places have been easier, some have been harder, but I have never once found it to be as difficult or impossible as everyone laments is the case.

Re: How SQLite is tested

#47

Post by gatlin »

stouset wrote: post #45
steve_adams_86 wrote: post #40

Earlier quoted context omitted.

> Nobody ever complains about the person who’s leaving everything they touch a little cleaner than how they found it. This should be true, but it's not in my experience. Even small, clear improvements are rejected as off-mission or shunted to a backlog to be forgotten. Like, "cool, but let's hold off on merging this until we can be certain it's safe", or in other words "this is more work for me and I'd really rather…

Do it as part of ticket work you're already doing. There is always a way to leave things better than how you found them. I have worked across a wide gamut of roles (full-stack eng, infosec, deploy infra, devops, infra eng, sysadmin), companies (big and small, startups and huge multibillion-dollar players), and industries (finance, datacenters, security products, gaming, logistics, manufacturing, AI) over a thirty yea…

That's really great and I'm happy for you but your experience is not universal.

Re: How SQLite is tested

#49

Post by stouset »

gatlin wrote: post #47
stouset wrote: post #45

Earlier quoted context omitted.

Do it as part of ticket work you're already doing. There is always a way to leave things better than how you found them. I have worked across a wide gamut of roles (full-stack eng, infosec, deploy infra, devops, infra eng, sysadmin), companies (big and small, startups and huge multibillion-dollar players), and industries (finance, datacenters, security products, gaming, logistics, manufacturing, AI) over a thirty yea…

That's really great and I'm happy for you but your experience is not universal.

My point isn’t that my experience is universal, but that I find it statistically unlikely that this is nearly as hard as people are making it out to be at the majority of SWE roles.

If you find yourself repeatedly working at places where the only option is to crank out garbage at breakneck pace, I don’t know what to tell you. If you stipulate as an axiom that it's impossible to write quality software at ${JOB}, then you're right, by definition there's nothing to be done. I just don't find that a particularly helpful mindset.

Re: How SQLite is tested

#50

Post by AlotOfReading »

taberiand wrote: post #33
Ferret7446 wrote: post #25

Earlier quoted context omitted.

You can definitely go overboard for work. If you want to do it as a hobby, go nuts, but there isn't a point in overengineering far beyond what is needed (recall the Juicero)

Overengineering is building a bridge that will stand 1000 years when 100 will do; it's excess rigor for marginal benefit. Juicero wasn't overengineering, it was building a crappy bridge to nowhere with a bunch of gaudy bells and whistles to try and hide its uselessness and poor design, that collapsed with the first people to walk over it

Have you looked at a Juicero teardown [0]? It's overengineered to the point where it's a genuinely astonishing bit of engineering art. It's also an incredibly stupid product. Those things are completely compatible.

[0] https://blog.bolt.io/juicero/

Post reply on HN