开源日报 每天推荐一个 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/