開源日報 每天推薦一個 GitHub 優質開源項目和一篇精選英文科技或編程文章原文,堅持閱讀《開源日報》,保持每日學習的好習慣。
今日推薦開源項目:《幻想命名指南 fantasyname》
今日推薦英文原文:《Perfection Is Holding You Back. Let』s Talk About How To Break Free》

今日推薦開源項目:《幻想命名指南 fantasyname》傳送門:GitHub鏈接
推薦理由:給自己家的孩子起名字從來都是一門學問,從古至今,無數的好壞例子引發的各種慘劇都證明了這一點。這個項目是另一個名字生成項目的開源實現,它們最終的結果都是生成一些奇怪的名字——或者應該稱之為幻想風格,你可以通過任意組合它提供的標識符來生成一些難以想像的詞語,至於要不要真的把這個詭異的單詞拿來扣在某個倒霉孩子的頭上……
今日推薦英文原文:《Perfection Is Holding You Back. Let』s Talk About How To Break Free》作者:Costas Andreou
原文鏈接:https://medium.com/better-programming/perfection-is-holding-you-back-lets-talk-about-how-to-break-free-1fcb86b9ff85
推薦理由:即使現在看起來完美無缺的成果,也遲早都要接受改造的命運

Perfection Is Holding You Back. Let』s Talk About How To Break Free

Inelegant solutions are sometimes OK!


Photo by Jonathan Hoxmark on Unsplash

Perfection is a funny thing. It refers to the idea that something could be so good that it couldn』t possibly be improved any further. Now, we know, however, that is not the case. There will always be room for improvement, whether through incremental or transformational change.
Don』t be afraid of perfection, you』ll never reach it—Salvador Dali
In this article, we are going to explore the concept of incremental change and how this seemingly simple concept can be extended across different areas.

Perfection Is a Process, Not a State

Let us start with a problem all too familiar to those of us in the software industry.

For one reason or another, you』ve inherited a problematic piece of software; it might be a component of a system or a whole application. Regardless of the specifics, the application is ridden with so much technical debt or bad decisions and design that it is technically debt insolvent. That is, there is no point even attempting to bring it back to par; it will be cheaper to start again.

Photo by Christina @ wocintechchat.com on Unsplash

Assuming no cost, resource, and time constraints, no one disagrees that this is exactly what needs to happen. Alas, as it is usually the case, the budget or business drivers are not there. 「It』s not that bad,」 「it hasn』t caused that many problems this quarter,」 and 「we will probably just decommission it altogether next year」 are some of the common justifications given from the powers above.
Perfection itself is imperfection.—Vladimir Horowitz
Our job as product owners, delivery managers, tech leads, and/or technical architects is to make sure that we reduce the risk we and our applications face. Knowing the perfect solution, dropping the bloody thing, and starting again doesn』t quite get us anywhere. 』Fraid not, however, as the path to perfection is through a careful road map of strategically chosen imperfections.

Imperfect solutions, even seemingly ugly ones, are sometimes needed to get us to our end goal, which will bring us closer to perfection than ever before. Don』t be afraid to pitch your plan and explain why your proposed not so perfect solution is only temporary but will lead to big things.

Define the End Goal

Defining the end goal before you start making any decisions is imperative. It will enable you to focus on what』s important and force you to focus on things that matter.

The end goal, however, should not be the actions to be taken. That is, dropping the application and starting again is not the end goal. Production stability and supportability could be some of the end goals.

Photo by Ian Schneider on Unsplash

Iterative Change

To achieve the end goal, you will need to create a road map on how you will get there. You need to break the plan into distinct milestones. Don』t concern yourself with budgets or how to achieve this at this point. Simply know the broken down states that you need to achieve to get you to the end. It might be things like moving the back end from database A to database B. They』re not holistic solutions, but it will be a move in the right direction.

As long as everything ties back to the overarching plan, the end goal, don』t be afraid to tackle one small piece at a time. Don』t let the imperfections paralyse you and hold you back.

This is incremental change. It can be on a functional level or architectural level; it can even be on a planning level.

Photo by Clark Tibbs on Unsplash

Don』t Be Afraid to Change the Plan

In the same way that sprints, requirements, and development work evolve, so do the plans. With each new bit of information, you』re better equipped to plan ahead. Sometimes that will mean changing the plan; other times it will reinforce the existing one.

In either case, you can always have the best (most perfect?) plan.

This also helps promote an added level of agility, which stops you from sticking to a plan due to previously made decisions. You always make a decision based on the data available at the time. This is often demonstrated by a story of a person going to the cinema. You』ve paid £15 to watch a movie, only to realise 20 minutes in that it is complete rubbish. Do you waste the next two hours staying simply because you』ve already paid for it, or do you accept the sunk cost and move on, taking those two hours back and doing something else?

Closing Thoughts

If there is a single thing you take away from this post, it should be that it』s never all or nothing. In the real world, sometimes things take a while to happen, but with perseverance and a plan, big things can be achieved. It could be that some of the interim stages of the plan include inelegant solutions; that fleeting phase should not be a reason why you do not take that path to success.
下載開源日報APP:https://openingsource.org/2579/
加入我們:https://openingsource.org/about/join/
關注我們:https://openingsource.org/about/love/