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.
How I build software quickly
51–60 of 215 posts
Re: How I build software quickly
#52"Learn to walk before you run. I firmly believe in this wisdom. First build a foundational model, then tackle boundary challenges and efficiency optimization."
Re: How I build software quickly
#53In 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 Celery. What's your approach?
Re: How I build software quickly
#54I actually try to build it "well" in the first pass, even for prototyping. I'm not gonna say I succeed but at least I try. This doesn't mean writing tests for everything, and sometimes it means not writing tests at all, but it means that I do my best to make code "testable". It shouldn't take more time to do this, though: if you're making more classes to make it testable, you're already messing it up. This also doesn…
I personally find that doing it well in the first pass slows me down and also ends up in worse overall designs. But I am also pretty disciplined on the 2nd pass in correcting all of the hacks and rewriting everything that should be rewritten. There are two problems I have with trying to do it right the first time: - It's hard to know the intricacies of the requirements upfront without actually implementing the thing,…
I have found that too much coupling between product requirements and the architecture can be detrimental. It's often the reason why people tend do too much upfront work, but also slows down the evolution of the feature.
So I don't really want to know the future requirements, or refactor on the 2nd pass to "match".
If some feature needs too many modifications or special cases in the current architecture, it's a round peg in a round hole. I prefer to have those places be a bit more "painful" in the code. The code doesn't have to be bad per se, but it should be clear that something different and not traditional is happening there.
Re: How I build software quickly
#55This 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)
Re: How I build software quickly
#56I 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 production server so its just the dns missing from beeing in production help so much for testing and highlights bug and other problems between teams. So the author mostly talks about this from a code perspective, but IMHO its even more important on larger teams.
(Sidenote: having this kind of architecture where you create layer of deps from one team to another is a bad idea from my point of view, but is still done a lot)
Re: How I build software quickly
#57I 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...
Re: How I build software quickly
#58What the article calls "rough draft" I like to call "executable architecture", a nice term from the "rational unified process".
Re: How I build software quickly
#59>(I recently had a branch where an error message was logged 20 times per second.)
Lightwork
Re: How I build software quickly
#60In 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 also like Django a lot. I can get a working project up and running trivially fast. In my day job I work with Go and while it's fine, I end up writing 10x more code for simple API endpoints and as soon as you add query parameters for filtering, pagination, etc. etc. it gets even longer. Adding a permissions model on top does similar. Of course there's a big performance difference but largely the DB queries dominate…
Whats so hard about writing an SQL query and some json struct tags? I really dont like LLMs but all the pain points of Go you described above are relatively mute now if you use them for these little things