开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《毒鸡汤 nows》
今日推荐英文原文：《Why Leaving a Project Unpolished Is OK》

---

今日推荐开源项目：《毒鸡汤 nows》传送门：项目链接
推荐理由：众所周知，有心灵鸡汤自然有毒鸡汤，前者使人提振精神后者让人看清现实，而这个项目属于其中的后者，包含了一千多条毒鸡汤数据，如果用户数量不算很多的话这些数据可以用上好一阵也不会让用户感到过于重复单调了。

---

今日推荐英文原文：《Why Leaving a Project Unpolished Is OK》作者：Kevin Fawcett
原文链接：https://medium.com/better-programming/why-leaving-a-project-unpolished-is-ok-fe4a43836f40
推荐理由：把视线集中于那些客户确认过的需求上能节省很多不必要的成本

Why Leaving a Project Unpolished Is OK

Sometimes finishing touches are not worth the time or money

While the examples below are limited, the following principles can be applied to almost any industry. The following questions are meant to challenge people to reframe their thinking regarding the value being added.

Does Your Customer Really Want the Bells and Whistles?

“80 percent of features in the average software product are rarely or never used. Publicly-traded cloud software companies collectively invested up to $29.5 billion developing these features, dollars that could have been spent on higher value features and unrealized customer value.” — Pendo’s 2019 Feature Adoption Report.

Don’t spend time adding low-value features backed by assumptions. Perfectionists often tailor products to their ideal image, not necessarily the customer’s. The customer may appreciate the extra features, but not all improvements will change their decision to purchase or retain a product.

Example: A web developer spends a month trying to create a user experience that shows data in a table with filterable/sortable columns.

Unexpected outcome: The customer uses the export feature to download the data and view it in Excel.

Sometimes a simple conversation with a customer can save tons of time and money. In this real-world case, the customer provided the data to a third-party for auditing. There would never be a case where the auditors would be allowed access to the fancy web table.

Are You Using Your Time Effectively?

Example: Nintendo created the Wii U, which allowed players to play on their controller and their TV. The device supports several streaming services, a game marketplace, and a social platform.

Unexpected outcome: Customers don’t buy it because of the limited range of the portable mode, a severe lack of quality games, and a lower standard of graphics than the other consoles.

Time spent polishing a product could be used on other innovations. Just because a feature has value doesn’t mean it’s the most valuable. Nintendo chose to integrate streaming features, despite customers having options available on other devices.

The Wii U was short-lived, and the Switch was born from the lessons learned. Unsurprisingly, the deficiencies of the Wii U, like portability, became the focus, resulting in a huge success.

Can Your Customers Live With Imperfections?

During my time at a large company, I worked on a three-month project, instead of improving the sales website to streamline ordering. The neglected website had a terrible user experience, so I was surprised that we would choose to ignore it.

My opinion changed, however, once I realized my project would save a million dollars annually. Shadowing multiple user-experience interviews with the customer reinforced my view: While customers found the website ugly, they were happy. They could still check out, and support was readily available through chat when they were stuck.

This neglect was successful because the primary focus of the product was to deliver a sales pipeline, not user experience, to resellers for a niche market. People don’t shop on websites like Amazon for their wonderful, polished design; they are interested in the prices.

Are You Perfecting the Wrong Solution?

Consider the classic toothpaste box example: An eight-million-dollar project was intended to prevent accidentally shipping empty boxes when a simple twenty-dollar fan blew them off the conveyor. While this popular example could be fictional (could not find the source), these mistakes do happen.

Example: Valve created the Steam Link, a product that was essentially a wireless HDMI cable for games. PC games could now be played on a TV.

Unexpected outcome: Customers were not interested. Also, many of the games did not work well on TV. The interfaces were designed to be played on a monitor within a few feet of the player. Reading tiny text from across the room was a struggle.

Releasing an unpolished, minimally viable product and testing early can help validate solutions and prevent wasted time.

Am I Getting Feedback From My Customer?

Agile development promotes making small, iterative changes to products. Long-winded, monolithic releases are becoming a relic of the past. Releasing minimally functional, working software faster allows for intermediate user feedback; design decisions are consistently validated.

The customer knows best how they use the product. Without interviewing or tracking, you may be spending time on a feature that could save them a few minutes, when another one could save them hours.

Am I Adding Value?

Unless your website is designed for frequent reading, like Medium.com, the odds of a dark mode being valuable are low. For websites like Netflix, the feature would be appreciated but unnecessary — especially on TV apps, where videos are played fullscreen.

However, that doesn’t mean every feature has to generate huge profits. Sometimes worth can be defined by morals, like adding inclusive features to help people with disabilities, or changing the words whitelists and blacklists to allowlists and denylists.

Am I Getting a Return on Investment?

Features cost time, which means money.

Example: Google Glass released smart glasses that would allow wearers with information and image capturing.

