今日推薦英文原文：《Moneyball and Software Development》
推薦理由：LeetCode 這個刷題的地方相信或多或少大家都有所耳聞了，打開一個題目，然後對著編輯器擺弄解法，然後寫好之後解法填上去測試結果。這個項目把這個步驟簡化了一下，只需要在 VSCode 中你就可以完成登錄解題等一系列步驟而不需要開個瀏覽器，趁此機會刷點題練習一下自己的演算法知識是個不錯的主意。
今日推薦英文原文：《Moneyball and Software Development》作者：Todd Moses
Moneyball and Software DevelopmentIn a perfect world one has the right team, enough budget, and a realistic timeframe. However, this usually never happens. Software Managers are given team members based on availability, budgets are pre-set and timeframes are rushed. The problem becomes, how does one deliver a quality product within these limitations?
Billy Beane, the Baseball Executive for the Oakland Athletics, had similar stipulations for his team. The result was, 「Moneyball」. A statistical approach to determining what positions on the team required the best players. In other words, given a smaller budget than needed to compete in Major League Baseball, what is the best way to spend it?
The results went against the traditional approach, making the playoffs on a shoestring budget. Concluding with a book by Michael Lewis and later movie of the same name. While powerful for sports management, this team building strategy has many applications in other fields. Including software teams.
Software Leaders have similar issues to Baseball Managers. That is to pay for proven talent at a premium or take a chance on young, unproven developers at much less cost. While the large companies can and do hire the big names (in baseball and software), smaller organizations often have to settle for less. That is, until they determine the positions key to the teams success. In other words, what are the most valuable attributes for their company?
Measuring LimitationEvery person and by default team, has limitations. In software, this means areas of inexperience where actual ability does not match the current requirements. Often, these limitations are subtle. Becoming apparent in the middle of a project plagued by trouble.
Consider a Developer well versed in building database applications. He or she has proven themselves on many difficult projects. They work well with a Front-End Developer who truly understands modern web development with a few high profile websites in their portfolio. Assisting the two is a Database Administrator who uses best practices to build required schemas and an Architect with both development and business experience.
While this team appears solid, there are limitations that could derail a seemingly simple project. The reason is that this team, like most, are very good at a subset of technology, but could become lost if pressed to adopt new ones. Usually, this occurs when a new Architecture Pattern is needed, a change in Framework, or something else that requires a learning curve.
For example, the software team at a small hedge fund was very good at writing financial trading systems using the mature data feeds available for stocks and option pricing. However, when Cryptocurrency trading facilitates were needed to be included into several strategies, the team was a loss. Perhaps the worst part was no one admitted they were unable to quickly implement the new strategy. Instead, the team acted as if it was just another data feed to digest. Fast forward a month later, and the entire project had failed.
At other times, it may be a skills deficit within the team. For example, a new Computer Science Graduate may have only been exposed to a few of the technologies required in his or her new position. If one assumes their abilities are the same as a developer with several years of professional experience, it will cause problems. To make matters worse, many new developers will not clearly state they are unable to do something.
During a Sprint Planning Meeting, it was asked of the team if they felt comfortable with the work assigned for the next two weeks. The answer was 「Yes」 by all involved. When pressed with, 「You are certain that the entire body of work can be completed within the next two weeks?」, the answers started to change. The reason was they were given an out by management. An open channel of communication to admit that the demands were unreasonable.
It is important to understand the Team』s weakness. The area or areas where the team is incapable of delivering at a high level. It can be discovered through trusted communication or testing. Some examples of team weakness include: single stack competency, lack of math skills, inability to code outside of a specific framework, and/or an unrealistic view of their own abilities.
Even the best teams can commit to more than they are capable. Developers by their very nature love challenges and will quickly want to tackle hard problems. For this reason, it is important to have a retrospective after each development cycle. A time where the team can explain the problems, solutions, and changes required to improve. When done correctly, this will lead to a better understanding of the team.
Billy Beane discovered that the most valuable statistic in a Baseball Player was on-base percentage. That is the ability for a batter to make it to a base by any means possible. In Software Teams, there is also a most important statistic. The key is to discover that for your organization.
Unless you have a large budget to hire the best like the New York Yankees, some important calculations need to be done. Beyond a general competency, there are a few key attributes of team members that are more important than all others.
For example, a team dealing with large scale data may need people with a very high aptitude for statistics. A corporate team building Line-Of-Business Software may need people with solid business understanding. The point is that hiring for specific abilities beyond the job requirements will improve the team without increasing the budget.
A Defense Contractor discovered that Software Developers with advance degrees in Physics and Mathematics were much more capable in building missile guidance software than those with a Computer Science background. In a manufacturing company, they found adding developers with a degree in Mechanical Engineering vastly improved the team. Likewise, a corporate team hired developers from a respected coding camp with backgrounds in Accounting and Finance.
Billy Beane was hiring beyond basic competency since every member hired came from Professional Baseball. Meaning. they had an expertise in the required field. It was only after they made the cut to be in the Major League that the other attribute was applied. Thus, managers need to hire competent developers with the chosen attribute(s). Not the other way around.
Another important fact with Moneyball is that Billy Beane let go of many team members to build his roster. Thus, an important first step after discovering the attribute(s) most needed is to remove those team members that do not possess it or who have expertise outside of what is required. For example, Beane discovered that a highly talented First Base Player was not needed. So he removed the cost by replacing the position with a low salary player.
Not everyone on your team needs to be an expert. A general level of competence is all that is needed for many positions. However, it is a best practice to remove team members that do not possess the core competence of software development. That is, have a minimum level of ability that must be met by everyone and specific expert requirements where it matters most.
With that said, some team members are teachable and can quickly get to the level of competency needed. Others may not. It appears there are Career Developers who love what they do and have the desire to constantly improve. Then there are Job Developers that only care about learning enough to keep their paycheck. Those should be eliminated from the team.
Expanding EfficiencyOnce a group is in-place that has the core competence and the magic attribute(s), there is still much work to be done. Ask any professional sports manager who has maxed their budget with talented players yet still suffers defeat. The point is that besides hiring great people, one has to build a team.
This team needs to succeed or fail as a single unit, not as individuals. Accountability is placed on the group and not on any one person. When someone is not doing their job effectively, the group will quickly make adjustments. That is to say, problem individuals will not last long inside a solid team. The team will either help them reach the required level of performance or push them out.
Another aspect is culture fit. Each member of the team must subscribe to the culture. Be it a love for the subject matter, belief in the goals of the company, a desire to build something great, or something else. Yet, every member of the team must be dedicated to the achievement of some objective outside of just completing their work.
In some startups, the common goal is building something worthwhile. At large companies, it is making something noteworthy for their department. Financial developers often measure their success in terms of profitability. The point is that every great team has a goal. A great leader helps guide them to achieve it.
ConclusionWhile it is difficult for a Development Manager to build a solid team on a limited budget, it is not impossible. Making strategic decisions on what positions to fill with high levels of expertise and which to settle for a minimum competency is hard. However, the hardest part is building a cohesive unit dedicated to the achievement of a common goal.
Discover where you need to spend the money for top talent and then fill the other roles with dedicated employees eager and able to assist them. Take the time to listen to the team and build a culture of goal accomplishment over meeting deadlines.
A disturbing trend in software teams is the modern carpentry approach of work fast and take many shortcuts to accomplish the most in the shortest time frame. Then rely upon someone else to find the issues, often at a much later date.
In contrast, a team dedicated to goal achievement may not accomplish as much as a team dedicated to rapid development. However, the end result will be greater. It may take an extra week to complete a release. That is not always a bad thing. A great team will set its own pace based upon quality of work. Great management listens and gives them the time needed to make something worthwhile.