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

How to build quickly

learnhowtolearn.org

Post reply on HN
Print view View original

51–60 of 147 posts

Re: How to build quickly

#51

Post by drekipus »

andrewstuart wrote: post #6

This message is suspiciously like being told to draw the outline of an owl then draw the rest of the fucking owl. https://seths.blog/2014/01/how-to-draw-an-owl/ The word recursively does a lot of work in the post. Every project I go into thinking I can do it quick and it never works that way because the minimal viable or minimum lovable thing is a long way from the minimum actual concept of what I have in mind. I fee…

I recently threw out the "do the MVP" mindset.

To me, MVP means "Do part A to a good enough level of perfection where customers will buy it, then release and get customers, support them while then working on part B as a value-add.." - often, in my mind, all parts, ABC add up to the whole package value. I don't want to break it apart.

I'm actually trying to do more planning and outlining first, and it has worked reasonably well for me.

Start with an outline of the different systems and how they connect, then outline one of those systems, the inputs and outputs to it. Then break down further into how does it get the input, where does it put the output, etc.

It has been remarkable in that I can actually feel joy for what I'm making again. I have also tried to start a blog with doing this type of "open design" - but blog writing requires its own planning and refining, which is an extra workload that I didn't intend to put on myself..

Re: How to build quickly

#52

Post by pan69 »

For my personal projects I use a very similar approach. However, I find this technique difficult to do with a group (more than 3 people).

Re: How to build quickly

#53

Post by tamimio »

I do that in a similar way. I start doing all parts at the same time, going back and forth until it’s done. It’s not a perfect approach though. Two downsides I sometimes encounter are: dependency, when most or some of the work or scope depends solely on perfecting another part, and if the work is complicated, you can get extremely overwhelmed to the point you don’t know where to start or even start at all.

Re: How to build quickly

#54

Post by _heimdall »

pan69 wrote: post #52

For my personal projects I use a very similar approach. However, I find this technique difficult to do with a group (more than 3 people).

Its trickier to scale for sure. I have actually seen something very similar work really well at an early startup. The team was around 5-6 people and fully remote at the time.

The real key is communication and trust. It only worked well for us because we communicated frequently, the CTO/lead was really good at acting as a conduit between everyone working on related projects, and we all really offered each other the trust to let each other run with it and adjust on the fly.

It was really common for us to go into a week with a clear idea of what the next feature to build was, only to end the week with the person working on it finding a different path or a reason not to build that at all, often with an alternative to propose. We'd discuss it as a team when needed, but it was always clear that the person who was working on it was the expert on it at the moment and had a lot of sway in direction for that feature.

It isn't easy, and it did actually fall apart when the team scaled to 10+ people, but there may have been ways we could have adjusted and avoided that too.

Re: How to build quickly

#56

Post by bordercases »

prmph wrote: post #32
layer8 wrote: post #30

In particular if you have to build on existing systems, a top-down approach doesn’t always work well, because the overall design may well depend on details of the existing parts you have to integrate with. In that case, starting with prototyping a vertical slice of the functionality can be the better approach.

Exactly. I've found that even with a greenfield project, there is the tension between keeping things simple and avoiding fully-engineering code so as to quickly get to an MVP, and the fact that code that is under-engineered is creating technical debt that becomes more ossified the more you build on top of it. My current thinking on a solution to this conundrum is this: try to craft the best architecture and engineeri…

Indeed, this seems to be the insight around vertical slice architecture? https://www.jimmybogard.com/vertical-slice-architecture/

Re: How to build quickly

#57

Post by phforms »

teo_zero wrote: post #25

This is a good way to maximize speed. I'm not convinced it's also a good way to master quality. Rushing ("speedrunning") to a first working version may force you to choose sub-optimal paradigms (algorithms, data types, etc.) that you won't have the time or the will to correct later. I'd even postulate that's why we have so many crap applications today that are first on the market but slow, inefficient and user unfrie…

I suspect that the “crap applications” issue arises not necessarily due to the method being wrong, but more likely due to people disregarding step 4 in the article: “Finally, once completely done, go back and perfect”.

It may be because of tight deadlines, lazyness (it’s “good enough” so why bother?) or eagerness to jump to the next project (because it is more exciting or profitable than doing the hard work of getting the details right).

I guess there is also a personality type factor that plays into it, because many people seem to just care about the hard requirements and cannot be bothered about things like performance, accessibility, design consistency, simplicity, maintainability, good documentation, etc., at least as long as nobody complains about it.

Re: How to build quickly

#59

Post by _heimdall »

gchamonlive wrote: post #47
kpw94 wrote: post #9

The author provides an example of the bad "Loading bar writing" but unfortunately not a good example of what they call "Outline speedrunning writing" pg, who's good at writing essays, does provide a good example of the latter, with https://byronm.com/13sentences.html . This is the writing process that lead to https://paulgraham.com/13sentences.html . (the https://code.stypi.com/hacks/13sentences?doomed=true URL on pg…

What I do for my blog is I write everything at once. Then I figure out where to put images, then I publish it! It makes me go back and read it carefully since I have already published it, and then I polish, rewrite sections and add stuff that I missed.

I have done something similar on the past and I was very happy with the results. At the time I was starting up a consulting business and got the first few gigs directly from engagement with my blog.

I also time boxed myself when writing. I wouldn't write unless I had a really clear topic in mind, then I'd give myself an hour to get it published. A few times I ran out of time and ended it with a "follow-up post coming soon to dive into ___" type message and that worked just fine.

Re: How to build quickly

#60

Post by throwaway4aday »

andrewstuart wrote: post #6

This message is suspiciously like being told to draw the outline of an owl then draw the rest of the fucking owl. https://seths.blog/2014/01/how-to-draw-an-owl/ The word recursively does a lot of work in the post. Every project I go into thinking I can do it quick and it never works that way because the minimal viable or minimum lovable thing is a long way from the minimum actual concept of what I have in mind. I fee…

Well, that's because it is how you draw an owl. You start with basic outlines to define size, pose and proportion, then you divide those outlined areas into smaller sections that locate important details like eyes, beak, ears, wings, etc. then you add rough detail to those parts which further breaks it down and you keep iterating like that until you fill in all of the fine details.

You can see the process here https://youtu.be/UGVOE2eHl0I

Post reply on HN