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

71–80 of 215 posts

Re: How I build software quickly

#71

Post by shireboy »

zwnow wrote: post #55
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.

Why not build a simple functional UI, its not a huge time sink between non functional and functional (as long as kept simple)

Well, sometimes I will, but for example take a simple list+form ontop of a database. Instead of building the UI and the database and then showing the stakeholder, who adds/renames fields, changes relationships etc. I will intentionally build just the UI not wired up to database. Sometimes just to an in-memory store or nothing. Then, _after_ the stakeholder is somewhat happy with the UI, I "bake" things like a service or data layer, etc. This way the changes the stakeholder inevitably has up front have less of an impact.

Re: How I build software quickly

#72

Post by gl-prod »

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…

In Django, how do you create components well and handle user interactions?

Re: How I build software quickly

#73

Post by kaptainscarlet »

gl-prod wrote: post #72
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…

In Django, how do you create components well and handle user interactions?

I think that's where htmx comes in

Re: How I build software quickly

#74

Post by pydry »

hobofan wrote: post #44

> For example, if you’re making a game for a 24-hour game jam, you probably don’t want to prioritize clean code. That would be a waste of time! Who really cares if your code is elegant and bug-free? Hate to be an anecdote Andy here, but as someone who has done a lot of code review at (non-game) hackathons in the past (primarily to prevent cheating), the teams that performed the best were also usually the ones with th…

I think some people look at code cleanliness in aggregate (this code base is dirty vs. it is elegant and bug free) and others have a fine grained cost/benefit analyses of nonfunctional code improvements.

Im pretty sure the latter vastly outpeform the former under all circumstances - whether quick and dirty hackathon or ultra hardened production code.

Re: How I build software quickly

#75

Post by MeetingsBrowser »

> What is my team’s idea of “good enough”? What bugs are acceptable, if any? Where can I do a less-than-perfect job if it means getting things done sooner?

I hop between projects regularly, and this has been the biggest source of inter-team conflict in my career.

Different people from different backgrounds have an assumed level of what "good enough". The person from big tech is frustrated because no one else is testing thoroughly. The person from a startup is frustrated because everyone else is moving too slow.

It would be nice if the "good enough" could be made explicit so teams are on the same page.

Re: How I build software quickly

#76

Post by anonzzzies »

croes wrote: post #43
anonzzzies wrote: post #2

We encounter many rough drafts (yours) in production systems. If the original devs are still there, it is usually something along the lines of: I showed the rough draft to my manager, they flagged is as done and I was assigned to another task.

This will get worse with AI

We already see it; the combination of job-hopping & AI are a perfect storm really.

From launch to failure is definitely getting fast-tracked; few months ago we had yet another hospital system that just lost data; reading the code (no tests, no peer reviews; they don't use versioning) shows clear signs of LLMs; many files that do almost the same thing, many similar function names that do almost the same thing or actually the same thing, strange solutions to trivial problems, etc. The problem was that there was a script ran at startup which added an admin user, but if an admin user already exists, it truncates the table. No idea why, but it wasn't discovered earlier because after testing by the devs it was put live, devs left (contractors) and it just ran without issues until the ec2 instance needed maintenance by aws and was as such rebooted after which all users were gone. Good stuff. They paid around 150k for it; that is not a lot in our field but then to get this level of garbage is rather frightening. This was not life threatening, but I know if it was, it would not be better as you cannot make this crap up.

Re: How I build software quickly

#77

Post by roane »

croes wrote: post #43
anonzzzies wrote: post #2

We encounter many rough drafts (yours) in production systems. If the original devs are still there, it is usually something along the lines of: I showed the rough draft to my manager, they flagged is as done and I was assigned to another task.

This will get worse with AI

I wonder if the rough draft approach is a good prompt for an agent. Since it can draft more quickly, you can review more quickly & get it on the right track.

Re: How I build software quickly

#78

Post by leetrout »

MeetingsBrowser wrote: post #75

> What is my team’s idea of “good enough”? What bugs are acceptable, if any? Where can I do a less-than-perfect job if it means getting things done sooner? I hop between projects regularly, and this has been the biggest source of inter-team conflict in my career. Different people from different backgrounds have an assumed level of what "good enough". The person from big tech is frustrated because no one else is testi…

This is a team charter. A “how we work” document.

https://asana.com/resources/team-charter-template

Re: How I build software quickly

#79

Post by marginalia_nu »

sisve wrote: post #56
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…

Hmm, context matter a lot. Im not sure on what you consider large development projects, so maybe its even bigger then what I'm thinking on. But getting the apis between apps up and ready early and getting a working setup from the database team to the frontend teams and apps teams trough some kind of backend/api team has always proven to be the correct choice for me. Also getting it as fast as possible on to a product…

It's a scale. On the one extreme you have solo development, on the other you have the gargantuan code bases at e.g. Google, or the Linux kernel.

What you're describing is somewhere in the middle (if you imagine a logarithmic scale), it's at a point where working like a solo dev begins to break down especially over time, but not at a point where it's immediately catastrophic.

Startups sometimes work in that sort of hybrid mode where they have relatively low quality code bordering on unmaintainability, where they put off fixing its problems into the future when they've made it big.

Re: How I build software quickly

#80

Post by smashed »

fhd2 wrote: post #53
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…

Agree with almost everything, but Celery is pretty common in my Django projects. I don't like the complexity cost, but especially when using some PaaS for hosting, it's usually the least painful option. I kinda always start out thinking this time I'll manage without, and then I have a bunch of jobs triggered via HTTP calls running into timeouts. At that point it's either threads, cron jobs (tricky with PaaS) or Celer…

This.

I use celery with the same code base/docker image. Just a different entry point to start a celery worker instead of a wsgi (web) worker.

Too many http requests? Add web worker instances.

Background jobs piling up? Add celery workers.

Clearly separate read endpoints from write/transactional endpoints and you can hit a slave postgres db or the master db depending on the http call.

This creates a very robust system that can scale easily from a single code base.

Post reply on HN