Unexpected outcome: Consumers had no idea about its practical use. While it seemed neat, it did not seem worth the price tag.

All that time spent on perfecting the design (which many customers hated) and features was wasted. The developers should have narrowed their view, focusing on solving a specific problem before adding the finishing touches. From the website, it appears they’ve shifted focus exclusively to businesses.

Am I Delaying Value?

Depending on the industry, the customer may be more concerned with solving an immediate problem than having a perfect solution. Every second a product is not released equates to lost potential revenue.

Revenue might not always be the goal. Imagine the CDC’s impact of delaying the release of information about COVID-19 because someone wanted to add fancy animation.

Conclusion

Starting small with products, keeping them simple, and iterating on improvements after gathering customer feedback can help save time and money. Don’t waste time adding all the bells and whistles before you’ve validated your solution with customers; don’t build a car stereo before you’ve tested the engine.

---

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/

开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《汤里有毒 nows》
今日推荐英文原文：《11 rules of effective programming》

---

今日推荐开源项目：《汤里有毒 nows》传送门：GitHub链接
推荐理由：心灵鸡汤，指的是能够为人的思想提供所谓正能量的文字片段；而反过来派生出的毒鸡汤，则是提供负能量的。这个项目提供了一个畅饮毒鸡汤的地方，简单粗暴的界面可以很方便的分享给朋友，有福同享有难同当嘛。不过这也就图一乐看看就算了，不管是心灵鸡汤还是毒鸡汤，在每个人眼里可能都有不同的感受，它们没有对错正负之分，而你的想法也不应到受这些影响，而是应该由自己决定。

---

今日推荐英文原文：《11 rules of effective programming》作者：Jakub Kapuscik
原文链接：https://medium.com/swlh/11-rules-of-effective-programming-8932f2d99711
推荐理由：让你花掉的时间带来更高收益的小技巧

11 rules of effective programming

This is by no mean an exhaustive list but rather my subjective top after spending several years in IT. Hope you finds some of those helpful

1. The Boy Scout Rule

“Always leave the campground cleaner than you found it” -that’s a great rule to live by. When you are near campground you should make it cleaner even if it was not you that made the mess. That’s one of the rule of scouts. Just the same should apply to programming. As Robert C. Martin paraphrased it “Leave your code better than you found it”. If we find some hard to read piece of application that someone else wrote and we spent some time understand, let’s make it at least a bit better. If it is out of the scope of task we are working on, one can always create new small technical task, describe it well and take it to the next sprint.

Minimalist version of this rule would be more like a sing in public toilets. We should at least not worsen the condition it is in. We have to remember that some people will one day take over that piece of application we developed and will try to modify it. Let’s just not make their life harder.

2. Think about problem, not only solution

Software developers are really great in implementing solutions. We know languages, patterns, libraries, frameworks and understand how to use them. The problem is that often things we are doing make no sense from business perspective. Some features you are developing may be duplication of existing ones that business owner did not know about. Some may not be well-considered and will never make it to next release or simply no user will ever use them. That is a huge wast of time, money and source of frustration. A lot of people do not bother to ask developers on their opinions and just assumes that their job is to deliver the feature. No deliberation. Only technical work.

Developers are the ones working with the application every single day. They know every feature even if nobody used it. Sometimes task that seems to be easy from business perspective takes months of development. Some that seems nearly impossible take days. The reason is lack of communication between the people that will be implementing a feature and ones that request it. There is a huge difference between those two:

1. Create persistent storage for users’ shopping carts
2. Users should be able to save their shopping carts and use it on mobile and web application

The first one is straightforward. No questions asked. The second one is a bit harder as it makes you think about the reasoning and you will be the one proposing solution to a given problem. There will be a lot of questions about details, functional requirements, quality attributes and others. The solution will be much better worked out as now you are not just an executor.

3. Think about Total Cost of Ownership

It is very tempting to sometimes cut corners, skip tests for later, leave temporary solution and promise to correct it later. In most cases you never will if it won’t break. There will be new task, priorities, features to implement and issues to fix. The problem you will have will be that such piece of application probably will break. Moreover, it will be very hard to fix.

Total Cost of Ownership of a feature is a sum of money and effort spent from start of development, through deployment and maintenance, all the way to termination. If we take shortcuts during development it will be the cheapest part of all. You may release faster but maintenance will be terrible, users will be unhappy and in total everything will be more expensive then it should.

It is always better to do it right the first time

4. Use SOLID

There are a lot of great rules in form of acronyms in programming: DRY, KISS, YAGNI, SOLID and much more. SOLID is a set of rules that should help make code cleaner and avoid common traps.

It can be a great checklist for your code before pushing it to repository. Does this class support Single Responsibility Principle? Can this class be substituted by any other from same hierarchy (is LSP fulfilled)? It will help filter out a lot of sources of future problems. Understanding and conscious application of reasons behind each rule will make you better programmer and increase quality of your code reviews.

5. Use Design Patterns

