今日推薦開源項目：《小猿做題 mathAI》
今日推薦英文原文：《The Problem of Estimating》
今日推薦開源項目：《小猿做題 mathAI》傳送門：GitHub鏈接
推薦理由：以前做題不會也想不出還沒有答案的時候，小猿搜題這樣的搜索 app 興許就能成為一線生機。而這個項目雖然暫時並不能幫你解決太複雜的問題，但是如果你寫一堆加減乘除的算式給它的話，它能通過圖像識別看懂之後給你個答案出來——當然，不是搜出來而是自己做出來的。儘管在現在的版本中它只能做做簡單四則運算，但是這只是個基礎而已，它還有很大的發展空間。
今日推薦英文原文：《The Problem of Estimating》作者：Robert Field
原文鏈接：https://medium.com/@snarfoid/the-problem-of-estimating-fcb9e4527950
推薦理由：估算越多就越容易出現不確定因素，這在哪裡都是一樣的
The Problem of Estimating
Estimating problems is commonplace, especially in the world of high tech, and is a valid exercise. What could be more natural than wanting to know how long something will take to finish? How long till my table is ready? When will my pizza arrive? When are you going to check in? All estimates. Every answer satisfies that basic need to know, even though every one is a guess. Maybe a very educated guess, based on data or heuristics, but still a guess.When the problem at hand is simple, a guess is fine. If my table took fifteen minutes instead of the alleged ten, I sucked it up. I didn』t starve. No one went to the hospital. It was inconsequential. An estimate then, for an inconsequential problem, is perfectly fine. There are no real repercussions. Now guess what? Not all problems are like this. If your Mom has stroke, it matters if you get her to hospital within the hour. That is not a problem you want to under estimate.
Let』s take the stakes up a notch to my high tech world. I got tasked with estimating the scope of a very large project for a large client. The client wanted to know, quite naturally, how much effort the project was. In other words, how much was it going to cost them? Once you start talking real money, estimates do have consequences. Everyone loves coming in under budget, but over budget is way, way different. Things get really uncomfortable in that case.
So I pondered over the problem set, got the basic holes ironed out. resolved all the dependency issues, and determined how to split up the work among our teams. Like I said, it was a large project, and so my estimates were large. With something so big, I felt a real need to build in some flexible time to deal with unforeseen issues and the inevitable bugs that would also arise. I』ve been through this before, and nothing really ever goes just the way you plan it. The bigger it is, the less likely it is to go well.
My boss nearly coughed up his liver when I showed him the numbers. He was adamant that there was no way we could deliver these numbers to the client. It was just unacceptable. So we bargained. This shouldn』t take so long, that we can skip testing, and the other thing can be done in parallel. If everything went super smoothly, maybe, just maybe, it would work. So the numbers came down, not where I wanted, and not where my boss wanted either. But the new numbers were deemed acceptable for presentation.
Work began. Code got checked in. Testing started. Hooray, the project was released. Except, not hooray. Horror. There were critical bugs right from the start. Every time we would solve one, two more came in. We were drowning, and the client, not surprisingly, became, shall we say, unhappy. They were quite rightly pissed, as they should have been.
My take away lessons from this unfortunate episode were two-fold. First, going in with my original numbers would have made the client unhappy from the start. Assuming they wanted to proceed from there, we would have in theory delivered a quality product, resulting in a happy customer. Instead, we chose a short-term trick to get the client to accept, then both made the client unhappy and made ourselves look bad, damaging our relationship. The lesson is that risk is very real, and the consequences of missing an estimate can be high.
Second, any project comes with ups and downs. You should know in advance what the real goals are. You have likely heard the of the project management triangle. Pick two: cheap, fast, good. In my example above, we clearly, though perhaps unconsciously, picked cheap and fast, unknowingly sacrificing quality. Knowing our client, our guiding principles should have been cheap and good, thus ignoring our time to completion, or, dare I say, going with my original numbers. But the client had an alleged deadline, things got negotiated around, and we wound up in a mess.
So as wonderful as estimates are, sometimes things take as long as they take. You can』t plan for everything single thing, but you can plan for how you want to deal with the problem and where your biggest risk is.
下載開源日報APP：https://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
