[Links of the Day] 09/04/2020 : TRAX deep Learning library, The next decade in AI, 1:1 questions

• The Next Decade in AI : Paper by Gary Marcus where he explores the possible future of AI over the next decade
• 1 on 1 meeting questions : a collection of 1:1 questions, great list that can help any manager pick the right question for the right context. As long as you are able to read the room/ team/ person.
• Trax: advanced google deep learning library built on top of JAX. It is actively used by the DeepMind team and aiming code clear while providing advanced models like Reformer.

[Links of the Day] 07/04/2020 : Incentivizing Innovation, Network Performance analysis, Neural Networks for embedded systems

• The Effects of Prize Structures on Innovative Performance : how to incentivize innovation? Well, the authors found that a winner-takes-all compensation scheme generates significantly more novel innovation relative to a compensation scheme that offers the same total compensation, but shared across the ten best innovations. However, like every psychological paper, you have to take it with a grain of salt.. reproducibility is always difficult.
• nfstream : Python package providing fast, flexible, and expressive data structures designed to make working with online or offline network data [github]
• Neural Networks on embedded systems : a good overview of the challenges and available neural network architectures for running on embedded systems.

[Links of the Day] 07/01/2020: 2019 AI index report, Essential Guide to electronics in Shenzhen, Tech Lead Expectations for engineering projects

AI index report 2019 : a little bit generic but still a good refresh of where we are and where we may be going.
Essential Guide to Electronics in Shenzhen : Huaqiangbei electronics market in Shenzhen is a must-visit for any tech aficionado. On top of the diversity of things, you can find you literally have access to a swarm of manufacturer and engineering group that can build whatever you need or can think of under one roof.
Tech Lead Expectations for Engineering Projects : an awesome overview of the tech lead by Gergely Orosz @uber. It provides a good overview and guidance of what this role consists of, and what the expectations are.

[Links of the Day] 10/09/2019: 6 pager, engineering user stories, disaggregated persistent memory

• Using 6 Page and 2 Page Documents To Make Organizational Decisions : The famous Jeff Bezos six-page document and review meeting process, as a mechanism to address this challenge. I like the concept but it can be hard to adopt without a company-wide push from the top. 
• Engineering guide to writing correct User Stories : Nice and concise guide that will help you to write better user stories and focus on their needs.
• OpenFAM : a programming model for disaggregated persistent memory. This looks cool but I really wonder if HP labs ( and the parent company) is going anywhere with this. They touted the whole "the machine" a while back but we can't see any production-ready application of the concept yet.  [paper]

[Links of the day] 21/10/2016 : Manager & Career Mgmt podcasts, Memory Enhancement, Computer Scientist Handbook

• Manager Tools & Career Tools : podcast about management and career . 
• How to Think Like a Computer Scientist : interactive handbook , its a little bit more about learning python than actually being a computer scientist. But a good intro to programming. 
• Multiplicity of memory enhancement : human memory is complex, and with the accelerate advance of technology to support (and supplant)  our  retention capability. New ethical and societal consequence emerges. The authors looks at the different memory systems and how technology evolution affect them. 

[Links of the day] 11/05/2016: teaching with wargaming , EU FRAND OSS threat, Teams Coordination tradeoff

• Teaching strategy with wargames : fantastic article on how the teaching philosophy behind wargaming in the US army (navy and marines) 
• FRAND : FRAND stand for Fair, Reasonable, And Non-Discriminatory licensing terms. This is the standard proposed by EU to be used for the future single digitial market. This standard, if implemented, will become a massive roadblock for the use, creation and consumption of open source software because it will not allow royalty free license to be used. However, its not too late and EU citizen comment on the proposal here. 
• Coordination amongst teams trade-offs: Team coordination is like designing a distributed system , compromise have to be made.

Corporate Strategy Conformism

One of the frustrating aspects of corporate behavior is the tendency for a large portion of the enterprise population to chose the most common rather than the most profitable strategy. The natural assumption is that the market interaction, amongst humans and between corporate entities, is driven by the desire to achieve straightforward payoff maximisation. It is not just an assumption; it is often a contractual obligation that management should first and foremost consider the interests of shareholders in its business actions. 

As a result, conformists’ strategy behavior within a corporation’s executive seems to be a contrarian to the requirement of the strategic decision making process. These comportements seem to be widely spread within the corporate world. Every year, we see a new fade coming and spreading like wildfire, bi-modal from Gartner, we need a platform, etc.. 

