今日推薦開源項目：《新手上路 first-contributions》
今日推薦英文原文：《The Perfect Software》
今日推薦開源項目：《新手上路 first-contributions》傳送門：GitHub鏈接
推薦理由：俗話說得好，萬事開頭難。這一點在各種地方都是相同的——特別是你與別人合作的時候，你會更加小心翼翼確保不給別人添麻煩。這個項目就是一個給 GitHub 新手的貢獻指南，讓初來乍到的新手也能簡單的為開源項目做出貢獻，一旦成功的邁出了第一步，後面的負擔和壓力就小得多了。
今日推薦英文原文：《The Perfect Software》作者：Hassan Habib
原文鏈接：https://medium.com/@hassanhabib/the-perfect-software-2d7905693d56
推薦理由：完美的軟體是不存在的，我們無法預知未來，我們能做的只是讓它更能夠適應未來
The Perfect Software
Don』t ever think there』s such a thing as perfect software, there』s no such a thing.There are, however, relatively satisfying experiences that slowly decline as technology advances and new tools are implemented for better experiences.
The trick here is to build your software to be adaptive to the inevitably upcoming changes before you know what they really are, or how they are going to be.
Because the software you build is nothing but a reflection of who you are, how you felt, and your pattern of thought at the time of developing that software, I see building adaptive software as more than just an intelligent move to build a better experience. It』s also a humble gesture that indicates that what you』re building is not perfect, because you』re not perfect either. Your software is ready to learn new tricks and evolve and morph itself to provide better experiences to its users.
Everywhere in every possible software house you can think of, you』ll hear some developers talking about making the code 「perfect」 — it』s like mirage developers endlessly chasing what they』ll never find.
This eventually causes a lot of tension between the business and the developers involved, because the business will never understand why they need to spend more money to get the same experience, and developers will never be able to explain to non-technical stakeholders why putting in four more weeks of development without any observable results is important for the business.
Some thinkers (such as uncle Bob) suggest that making the software 「right」 is a part of the risk developers should take and include that in their development efforts, as a part of delivering features.
But then again, he』ll say even after taking that risk, the software itself must be in a continuous maintenance state, because software rots, and it requires continuous effort to keep it up to date.
So, what is an adaptive software, what are the measures of success for an adaptive software?
Modularization
The first and most important sign of an adaptive software is modularization or componentization.Modularized software with pluggable, configurable and reusable components makes it a lot easier to change these components and adapt new patterns to provide better experiences.
But with modularization comes abstraction, and abstraction is the tough part. Because abstraction isn』t just about building contracts that both the provider and the consumer should honor, it』s also the art of predicting upcoming changes that you don』t fully understand, or know the nature of.
Building contracts is just like predicting the future. It』s about how long it can hold off, and both sides try to bend it backwards before they decide to sunset your work and build v2.0.
Building v2.0 is a declaration that your prediction of the business needs only lived so long before you went into this dark area where all your predictions and expectations have failed.
That』s why I stress on the notion that developers and engineers are two very different creatures. The first thinks all the problems lie in the code in front of their eyes, while the latter don』t just think of the big picture and the entire process end to end, but they also consider how the software will actually hold up for the next three to five years before it turns into a legacy that everyone tries to stay away from because it』s a pain to understand let alone support.
The Experience
In addition to modularization, there』s the other side of the coin, which is the experience.A successfully adaptive software should evolve not just on the back-end but also to the end-users. They should see something better, not just the same experience, but better, faster, easier and feel improved intuitiveness.
In Steve Jobs』 own words, he used to say: 「Our software should know what users want before they even know they want it.」
And as hard as that is, it』s actually a very achievable, realistic experience that Apple succeeded at some point in time and turned it into reality.
Using the latest UI framework isn』t enough to build a better experience and provide an actual business value to the end-user, just the same way buying the fastest car doesn』t magically turn you overnight into an F-1 racer.
Modern tools will help you turn your vision into a reality faster, but if you have no vision and your software isn』t experience-driven, then the tools are just as good as any others. Tools don』t inspire vision, vision comes from the tools you were born with — your mind, spirit and personal experiences.
David Pullara
While I was writing this article, my friend and mentor David Pullara brought a good point. I can summarize it in one excellent question which is, 「Are all modern adaptations of software good?」And my answer is that I don』t really think so. Some adaptations might cause an end to the software forever and a loss of its customer base.
Engineers must be intelligent enough to understand that building adaptive software then evolving it must be governed by some principles whether the adaptation will actually contribute to both developers』 and users』 experiences or not.
I』ve been to companies where they decided to adapt a new technology just because it』s new (and shiny) — but, that adaptation brought a miserable experience to both developers and end-users.
The Future
Engineering software that will be used by users that have different tastes, opinions and accessibilities can be very challenging, especially considering that these very same users could have two different opinions based on their moods, what devices they used to utilize the software and all different levels of variables.A deeper understanding of people in general, staying in tune with how different people react to different software experiences and interacting and communicating with a wide variety of people can immensely help build better software that people could actually appreciate.
Dear engineers, don』t lock yourself in your office building and design software for users you haven』t even met once. Get out of your offices and meet with your end users, listen carefully and welcome their feedback, challenge their thoughts and think deeply about not just what they are saying, but what they are really saying.
In some companies there are product owners and program managers to do that part, but then a lot of things get lost in the translation. I highly recommend that even if you have a product owner on your team, try to get involved in these end-user meeting. Sit and listen, take notes and put yourself in your potential end-user shoes. This is how you build software.
My favorite story here is when Steve Jobs wanted to sell a printer to potential customers. He didn』t really show them the printer, he showed them a piece of paper that had the print on it. He showed them what the printer could do. He sold them on the experience. It』s the end product that actually matters. There』s a lot to learn there.
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
