TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Engineering "home-cooked" software

54 点作者 kookiburra5 个月前

11 条评论

ebiester5 个月前
This feels like someone who hasn&#x27;t been in the industry long enough to know what it is like to try and design software before implementing it with groups larger than 3, and yearns for problems that aren&#x27;t as complex as the ones they are dealing with.<p>It is easy to build &quot;home cooked&quot; (by his definition) software when you are building for a small number of people by a small number of people. Old Visual Basic programs built for a single version of Linux will do just fine - and that will work well for some use cases. But if you are building software that has to work on thousands to millions of machines, and fulfill their needs, you will need to build a factory to build that software.<p>The factory, in this case, is the infrastructure necessary to turn the R&amp;D (you and me) into the repeatable product (that is, your app.) The factories need a lot of maintenance. If nobody is buying your product, you need to change the factory to produce outputs that people are buying. If people have bought your product (let&#x27;s say... on subscription) then you need to keep the factory maintained well enough to produce the product that people are happy to buy.<p>Some things will be like tarsnap and change relatively little. That&#x27;s great. A small shop will need less maintenance. A bigger shop that is a factory for more users with wider needs will need more complicated products and that will mean more maintenance.<p>But yes, if you don&#x27;t need to have a return on investment, you don&#x27;t need to react to customers&#x27; needs and therefore you can build a spec first and let it change little. (Or, you build something as niche and as good as Tarsnap!)
评论 #42750070 未加载
smileysteve5 个月前
I couldn&#x27;t disagree with the premise of the sections more on development methodology<p>&gt; Fast Food &gt; Here, we develop in &quot;agile&quot; sprints. Working software is developed at the fastest pace possible, and all bugs are to be fixed later.<p>&gt; Home Cooked &gt; Here, things are slower, more thoughtful. More waterfall-y.<p>While Sprints is a term that sounds like fastest pace possible, that is not what the term means; and a key part about waterfall vs agile is that waterfall IS NOT more thoughtful, but all planned up front.<p>Both methodologies can create bugs, or deliver features faster than scale can be thought of and deliver features faster than can be tested.<p>If we remove the quotes from &quot;agile&quot; we actually get slower and thoughtful. A key part of that is measuring (training, interviewing, analyzing). An agile process <i>should</i> build a feature, release that feature, interview users, analyze system behavior, iterate by improving user&#x27;s goal, adding appropriate scale, iterating by removing unexpected errors or behavior.
评论 #42742275 未加载
评论 #42750117 未加载
mschild5 个月前
In the same vein, I recommend reading this post by Robin Sloan <a href="https:&#x2F;&#x2F;www.robinsloan.com&#x2F;notes&#x2F;home-cooked-app&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.robinsloan.com&#x2F;notes&#x2F;home-cooked-app&#x2F;</a>
airbreather5 个月前
80% done, with no code.<p>This is often how a functional safety project works - specification is everything, no point writing any code until you know exactly what you plan to build.<p>Due to traceability requirements it becomes a very waterfall approach.<p>However one way of improving methodology and outcomes is an executable specification that can be converted to code and documenting at the very last minute, meaning you can be specifying right up until you need to deploy.<p>Executable specification concept comes from IEC 61499.
jppope5 个月前
False dichotomy, and not a great analogy. I see what the author is going for but they could have used to stress test their ideas before clicking &quot;publish.&quot;<p>Just for fun let me pose: Where would a Michelin star chef perform better? Whats the equivalent of fast casual or fine dining? Does the type of cuisine influence the outcomes???
评论 #42742230 未加载
评论 #42741485 未加载
bokohut5 个月前
I have been home cooking for a long while now and a portion of that past cooking has turned into acquired businesses that still operate to this day on the system platforms I architected and wrote. Cooking is a skill that takes great time, effort, and commitment yet since nearly all have no time to stop and appreciate a good meal here we have a compounding societal health issue just as with &quot;fast-food&quot; software we have a rapidly compounding cyber security issue. Everything has a pattern and a cycle so once you spot that pattern be sure to cook something up to ride that next crest.<p>I love to cook and have fed many yet I also have come to accept that most people never meet the chef who made their meal.<p>Stay Healthy!
评论 #42740527 未加载
drweevil5 个月前
My idea of home cooked software is certainly not &quot;waterfall-y&quot; at all. Rather, it is building from the ground up, aiming at a fairly well defined end goal. Of course, there is no one-size-fits-all solution here. Not everyone is working on web apps, CRUD, or using node. I spent my career writing embedded systems and instrument control software, mainly in C&#x2F;C++. I had colleagues who specialized on data reduction pipelines, using C and Fortran. Others who did the web&#x2F;database thing. Software development is a vast and varied field. What works in one arena may well be unsuitable in another. Be prepared to be flexible and open to new ideas.
jslakro5 个月前
Reminds me of an article from last year <a href="https:&#x2F;&#x2F;maggieappleton.com&#x2F;home-cooked-software" rel="nofollow">https:&#x2F;&#x2F;maggieappleton.com&#x2F;home-cooked-software</a>
meltyness5 个月前
It&#x27;s not like the market isn&#x27;t aware of this. This kind of motivates middleware more generally, so that the design and functionality of custom services can be paid due care.
hit8run5 个月前
I can relate. But home-cooking is also often reinventing the wheel. Core logic should be home-cooked but general aspects are probably best solved using battle proven 3rd party dependencies? What you guys think?
评论 #42739928 未加载
评论 #42740009 未加载
评论 #42740023 未加载
评论 #42740068 未加载
nayuki5 个月前
I would say that this blog post is half right. The half that&#x27;s not right is glaring.<p>&gt; the pyramids have had 100% up-time with no human maintenance<p>It helps that there is hardly any rain in the desert. Water would foul up the structure in a matter of years.<p>&gt; dependencies are added like seasoning. Hundreds of packages. Thousands of foreign lines of code make their way onto your software routinely<p>True, and I think NPM JavaScript exhibits the worst of this behavior.<p>&gt; Problems are expected and fixed on the fly, somewhat haphazardly: ... push a patch ... code scanning ... dependa-bot ... DevOps<p>True, and I remember when software releases were treated with much more care and quality because it costs a lot to ship a CD or game cartridge rather than a download.<p>&gt; More waterfall-y.<p>That&#x27;s not a good thing. Having a short feedback cycle from implementation back to design is a big win for software development. Waterfall is the dark ages when we didn&#x27;t know better.<p>&gt; This is where minimalist software is built.<p>Agreed.<p>&gt; No build process<p>That doesn&#x27;t make any sense, unless you&#x27;re writing machine code directly in hexadecimal.<p>&gt; no outside dependencies<p>I agree with minimizing dependencies, but there&#x27;s no such thing as <i>no</i> dependencies. I dare you to avoid any of these libraries: HTTP (especially HTTP&#x2F;2 and 3 which are much harder than HTTP&#x2F;1), TLS&#x2F;SSL, TCP&#x2F;IP, hardware drivers, compilers, data codecs like DEFLATE, multimedia codecs like AVC and AAC.<p>&gt; There&#x27;s no need to be constantly refactoring things, since everything was designed up to spec beforehand. ... The catch? Writing such a spec costs you over 80% of your engineering time, and you&#x27;ll have nothing to show for it until day 100.<p>This is a fallacy. I agree with and like this talk where the speaker Glenn Vanderburg argues that the software is the specification, the construction is done by compilers, and that most analogies to physical engineering are completely wrong. <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=NP9AIUT9nos" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=NP9AIUT9nos</a><p>&gt; The thing is, most humans are laughably bad at architecting software without actually writing it first.<p>There&#x27;s no shame in discovering the software architecture as you go along. If you already knew the architecture beforehand, that means you&#x27;re very familiar with the problem space already, and you probably should&#x27;ve written a framework to avoid repetitive work. In a sense, software development biases toward novel exploratory work rather than routine work, and that&#x27;s why it&#x27;s challenging.<p>&gt; this all stems from a certain greed software developers have ... Meanwhile other engineering fields are far more humble.<p>Nonsense; greed is human. In all fields of engineering, the general principle is to do more with less. As the saying goes, any fool can build a bridge, but only an engineer can build a bridge that barely stands. All engineers want more features for less cost, and software is no different. The difference is that in most engineering, there are more physical constraints, more templates to apply, more repetitive work. And because of that, the norms are well-established in traditional engineering. You don&#x27;t look at a big McMansion and call it &quot;greedy&quot; because it&#x27;s just the norm. You don&#x27;t look at a sprawling highway interchange with 4 levels of ramps and call it &quot;greedy&quot; because it&#x27;s socially acceptable.<p>&gt; Even your measly human body doesn&#x27;t need weekly patches<p>Have you looked at the list of bugs for humans? Allergies, back pain, appendix, aging, various birth defects, cancer, etc. If anything, life is the ultimate example of spaghetti coding and monkey-patching. Look at how vertebrate embryos (human, chicken, fish) all look the same in the first few weeks of life, then they diverge as various body parts and limbs are grown or shrunken.<p>&gt; Sadly, a good home-cooked meal is hard to find nowadays. Fast food is just too good to beat.<p>It&#x27;s weird when people praise home-cooked meals, because I&#x27;ve found restaurants that have great food. Heck, I&#x27;ve been to various traditional sit-down restaurants where they bring you the food in one minute and is faster than standing in line at McDonald&#x27;s.<p>&gt; Most software today just feels bloated and trashy, even if the experience is drug-like.<p>Most software do feel bloated and trashy to me too. I especially find that the more popular a software is, the trashier it is. A few decades ago for example, I found MSN Messenger to be popular but insufferable (big program size, laggy UI, lots of attention-grabbing features) whereas IRC was an underground community and the software was very well-behaved (small, not attention-grabbing).<p>Overall, I agree with the ideas that simpler software is better, there&#x27;s too much cargo-culting in industry, piling on complexity and dependencies is bad. But your article wanders all over the place and doesn&#x27;t hit the right points.
评论 #42744844 未加载