This generated quite a lot of frustration from me as I was trying to understand why such behavior was commonplace. I wasn’t fully satisfied by herding instincts or widespread incompetence justification that were so often put forward. This just didn’t add up because in a competitive system, under-performing strategies should have been eradicated a long time ago due to evolutionary constraints, and yet instead the conformist strategy persisted.

Behavioral conformity :

Recently I came across a series of Game Theory papers [ 1 - 2 - 3 - 4 ] that provide the beginning of an answer . This research indicated that spatial selection for cooperation is enhanced if an appropriate fraction of the population chooses the most common rather than the profitable strategy within interaction range. 

One of the premises of this research relies on the aspect that humans are social animals that are not solely driven by the desire to maximise fitness, but also aim to socialize and identify oneself within a group of like minded individuals. The main idea is that some of the individuals participating in a competitive game do not adopt the strategy that is the most profitable but instead, the strategy that is the most common in the group or within one's interaction range. Another interesting side effect of this behavior is that the individual and group benefits from the strategic approach homogeneity, which can explain why this behavior persist in the face of more individualistic corporation. 

As executives in a corporation are still humans (until proven otherwise), we can assume that these behaviors are transposed, to a certain extend, to their strategy decision making process by incorporating conformity as an alternative to straightforward payoff maximisation in cooperation strategy. We can begin to have a valid explanation as to copycat behavior of management. Naturally, not all participants are conformists, but they all have this tendency to become such, to a certain degree.

Within a network of enterprises doing business and competing against each other, you end up having different participants with various degrees of conformism tendencies. And the repartition and diversity ultimately has an impact on the ecosystem landscape. However, the amount of information available for the strategic decision making choices greatly influences the conformity tendency and this is often abused by consulting and analyst companies. 

Conformity by Information overload :

It has been demonstrated that conformist tendencies for choosing a particular strategy is reinforced with the increase of available information. And that is why consulting and analyst companies are able to hook-in so many corporations with a similar pitch. When overwhelmed with information, humans tend to turn to a third party to make the decision for them. 

This approach is well known and applied in retail. For example, as soon as you step into a mobile phone shop, you are assailed by a multitude of phones to chose from. As the customer starts to feel disoriented by this tsunami of choice, the “helpful” shop assistant quickly step in to advise you. At this stage, customers are more than happy to be led to the “ideal” phone they need. 

Following a similar scenario in the corporate world, management often relinquish their strategic decision power after being bombarded with information. This onslaught, being orchestrated by the same businesses that will sell them the strategy they “need”. 

Luckily for advisors and the advised corporation, conformist behavior delivers some non negligible benefits. 

Benefits of conformism :

What is interesting is that the research [ 5 - 6 ] show that the adoption of strategy is most common within the interaction range of the player regardless of the expected payoff. While you would expect this to be detrimental, it has been shown that the participant adopting the conformist approach, coordinates their behavior in a way that minimizes individual risk and ensures that their payoff will not be much lower than average.

Moreover, the effect of conformism in game theory is similar to the one we witness in the business world. This behavior fosters the emergence of large homogeneous clusters competing with each other in the same ecosystem. The participants in these groups benefit from the cooperation by virtue of the network reciprocity. And from this network reciprocity effect, they benefit from a minimization of invasion risks by defectors.

  

As a result, while you do not get the chance to greatly outperform the market, you are still providing a better than average return, while benefiting from a group protection. These types of results are generally regarded as positive by company boards and hence conformist behavior is rarely questioned, but usually encouraged (but not always consciously).

Leveraging conformism situational awareness

The great thing about conformist behavior, is that once you have learned to spot it within the business ecosystem, you can leverage it to your advantage. By drawing a map of a business’ ecosystem, you can identify its’ participants, strategic approach and spot homogeneous clusters competing in the population.

Armed with this information you can identify weak clusters to disrupt. Weak clusters are often characterized by the presence of conformist leaders. Leaders are corporations with a high collective influence in the network. If leaders conform, they lose the capability to capitalise on their central position within the network by forfeiting their capacity to search for a more successful strategy. This means that the business within the cluster will suffer from a form of sclerosis and won’t be able to coordinate and/or formulate a counter strategy when challenged. As a result, individual corporations in the cluster are more vulnerable as the network effect dwindles.

Another way to leverage conformism at your advantage is to spot companies that copy neighboring strategies, when the neighbor’s business belongs to a different evolutionary stage. Imagine that Company A is selling utility components and use a platform strategy. Company B uses Company A’s product but sells custom components. If Company B decides to mimic Company A’s platform play, you then have the opportunity to to out-compete Company B by industrializing Company B’s components.

