今日推薦開源項目：《竟無語凝噎 dumb-password-rules》
今日推薦英文原文：《New Project? Just Hardcode It》
今日推薦開源項目：《竟無語凝噎 dumb-password-rules》傳送門：GitHub鏈接
推薦理由：眾所周知，設置密碼的時候總是有些規則來幫助你提高安全性——從基本的不能純數字到必須加入一個特殊符號等等，但是有些規則實在是有點讓人無語……這個項目收集了擁有讓人無語的密碼規則的網站，有些前車之鑒還是不要再犯比較好，當作茶餘飯後的趣聞一讀也不錯，畢竟限制密碼為六個字元什麼的實在是有點太讓人無語凝噎了……
今日推薦英文原文：《New Project? Just Hardcode It》作者：Allen Helton
原文鏈接：https://medium.com/better-programming/new-project-just-hardcode-it-bac72e1a231e
推薦理由：在速度至上的時候，選擇不去想太多也是一種選擇
New Project? Just Hardcode It
Spending too much time building configuration nobody asked for? What about writing an extension point you』ll never use? Just hardcode it
If you follow my writing, you know I have two strong beliefs:- Time to market is the key to success
- Value iteration above all else
Have you ever been in a situation where your team committed to getting a project done in a certain amount of hours, but you went over because a piece of configuration was a bit more complicated than expected? And come to find out your clients don』t even use that configuration?
It』s frustrating to you because you spent all that time coming up with a robust set of configuration that nobody uses. It』s frustrating to your clients because you delayed getting their software because of configuration they don』t want.
So How Do We Change?
Hardcode it. Unless you specifically committed to building a piece of configuration, just hardcode it. Place value on iteration. Quickly get the product to your consumer. Let them see what they like and don』t like.You』ll be amazed how many people are happy without configuration they think they need.
Let』s take a look at an example. Your team is responsible for building a sandwich ordering app. The app presents users with a list of ingredients they can select before they hit submit. After they submit their order, it goes to the cooks who then process the order and deliver it to you via bicycle. Very 2019.
Image by Kai Pilger from Pixabay
But someone on your team has the idea to introduce a 「the usual」 concept. The user logs in, sets their ingredients for the sandwich they order all the time, and hits save. Now they have a one-click order option.
Somebody else suggests adding configuration for the cooks to mark when an ingredient is out of stock. Seems necessary so you don』t have orders missing ingredients, so you add that into the mix.
Another person brings up that you need a priority membership. People can pay to become pro members so their sandwich orders bump up to the top of the queue automatically. Pay more, wait less.
Before long, you have a list of features and configurations that have easily doubled or tripled your time to market if you build them all. What do you do now? Delay the release?
No.
Hardcode what you can. Omit the unnecessary features. Get some user testing in before building out all your features.
Build, measure, learn
In the book Lean Startup, the author talks about the principle of build, measure, learn. In short, it is a feedback loop that helps you iterate and improve your product.
Diagram adapted from Ries, E. (2011) 『The Lean Startup,』 New York: Crown Business.
Build something small. Measure feedback from customers. Learn from their needs. Then start the cycle over again. Build one of the needs you just learned about. Measure if you met the need. Learn how it can be improved.
In our sandwich app, all we need to do is display a list of ingredients and take payment. It displays the order on a screen to the cooks. The cooks mark the order complete. The bicyclist delivers the order. Iteration 1 complete.
Show it to your customers. Get their feedback. Turns out they really need the ability to mark ingredients out of stock. Learn where the priorities are. Go build it.
Maybe they never bring up the idea of 「the usual.」 You saved yourself time that you could have been innovating. By omitting or hardcoding features that could have been configurable, we allow ourselves to spend our time building what the customer truly wants.
Do People Really Do This?
Yes! Many companies are out there right now changing the world by building products and services that we actually need. In fact, if you take a look at the GitHub flow, you can see this is the model they follow.
GitHub Flow from GitHub
The GitHub flow proposes that you deploy a new feature to production before merging it to master. So getting the feature out in front of your customer base before considering it gold or even feature complete is the main idea. Doing so enables you to verify the feature is something your customers will use.
What do you call software your customers are happy to use? A market success.
This is a strategy that many startups follow. You won』t be alone or trodding new ground if you go down this route. You will be joining the thousands of other companies in the happy customer club because you will be getting software they want to them quickly.
Call to Action
Don』t overthink it. Software doesn』t have to be hard. The best architects make simple solutions of complex problems. How do they do that? Hardcoding it. They don』t dirty up the water with unnecessary configuration.They get the problem solved the fastest they can to get exposure. They measure their success from the feedback of their customers. They learn about the needs and new features that are necessary.
I』m not saying you need to throw everything away you』re currently doing, but consider being more agile and getting your customers exposed to ideas earlier in the process. Don』t let you hold you back. Value iteration. Value simplicity. Value a market success.
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
