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

How I build software quickly

evanhahn.com

Post reply on HN
Print view View original

191–200 of 215 posts

Re: How I build software quickly

#191

Post by tonyedgecombe »

zwnow wrote: post #57
marginalia_nu wrote: post #20

I think scale matters quite a lot here. If you're building something yourself or in a small team, I absolutely agree with everything written in the post. In fact, I'd emphasize you should lean into this sort of quick and dirty development methodology in such a context, because this is the strength of small scale development. Done correctly it will have you running circles around larger operations. Bugs are almost alw…

This is the point at which u scale down. Nobody needs these huge systems but everyone for some reason wants them...

In general it doesn't happen unless the business itself is swept away by leaner competitors.

Whenever I asked customers what they wanted from their new systems they always started by saying we want to match the existing system.

Re: How I build software quickly

#192

Post by hu3 »

deterministic wrote: post #178

I write (mostly) bug free production code fast by doing the following: 1. I use a custom code generator to generate 90%+ of the code I need from a declarative spec. 2. The remaining hand written code is mostly biz logic and it is exhaustively auto tested at the server API level. 3. I maintain and "bring along" a large library of software tools "tested in combat" I can reuse on new projects. 4. I have settled on an ar…

I too like code generators. Keeps code standard and reduces human error.

What programming language you like for that?

Re: How I build software quickly

#193

Post by creshal »

pdhborges wrote: post #62
creshal wrote: post #46

Earlier quoted context omitted.

> Always choose extremely boring technology. Just use python/Django/Postgres for everything. Hell, think twice before you consider postgres. Sqlite scales further than most people would expect it to, especially for local development / spinning up isolated CI instances. And for small apps it tends to be good enough for production too.

What do you save by going with sqlite vs how much pain are you going to endure in the future?