Conformism or Anti-conformism ?

The conformist approach can be a valid choice as it creates non negligible benefits. However, this needs to be an informed choice, not a contrived one. Corporations need to understand the state of the playing field and decide whether or not leveraging the cluster effect might benefit them or hinder them. Moreover, by understanding how network cooperation effects are detrimental to them, companies can tailor their own strategy to take advantage of the conformist tendencies of their surroundings. In the end it boils down to understanding the surrounding corporate environment and to know when to blend in or not.

[Links of the day] 20/01/2016 : next gen configuration management, RamCloud K/V store, Fragility of complex systems.

• mgmt : Next generation configuration mgmt that tries to relies on three key design pattern : 1. Parallel execution , 2. Event driven 3. Distributed topology. Note that the main challenge is to be able to deliver repeatable execution with distributed topology, lets keep an eye on it and see how it evolve. [github]
• SLIK: Scalable Low-Latency Indexes for a Key-Value Store from the ramcloud crowd. [all RAMCloud Papers]
• The Hidden Fragility of Complex Systems : Very good paper demonstrating how the complexity we build into our system hide its overall fragility : “In short, fragility emerges due to increasing structural correlation that spans system degrees of freedom and system degrees of abstraction. Fragility is hidden from us because it is emergent."

Links of the day 10/12/2015: Networks, Crowds, and Markets book, end to end encrypted DB, low level Datacenter devops

• Networks, Crowds, and Markets : Books on the different scientific perspectives and approach to understanding networks and behavior. Drawing on ideas from economics, sociology, computing and information science, and applied mathematics, it describes the emerging field of study that is growing at the interface of all these areas, addressing fundamental questions about how the social, economic, and technological worlds are connected.
• ZeroDB : An end-to-end encrypted database protocol.
• Vapor : can't believe a company actually named themselves vapor .. anyway . While their hardware is semi interesting what really picked my interest is their Open Data Center Runtime Environment. It aims to offer capability to expose and manage low level DC capabilities such as Power and Temp. I am not sure if devops will really want to go that low but this might be a nice addition to orchestration framework for meta optimization. 

Using financial tools to manage technical Debt

Technical debt is a term commonly used in the IT sector. This term, first introduced by Ward Cunningham, describe the deferred necessary work during the planning or execution of a software project. However, while the term debt comes from the financial vocabulary, quite often the analogy stops there. I find this rather disconcerting as we can borrow more than the terminology, we can borrow the mechanism associated with the term in order to prevent, address, classify such liability. Some started already to push the analogy closer to the economic concepts. Lets first have a look at the two main type of technical debt.

External vs. Internal Debt :

We need to understand that developers group maintain two type of debt, external and internal. The external debt represent the total amount of deferred work that was contracted or required by a third party. The creditor can be a customer, another group within the company, feature for the product manager, etc..

On he other side, we have the internal debt, which is only visible within the group and only impact the work executed internally. Like the submerged part of an iceberg, the internal debt is invisible to the outside world, tend accumulate faster,and is sometime the reason for the creation of external debt. Moreover, the internal debt often need to be resolved in order to chip away at the external one. This dependency increase significantly the cost of paying the external one.

In order to maintain the analogy, we could describe internal debt as credit card debt, payday loan, etc.. Easy to acquire and accumulate and snowball easily if we don't pay attention. While, on the other side, the external debt is more like contracting a mortgage for a house, any failure to repay it can lead you to deep trouble. Internal debt tend to have a high interest rate as the more you wait the higher the chance you pile up more debt that you need to repay while the external one tend to have a lower one.

To follow the analogy we can classify the debt as follow :

	Internal	External
Frequency of acquisition	high	Low
Visibility	low	high
Interest Rate	high	low
Risk	low - medium	High

How do team accumulate debt :

It is not rare to see team, project, company being trapped in the IT equivalent borrow-and-spend cycle. Lets have a look at the technical debt acquisition spiral.

Project inception:

The Technical Debt (TD) slippery slope can start right at the project conception phase. Often, part of the requirements, statement of work, and/or analysis are missing. This situation can quickly create an initial credit buildup since trying to fulfill correctly the work at that stage is often unfeasible due to lack of real understanding of the requirements. For many people TD become the only choice. TD generation immediately puts the project in a bad position as you are accumulating debt at a time when you probably do not have enough "velocity" to make even a single payment in an effort to reduce the debt balance. However, often you do not have a choice unless you are part of a big enough organisation that can weather the initial cost.