In most cases you are not the first one trying to solve a problem you are facing or implement a feature with similar requirements. There have been thousands of CRM, CMS, banking systems, chats, online shops, marketplaces and basically any possible type of application one can think of. System you are developing may be the best on the market or have some extremely advanced and unique features nobody else have. Still, most of the job will be at some degree referential. Someone else might try to do it on number of different ways and even describe the whole process. It may save you a lot of hassle and guide to better solution.

There is a great book by the Gang of Four presenting some of repeatable patterns that could be used to tackle common problem. It was wrote in 1994 but those are still valid and helpful. In software those are ancient times but somehow problems we are facing writing code are now not much different. There have been a lot of more newer design patterns developed since then. Knowing them can make your job much easier.

All design is redesing. Learn from the experience of others

6. Minimize complexity

Software development is a complex task by it’s nature. Do not make it more complicated then necessary. It is sometimes very tempting to implement some business rules by introducing few extra ‘ifs’ or loops in a function. Development will be faster but code will get darker and adding new features will just make it more complex. If something will go wrong it will simply be harder to find out the reason.

There is a great and very simple metric with a cryptic name Cyclomatic Complexity. It’s was introduced in 70s but can still be very useful. This metric measures number of way your code can be executed. Each conditional statement and loop adds +1 to the score. The smaller the score the better. When we are analyzing a method and the score is in range:

• 0–10: code is well structured and should not cause unexpected problems
• 10–20: code is quite complex and has a lot of potential paths of execution to test. Candidate for refactoring
• 20–50: code is utterly complex and should be subject to refactoring
• 50+: refactoring is a must

# CYC = 1 
def cycle(name, bike, view_points=[]):
    if len(view_points): # +1
        if name and bike: # +2
            for point in view_points: # +1
                print("{} is going on his bike {} to {}".format(name, bike, point))
    else:
        print("No places to go. Sorry")

# CYC = 5

Readability is more important then performance. There are some limitation to this statement but basically readability pays of in a long term. You are able to change your code with less bugs. Micro-optimization may easily make your code a mess and do not bring much value to users.

7. Don’t do it alone

It may sound counter intuitive but programming is a social activity. Age of programmers hidden in darkness of a basement is over. Sharing expertise and experiences is getting more and more important. In the worst case scenario people you are talking to will become your rubber duck but most likely you will receive some valuable feedback. Someone may identify problems in your solution you did not even consider. Taking a look from different perspective is a great tool and is very easily available.

No single person should be responsible for a deployed piece of code. It is a job for a team, not a person, to deliver new features. Code review, pair programming, pull requests are tools that take responsibility from a person and moves it to a group of people with preferably cross-functional skills. Responsibility for an important feature that may influence performance of whole company for better or worse is simply too much to shoulder for a developer. Such situation is very unhealthy and should never take place.

8. Tests are a must

Finding bugs early is extremely important and saves lot of effort and angry calls from clients. Discovering problems early makes them easier to solve. We are able to remember all details and logic behind specific piece of application best when we are developing it. We remember all reasoning for making specific decision and how to debug each piece of application. Cost of fixing bugs grow exponentially over time.

Source: https://deepsource.io/blog/exponential-cost-of-fixing-bugs/

9. Learn English

Sharing knowledge have always been one of fundamentals of software community. Most of the information is written in English and is easily accessible. It it right now most popular language of all in software world. If you are not able to read and write in English you will have much harder time and loose a lot of opportunities. Moreover, syntax of nearly every language is by default written in English.

It is also a good practice to write comments and names in code in English. It makes code cleaner and more consistent with the syntax. If we are sharing code with other people, especially from different country, there is basically no better way then to do it in English.

10. Multitasking makes you stupid

People are simply not able to make multiple things at once well. Software development requires using abstract concept and often building quite complex mental models. If you get distracted or start working on something else you lost it all and have to start from the beginning. Moreover, there are multiple studies that proved that multitasking has negative impact on performance, productivity and IQ.

Source: https://insights.sei.cmu.edu/devops/2015/03/addressing-the-detrimental-effects-of-context-switching-with-devops.html

I have once been on a training in a software house that introduced very useful practice. If you do not have any scheduled meetings or calls you are free to play “Tomato”. The rules are very simple -you do not have to speak to anyone. If someone ask you any question, you answer with a single word: “tomato”. Therefore, you show that you are in a middle of work and do not want to be bothered. When people are in ‘tomato mode’ they also indicate it in their calendars for chosen hours. It is not always good to go fully “tomato” but it is interesting way of improving performance.

11. Better less, but better

The less code and infrastructure to maintain the better. There are a lot of people that like to boast about huge number of line of code in their application, number of modules, servers, nodes, pods, micro-services or any other things. There is a chance that every line of code in their application is of highest quality and is just in the right place. But this is a very rare case. If you can do the same job with usage of fewer resources you should go for it. Quality is a the goal, not quantity.

---

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/