今日推薦開源項目：《控制這個遊戲 untrusted》
今日推薦英文原文：《Being Fast or Getting Faster? (aka Build Momentum, not Velocity)》
今日推薦開源項目：《控制這個遊戲 untrusted》傳送門：GitHub鏈接
推薦理由：一個網頁遊戲。在這個遊戲里你需要的當然就是——作為主角經歷冒險最後迎來故事的結局，不過這次有點不同：你需要調整這個遊戲的代碼來繼續前進，這就到了用得上 JS 知識的時候了。當然了，需要的更多不是 JS 的代碼知識，而是極具柔軟性的思維，過關的方法並不只有一種。
今日推薦英文原文：《Being Fast or Getting Faster? (aka Build Momentum, not Velocity)》作者：Kislay Verma
原文鏈接：https://medium.com/@kislayverma/being-fast-or-getting-faster-421a6bde08cf
推薦理由：要想跑得快，首先要站得穩
Being Fast or Getting Faster? (aka Build Momentum, not Velocity)
With technology becoming a large, often critical part of any large business today, businesses always want their technology NOW — to prove product market fit, to leapfrog ahead of competitors in new offerings, and to stay ahead of newcomers by building an unassailable technical moat. Needless to say, the market always wins, and pure technological concerns are often left behind in favour of achieving the next critical business goal. As engineers, we don』t always do, or get to do, the best technical thing — we often settle for meeting the end goal.Repeat this story of developers building the just-enough solution writing not-so-good code using the not-best-suited tech stack over a couple of decades and we end up with a collective belief that good code and short timelines are opposites of each other, and never the twain shall meet. I want to question this folk wisdom by calling out that there are caveats to this, and there are now well proven ways where we can (and teams have) delivered consistently good technology in great timelines.
The thing with 「good code takes longer」 is that it holds good only if we are in the building game for a short period. Short term is fine for early start-ups, who don』t know if they will exist the next year. They should focus on doing whatever it takes to get a foot in the door and finding their first customers. But if a team is past that stage and knows that it is there to stay (at least for while), different rule apply. As a team, we should of course be as fast as we can today. But I would argue that the actual goal should be more ambitious— the goal should be to get faster over time.
Build momentum, not velocity.
Let』s be clear, doing good work does take longer. The current problem has to be thought through, future problems have to be anticipated, architecture has to be figured out for functionality and scale, technologies have to be evaluated and selected etc etc etc ad nauseam. All this is a lot of work. What this means in the context of our current discussion is that if we want to be fast right away, the only way to do it is to do a shoddy job. Simply 「be fast」 is a poor goal for a team.
Now consider what happens if we explicitly state our goal in terms of getting faster over time. How can we get faster when business problems coming at us are of increasing difficulty? The way I see it, the only choice is to not do some things so that we get to the finish line quicker. However, we cannot drop the feature requests because that』s the job. So we must drop some technical things. And the only way to drop technical things but still do a good technical job is to make sure that we are able to build on what we have. We build something once, take our time about it, and re-use it every time in the future.
Build momentum, not velocity.
Some of you will now realize that I』m getting at building platforms (Yes. Again. I know). The above statement is a paraphrasing of the golden rule of platforms (which is to build once and re-use in every relevant use case). But the idea of 「get faster via DRY」 is more widely relevant and platformization is only one of its by-products. We can apply it at multiple level of abstraction with some pretty cool results.
At the code level, good code leads to libraries and abstractions which can be re-used for faster intra-component feature development. Team members never have to write the same thing twice because it is already available in an easily consumable way. Clean interfaces and clear, extendable behaviours ensure that we only work on the critical new stuff. This level of abstraction imposes the least penalty on current speed.
At a component level, the getting faster principle leads to service based architecture(or similar things) where technical capabilities are made available for reuse across multiple teams. It is slow at first, but if we do it well and do it right, next steps become ever faster as we isolate the changing parts from the non-changing ones and can focus on the changes needed now. Again, we are sacrificing current speed for future turbo-charge.
At an even larger scale, we are looking at reusing entire domains across the organization to come up with new business propositions. This is the platform play at it most potent — an organization which can compose business ideas whole cloth out of existing tools/teams/processes can respond and innovate faster than its rivals in the market. This kind of strategic advantage is hard to beat. Obviously, getting into this mindset and executing well on it is a very very hard thing to do.
Build momentum, not velocity.
None of the above means that the things that were built earlier are absolutely never modified again. The idea is to modify them as little frequency as possible. The idea is to 「do fewer things to move faster」 as we move forward, and we have to be willing to pay the occasional fine as long as the average feature delivery time is shrinking.
Notice that the above technical principles are not emerging from an explicit technical directive, but from a kind of management principle of getting faster over time! Ergo, this is an organization pattern. We are extending the size of the team and trying to identify the things that team has already done and should not do again. The core capabilities and processes are well known, and can be used in varying contexts without fundamentally altering the org. The undercurrent powering this is a conscious eye for 「composability」 of capabilities. If a system (tech/non-tech) cannot be used to compose something bigger than itself, it will end up being re-invented elsewhere (i.e. that which is platformized will defeat that which isn』t). This is clearly not the way to being faster. We should take the time now to ensure if the class, the service, the infra that we are building has enough functionality to provide business value and enough flexibility to mould itself to other use cases.
So don』t repeat yourself. Let the time you spent in the past be an avalanche to to power your future
Build momentum, not velocity.
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
今天推薦項目又是遊戲，當然要好好玩一玩啦。