Daily project routine :

The daily development effort soon come into play to help you cover Internal TD cost. However, often this internal TD is accruing interest and putting you deeper in debt. Moreover, the high interest rate of the internal TD make it even harder to catch up on the debt you already contracted at the inception stage of the project.

Real requirement settle in :

Like most project, at some point the actual requirements comes in forcing you to re-evaluate the technological choices as well as established scheduled. Sometimes, you need to acquire a certain type of technology, skill set or even workforce to cope with this mutation. With every acquisition comes a certain amount of inertia to fulfill it further increasing the debt burden.

Customer comes in :

Here, external debt start to form as milestone and deadline have to be met. Quite often to meet them teams cut corners and the hidden internal debt accumulate in order to avoid default on the external one. At this stage, the project risk spiraling out of control unless we establish clear way of dealing with the increasing cost of debt.

Preventing technical debt accumulation :

How do we resolve the debt crisis that every group face at some point ? Like any financial issue, you need to have a plan.

Preemption via process management :

One of the most common way to prevent debt buildup is to use a process management method. Agile approach like Kaban or Scrum are in vogue for the moment. They tried to enable just in time delivery by minimizing the development cycle in order to allow as much agility as possible. Effectively, it limit the potential amount of debt that can be accumulated before taking action and enables greater visibility.

However, do not dismiss the other approach such as waterfall, TOGAF, ITIL, 6sigma, etc... Each alternative have their own merits, default and should be used depending of the circumstance. Agile method are best used when the project inception phase generated a lot of debt ( in term of unknown requirements by example) and create the need for a on the fly adaptation model to deal with changing requirements.

More industrialized development project with defined, well understood and highly repeatable efforts are more effectively managed by a highly structured method. Agile approach would create too much waste and potential dispersion which result in technical debt generation.

Remember, one size doesn't fit all and moreover you need to adapt your process as the project mature ( or change ). By example, with the structured approach in a rapidly changing environment you end up rapidly overrunning your allocated resources due to change control associated with structured methods i.e. you're applying a method designed to reduce deviation to an activity that is constantly deviating.

Snow balling:

This classic debt reduction strategy simply target the technical debt that can be payed off the fastest and you work you way up the debt pile. This requires to have a clear understanding and provisioning of resource to deal with it. However, if you end up strapped in resource this is not always possible. One of the great thing with this approach is it create the perception of momentum which help reinforce the team commitment in dealing with this predicament.

Too Big to Fail :

This options might be riskier, but if you are desperate, you might want to try it and hope for a not too painful bailout. Simply put, you are trying to externalize the risk by following the old adage : “If you owe a bank thousands, you have a problem; owe a bank millions, the bank has a problem”. The objective is to rely on investment by piling up external debt in order to subsidize your budget. As a result, the overall exposure of the company force it to invest more into it in order to avoid significant repercussion at a larger scale.

On the downside, you have to be careful to not hit the debt wall. This can happen when the project external debt outweigh the benefit of pumping more resource into it. The consequences are that project manager and all the members of the team may lose significant reputation and also impact negatively their career or position within the company. 

When it's already too late:

Well when you are in too deep with technical debt there is various options. But you need a plan to mitigate the personal and corporate impact.

First you need to acknowledge the issue. Then you might consider notifying the creditor(s), the product manager by example for internal debt or the customer for the external one. however, i would suggest considering the various options at your disposition:

• Negotiating a technical debt adjustment with your creditor by stretching some for of debt over a longer period of time. However this can only be applied to external debt due to its nature.
• Alternatively you could try to consolidate your internal debt by exposing it to the external parties. Effectively refinancing your technical debt by securing a lower interest rate on the entire debt load. Typically this would take the form of dedicating a whole sprint to address the internal debt by demonstrating its value to the customer.
• Finally you could seek debt relief with a partial or total forgiveness. This could take the form of re-scoping the requirements, realigning the statement of work etc.. 

Beyond hope :

Most of the time this part is completely ignored in technical debt talk or paper. It is kind of a taboo subject but is still essential to be aware of. Sometimes, you might want to consider defaulting on your debt altogether. By claiming insolvency, you are declaring that you are unable to meet the technical debt fulfillment obligations. Insolvency occurs when the amount of work needed to clear the technical debt is higher than the net worth of the project itself. Quite often, you might want to keep an eye on the debt accumulation rate and stop the project or deliver it /pass it on before it reach that stage.

Links of the day 18 - 05 - 2014

Today's links 18/05/2015: System Performance management, Grows the next agile ?, Async task queue,application sharding

