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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Moving Past the Scaling Myth

100 点作者 tmorton大约 9 年前

7 条评论

ktRolster大约 9 年前
Fred Brooks pointed out that with a small team of competent programmers, any organizational methodology will work.<p>If you pay attention, the best Agile systems focus on improving the skills of developers instead of forcing people to follow the &#x27;steps&#x27; or a formula.
评论 #11606403 未加载
exabrial大约 9 年前
I really wish the scaling myth would die. Everyone pretends they have a scalability problem because it&#x27;s sexy and as such, travesties have been committed (you know, in case we scale). How about instead designing software where the architecture and code is clear, consistent, and readable by the next guy?
评论 #11605395 未加载
wpietri大约 9 年前
This makes a lot of sense to me. At the very least, I think that most American organizations undergo a substantial cultural transition as they scale, so it makes sense we&#x27;d also need a process transition.<p>The problem I see is that people aren&#x27;t really willing to be honest about the cultural transition that happens, so we also can&#x27;t be honest about the process transition.<p>I think Agile-ish approaches work very well in startups, because the structure is pretty flat, and the goals are shared. But as companies grow, they tend to become what I think of business feudalism: hierarchical, control-oriented, territorial. For that, it makes sense you need different processes. And I think large company Agile is in effect Waterfall with a faster cadence, so you get that different process. But nobody will admit it. &quot;We&#x27;re doing Agile,&quot; they say, with too-bright eyes and gritted teeth.<p>What I wonder is: what if instead of killing the peer culture and the human-centered process as we scaled, we kept them?
评论 #11605306 未加载
评论 #11607022 未加载
nickpsecurity大约 9 年前
Hmmm. Maybe. What I&#x27;ve found is that IT often re-invents past designs and methods to solve modern problems. Matter of fact, the way the cloud providers scaled was to re-implement mainframes on x86 boxes. The next level is applying lessons from older research in modern ways to improve efficiency of various parts of HW and SW. If anything, quite a few people came up with timeless lessons that teach you how to do efficient, reliable computation. They keep getting reused.<p>So, I don&#x27;t think we can take it as far as author is suggesting where it&#x27;s like classical vs quantum physics. Maybe at ASIC vs software level. Even those were partly joined with synthesis &amp; coprocessing tools. I just don&#x27;t see it as every high-level description I read about things is based on similar principles at each layer of the stack. Given similar constraints or goals, you would use similar strategy. There&#x27;s certainly divergence or outliers but more repetition of patterns than anything.<p>The only myths are that technology&#x2F;fads X, Y, and Z should&#x27;ve been widespread adopted over the ones (or enhancements of them) that consistently worked. The author is seeing results of people building on stuff that came with assumptions that don&#x27;t match new problem. Or people straight-up ignoring root cause in their solutions or methods. Common problems.
评论 #11604704 未加载
tango12大约 9 年前
Reg. the architecture question: People generally start carving out microservices once they hit some scale.<p>What about starting off with microservices (because tools like k8s make the otherwise insane management overhead more tractable)? Could that be a possible solution?<p>The problem of scaling state, databases need to handle anyway. Ideally the same database just keeps on working as you go up. Or atleast the protocol is the same, and you switch out the implementation from a single instance to a clustered version.
cateye大约 9 年前
One of the underlying problems is that there isn&#x27;t a formula (= process) for innovation. Most software development tries to create a competitive advantage by creating something unique that isn&#x27;t easy to replicate.<p>So, every process around being able to deliver that by just applying that process creates a false hope. Or it is not meant for this purpose but the &quot;buyers&quot; aren&#x27;t aware of it and have other expectations.
DanielBMarkham大约 9 年前
As somebody who loves startups and small teams, and who has a job working with both small and big organizations, I have been living this scaling thing for a long time.<p>I&#x27;d like to give you a simplistic answer, like &quot;All you need, kid, is a small team! For anything!&quot;<p>Slogans like that are true, but yet they are terribly misleading, because 1) many organizations are already terribly overstaffed, and 2) it doesn&#x27;t really help to tell teams &quot;What do I do right now?&quot;<p>So here&#x27;s as simple as I can make it:<p>Good organizations will do whatever is necessary to make things that people want, even if that means instead of programming, the programmers sit on the phone and do some manual chore for people as they call. Before you code anything, you have to be hip-to-hip with some real person that you&#x27;re providing value to.<p>But as soon as you have those five folks sitting on the phones doing something useful? You gotta immediately automate. Everything. This means you&#x27;re going to have all freaking kinds of problems as you move from helping ten people a day to helping a million. You have to automate solutions, access, coordination, resource allocation, failovers, and so on -- the list is almost endless (but not quite)<p>As they grow, poor organizations take a scaling problem and assign it to a person. Somebody does it once, then they&#x27;re stuck with it for life. Good organizations continue to do it manually, then immediately automate. Somebody does it once, then the team immediately starts &quot;plugging all the holes&quot; and fixing the edge cases so that nobody ever has to manually be responsible for that again.<p>Growing &quot;sloppy&quot; means you end up helping those million people a day -- but you have hundreds of people on staff. Meetings take time. Coordination takes time. There are a ton of ways to screw up. People tend to blame one another. Growing good means you can be like WhatsApp, servicing a billion users with a tiny team of folks.<p>If you&#x27;re already an existing BigCorp and have been around for a while -- odds are that you are living with this sloppy growth pattern. That means you need to start, right now, with identifying all the feedback loops, like release management, and automating them, such as putting in a CI&#x2F;CD pipeline. Not only that, but there are scores of things just like that. You have a lot of work to do. It might be easier just to start over. In fact, in most cases the wisest thing to do is start over.<p>Now picture this: you&#x27;re an Agile team at BigCorp and you&#x27;ve got the fever. Woohoo! Let&#x27;s release often, make things people want, and help make the world a better place. But looking around, all you see is ten thousand other developers in a huge, creaky machine that&#x27;s leaking like a sieve. You go to a conference with a thousand other BigCorps, just like yours. Are you going to want to hear about how it&#x27;s better just to trash things and start over, about the 40 things you need to have automated right now but don&#x27;t, or how to make your section of 150 programmers work together; how to &quot;scale agile&quot;?<p>Scaling Agile is an issue because the market says it is an issue.