I save having to deal with a full-blown DBMS daemon accessed through a network boundary unless I need this, and I have approximately zero pain, because I read the documentation and set up my database schemas to work on both solutions (and use WALs so sqlite is rock stable). I also know how to open a file on the command line if I need raw database access for some reason (very rare with django anyway, django's console is just too good not to use it). I also design my apps to not deadlock on unnecessarily long transaction and don't turn every request into a database write, so I can scale out pretty far before I have to worry about write performance. And if I do, I can still use postgres. Until then, I can do unified, consistent backups of all state by snapshotting the filesystem containing uploads and sqlite files.

So I dunno why people insist on spreading so much FUD.

Re: How I build software quickly

#194

Post by whizzter »

shireboy wrote: post #51

This pretty much exactly describes my strategy to ship better code faster. Especially the “top down” approach: I’m actually kind of surprised there isn’t like a “UI first” or “UI Driven Development” manifesto like w TDD or BDD. Putting a non functional UI in front of stakeholders quickly often results in better requirements gathering and early refinement that would be more costly later in the cycle.

I think at that point it's almost better to come with paper printouts for 2 reasons.

1: Tacticale/shareable/paintable in a physical meeting

2: It drives home that it's a sketch, with bad customers a visible UI so easily hides the enormous amounts of complexity that can sometimes be under a "simple" UI and make it hard to educate them as to why the UI sketch one did in an hour or two then needs 1500 hours of engineering to become a functioning system.

Re: How I build software quickly

#195

Post by whizzter »

kukkeliskuu wrote: post #22

In recent years, I have learned how to build sufficiently robust systems fast. Here are some things I have learned: * Learn one tool well. It is often better to use a tool that you know really well than something that on the surface seems to be more appropriate for the problem. For extremely large number of real-life problems, Django hits the sweet spot. Several times I have started a project thinking that maybe Djan…

I think HTMX as "simple" solutions comes into the same class as you mention "django being too heavy".

Sure, Django,Rails,Asp MVC,etc with static pages could be fully functional for something that is 99% CRUD.

But I myself foolishly tried using static view+HTMX for something that should have been built with something more dynamic like Vue/React(perhaps Alpine?) from the start due to actual client-side complexity.

In general imho one should classify what your main interaction points are and use the correct tools for each.

- Is it static pages for masses of consumers with little to no interaction? (Ie a news-site,etc) then fast SEO-friendly pages is your nr 1 priority.

- Is it mainly massive CRUD updates that needs persistence, go with server built pages with Django, Rails, etc.

- Is it an actual client/data heavy UI (games but also scenarios where you want fast client data slicing or processes/sources that complete at different paces), use an SPA.

Ie, right tool for the right job.

Re: How I build software quickly

#196

Post by aatd86 »

vbezhenar wrote: post #184
aatd86 wrote: post #146

Earlier quoted context omitted.

I don't think that everyone is capable of or should be implementing csrf protection or cors handling. While the standard library is an awesome starting point, telling people that it is sufficient is not going to convince them.

I wrote CORS handling in one project, it's like 10-20 lines of code. Very simple and well documented feature.

Good for you but most people don't even know what a preflight request is so I would maintain my position that it is not obvious.

Re: How I build software quickly

#197

Post by benterix »

kukkeliskuu wrote: post #181
benterix wrote: post #47

Earlier quoted context omitted.

> Forget Kubernetes, Redis While I agree with you, these two are the boring tech of 2025 for me. They work extremely reliably, they have well-defined use cases where they work perfectly and we know very well where they shouldn't be used, we know their gotchas, the interest around them seems to slowly wane. Personally, I'm a huge fan of these, just because they're very stable and they do what they are supposed to do.

I am not going to argue with you about specific technology or use cases. But these are complex pieces of software, and the fact that you consider them to be "boring technology" is the reason why I was talking about "extremely boring technology". When you are building software really fast, you need to take the boringness to the next level and cut all non-essential components. At fly.io, hosted Redis costs over $100/mo…

There are a couple of points I'd disagree here.

1. I don't believe tenfold difference in pricing PostgreSQL vs Redis at fly.io is due to complexity, Postgres is much more complex. If I had to guess at why they priced it that way, I'd say it's because they choose more RAM-beefy machines to host their Redis instances. Other providers may have the pricing completely different.

2. It's been a decade that Lucene-based search engines are no longer the default choice. If for some reason PostresQL's FTS is not the right choice, there are many excellent alternatives like Meilisearch or Typesense.

Re: How I build software quickly

#198

Post by benterix »

frollogaston wrote: post #159
packetlost wrote: post #151

Earlier quoted context omitted.

K8s is chock full of complexity though. Complexity that the vast majority of applications do not, and will not need

I only used it once forever ago, and all I remember is being very confused about pod vs service and using a lot of magic strings to get load-balancing to work. Sure I could figure it out, but didn't want to.

You can treat Pod as a container (or set of containers in some cases) and Service as its IP address (whether visible from inside the cluster, outside etc. - that's why you have different service types). Starting with simple analogies is very helpful in understanding complex structures in general.

Re: How I build software quickly

#199

Post by benterix »

packetlost wrote: post #165
acedTrex wrote: post #163

Earlier quoted context omitted.

I mean a basic k3s install + a barebones deployment combined with a nodeport service is about as trivial as you can get. its not THAT much more "lines of config (60-70 max)" then an nginx conf + "git clone + other stuff" deploy script.

I dunno, a sane nginx config is like 30 lines max for a basic service. You can mange it entirely with git (`git config receive.denyCurrentBranch updateInstead`) and some post-receive / push-to-checkout hooks. Keep in mind, for K8s to work you also need to containerize your application, even if it's just static files (or I guess you can break containment and do volume mounts, or some sort of static file resource if yo…

Yeah but what's the point of running k8s if your app isn't even containerized, why not use a simple VM for that, it's cheap and easy to manage.

On the other hand if you are running thousands of containers it's hard to beat k8s, simpler solutions like ECS fall short at some point.

Re: How I build software quickly

#200

Post by kukkeliskuu »

benterix wrote: post #197
kukkeliskuu wrote: post #181

Earlier quoted context omitted.

I am not going to argue with you about specific technology or use cases. But these are complex pieces of software, and the fact that you consider them to be "boring technology" is the reason why I was talking about "extremely boring technology". When you are building software really fast, you need to take the boringness to the next level and cut all non-essential components. At fly.io, hosted Redis costs over $100/mo…

There are a couple of points I'd disagree here. 1. I don't believe tenfold difference in pricing PostgreSQL vs Redis at fly.io is due to complexity, Postgres is much more complex. If I had to guess at why they priced it that way, I'd say it's because they choose more RAM-beefy machines to host their Redis instances. Other providers may have the pricing completely different. 2. It's been a decade that Lucene-based sea…

1. fly.io sells redis hosted by upstash. But you are correct in the sense that default fly.io PostgreSQL was unmanaged and probably subsidized, and recent PostgreSQL is probably more expensive. But while I think you cannot directly say that tenfold increase in price means tenfold increase in complexity, I am just saying that it is complex.

2. It is surprisingly common to see people preferring Lucene-based search engines over Postgres. I don't know about your alternatives and not saying anything about them.

Post reply on HN