• Shark : System Performance Management in Lua
• Grows method : Some agile manifesto founders got disgruntled with the agile approach and its shortcoming and propose a new one that tries to address its limitation and enhance it. Worth a read but if you don't have time let me just give you this advice: Grow your own method that suit best the mix of personality within your team. Imposing an approach from top down most of the tie led to a shipwreck. However, you are no precluded from seeding it with the right tools. I think that's what this manifesto is all about, create the right environment for the creation of effective project delivery process.
• Machinery : asynchronous task queue/job queue based on distributed message passing ( using GO + RabbitMQ).
• Ringpop : Node.js library providing Scalable, fault-tolerant application-layer sharding from uber. [talk about it here]

From Converged Infrastructure To Disaggregated Datacenter

Recently the (hyper)converged infrastructure model has been picking up steam. Converged infrastructure refers to the tying together of server, storage, networking, virtualization and sometimes other resources into an integrated solution that is managed as a whole rather than through separate management systems.

Smaller to medium sized companies, or those seeking a simpler IT environment, are interested for scalability and easier management. Leading systems vendors are making their move and start to offer their own solution or acquire a company that delivers it which keeps adding to the momentum. Vmware also released its own solution with the EVO:Rail at the latest VMWorld14.

Moreover the next evolution of the data center is already appearing and will directly threaten to a certain extent the converged infrastructure solution : dis-aggregated infrastructure. This solution tries to go a step futher than the simple aggregation. It tries to provide a finer granularity of resource management by pooling the various element in pools ( memory - compute - io - storage) that can be freely composed without being affected by the limitation of traditional server architecture. In a certain way you will be able to compose the right server for the right services - VM - Docker- whatever the buzz of the moment..

Solutions are already profiling at the horizon. On Intel side we have the Rack Scale Architecture solution(RSA). RSA a “rack fabric,” using optical interconnects that allows for a much greater level of dis-aggregation and much greater modularity. The ultimate goal of RSA is completely modularized servers with pooled CPUs, pooled RAM, pooled I/O, and pooled storage. We also have FusionCloud-Sphere-Cube from Huawei. This solution is slightly less advance on the Hardware front however it is a generation or two ahead of the Intel one as it offer a fully integrated software and hardware product solution while Intel is still at the proof of concept stage. But let see what the future reserve, Intel is in for the long haul.

These solutions tend to focus on the hyperscale part of the datacenter spectrum as it requires a significant upfront investment to profit from what the technology has to offer. One of the consequence is that we will see the Converged and Hyper converged solution taking the low to mid sections of the market while the dis-aggregated datacenter approach will initially tap into the mid-high layer of the market. This will further fragment the market and intensify the competition as well as consolidation within the vendor ecosystem. 

Software will be key to the success of such architecture,  currently most cloud system architecture are not well sized or designed to handle fine grained resources management. We are orchestrating operation at a minute timescale and server granularity today. However, we will be managing individual Core, GB of RAM , IO device, Networks at second or even smaller timescale tomorrow and current architecture are not tailored to handle such rapid update rate. 

Last but not least, it will become increasingly more difficult for single solution vendor ( storage - network , etc..) to stay relevant with the rise of such model and they will be forced to go the OEM route or be absorbed if they want to survive. 

As the resources get commodities the hardware becomes a utility and the margin diminish making it difficult for specialized vendor to survive ( look at Cisco and their UCS push). 

Links of the day 24 - 07 - 2014

Today : Web Business Models, Management, HP universal memory to rule them all  ( my precious ...) and network reliability.

• Web and Mobile Business models :List of Internet - Web business models. It give a very good and quick view of the different business model in the start-up web-sphere. Note here is the original list from AVC
• How to Ruin Your Company with One Bad Process : how forgetting personal interest and company politics can ruin a perfect plan. 
• Iris Decentralized Cloud Messaging : a reasonable compromise between the decentralized nature of the brokerless systems and the minimal-configuration and management of the brokered ones. Iris lends itself to building large-scale systems the way we conceptualize and reason about them—by using services as the building blocks, not instances.
• The Network is Reliable - An informal survey of real-world communications failures : Very good list and examples of real world network failure but no surprise the if you want a reliable network or tolerate partition you have to invest the effort , time and money to make it so.. Not magic there.. And even so you are not protected from murphy's law.
• The End of a Necessary Evil: Collapsing the Memory Hierarchy : HP's CTO post/ talk on their big push toward Universal memory, kind of like one memory to rules them all and in HP bind them.