Sunday, 30 March 2014
In defense of defaults
It is necessary but not sufficient for something to be possible: The possibilities need to be communicated also, and we have limited capacity for in-band communication. Default settings are a great way to communicate desiderata in a way that sidesteps our ubiquitously crippling bandwidth limitations.
Friday, 28 March 2014
Social network topology and interpersonal bandwidth as a predictor for conflict
Response to: http://squid314.livejournal.com/329561.html?view=11210073#t11210073
A lot of arguments and disagreements come about because of misunderstood terminology: words and phrases that evoke different imagery and have varying definitions between different groups of people.
These differences come about because of uneven diffusion of information through the social network, and restrictions in interpersonal bandwidth more generally.
We can reduce the long-term aggregate severity of arguments & disagreements (at the expense of some short term pain) if we increase our communications bandwidth both individually and in aggregate; and act to bridge the gaps between super-clusters in the social network.
A lot of arguments and disagreements come about because of misunderstood terminology: words and phrases that evoke different imagery and have varying definitions between different groups of people.
These differences come about because of uneven diffusion of information through the social network, and restrictions in interpersonal bandwidth more generally.
We can reduce the long-term aggregate severity of arguments & disagreements (at the expense of some short term pain) if we increase our communications bandwidth both individually and in aggregate; and act to bridge the gaps between super-clusters in the social network.
Tuesday, 25 March 2014
Accidental and essential complexity
Response to: http://250bpm.com/blog:36
This sort of reminds me of Rodney Brook's commentary on essential and accidental complexity. Once you have got rid of the accidental complexity, you are left with the essential complexity, which cannot be further reduced without compromising on functionality.
You can shovel the essential complexity around your system design all you like, but the overall quantity of complexity still remains constant. A practical consequence of this is that you can move the complexity away from the 1500 line function by splitting it up into smaller functions, but that complexity remains embedded in the implicit relationship that exists between all of your 50 line functions. (Plus some additional overhead from the function declarations themselves).
Of course, splitting up the large function into smaller ones gives you other benefits: Primarily the ability to test each small function in isolation, but also (and more importantly) the ability to read and understand the scope and purpose of each small function without being confused by irrelevant details.
Personally, I would like to have the ability to give names to chunks of code within a large function - and to write tests for those chunks without having to extract them into separate smaller functions.
I would also like to see better tools (and widespread usage of those that exist) for building various graphs and diagrams showing the call-graph and other relationships between functions and objects, so that we can explore, understand, and communicate the implicit complexity encoded in program structure more easily.
This sort of reminds me of Rodney Brook's commentary on essential and accidental complexity. Once you have got rid of the accidental complexity, you are left with the essential complexity, which cannot be further reduced without compromising on functionality.
You can shovel the essential complexity around your system design all you like, but the overall quantity of complexity still remains constant. A practical consequence of this is that you can move the complexity away from the 1500 line function by splitting it up into smaller functions, but that complexity remains embedded in the implicit relationship that exists between all of your 50 line functions. (Plus some additional overhead from the function declarations themselves).
Of course, splitting up the large function into smaller ones gives you other benefits: Primarily the ability to test each small function in isolation, but also (and more importantly) the ability to read and understand the scope and purpose of each small function without being confused by irrelevant details.
Personally, I would like to have the ability to give names to chunks of code within a large function - and to write tests for those chunks without having to extract them into separate smaller functions.
I would also like to see better tools (and widespread usage of those that exist) for building various graphs and diagrams showing the call-graph and other relationships between functions and objects, so that we can explore, understand, and communicate the implicit complexity encoded in program structure more easily.
Wednesday, 12 March 2014
Fundamental prerequisites for development
Great technical leadership guides developers to move in the same direction by articulating a clear (and simple) technical philosophy and encouraging the formation of a strong and consistent culture.
Well thought through infrastructure and high levels of automation allow high quality work to be performed at pace.
Intelligent and passionate developers are required so that work is not pulled backwards by inconsistencies introduced because of insufficient levels of attention and concentration.
Once all this (and more) has been achieved; only then is it worthwhile thinking about whether "Agile" makes sense as a risk management and/or stakeholder communications approach.
Well thought through infrastructure and high levels of automation allow high quality work to be performed at pace.
Intelligent and passionate developers are required so that work is not pulled backwards by inconsistencies introduced because of insufficient levels of attention and concentration.
Once all this (and more) has been achieved; only then is it worthwhile thinking about whether "Agile" makes sense as a risk management and/or stakeholder communications approach.
Sunday, 9 March 2014
The expectation of perfection is poison
If you create an expectation for flawless perfection, you are setting yourself up to be lied to.
It is a distressingly rare thing to find an organisational culture that successfully puts a premium on humility, public acknowledgement of ones' own flaws, and the learning of lessons for the future.
I am particularly reminded of my experience whilst working for Fidelity: As a company, they tried very very hard to create a culture that stood apart from the financial industry mainstream: One of maturity, professionalism, introspection and self awareness: Yet still the testosterone-stewed aggression of some individuals, combined with industry behavioural norms rapidly undid all that good work.
In time, the company's self-regulating mechanisms kicked in and the offenders were shown the door, but the experience shows how quickly and how easily a shallow message backed by aggression beats a deep message backed by considered thought.
It is a distressingly rare thing to find an organisational culture that successfully puts a premium on humility, public acknowledgement of ones' own flaws, and the learning of lessons for the future.
I am particularly reminded of my experience whilst working for Fidelity: As a company, they tried very very hard to create a culture that stood apart from the financial industry mainstream: One of maturity, professionalism, introspection and self awareness: Yet still the testosterone-stewed aggression of some individuals, combined with industry behavioural norms rapidly undid all that good work.
In time, the company's self-regulating mechanisms kicked in and the offenders were shown the door, but the experience shows how quickly and how easily a shallow message backed by aggression beats a deep message backed by considered thought.
Towards a declaration of independence for the internet?
Shortly after I first heard of bitcoin back in 2011, my first thought was that it could be used to implement a sort of peer-to-peer exchange in which the instruments being traded would not be stocks and shares in the conventional sense, but voting rights in committees that made decisions controlling shared interests. I envisaged that this would operate as a sort of virtual crypto-corporation controlling some real-world assets.
Since then, others have come up with ways of using the bit-coin infrastructure to provide a general-purpose computing resource, so one could, in principle, replace the virtual crypto-corporation and the real-world assets with some source code and a computing resource; raising the possibility of truly autonomous, distributed, financially independent digital entities; which is about as close to a declaration of independence as the internet is ever going to be able to give.
Since then, others have come up with ways of using the bit-coin infrastructure to provide a general-purpose computing resource, so one could, in principle, replace the virtual crypto-corporation and the real-world assets with some source code and a computing resource; raising the possibility of truly autonomous, distributed, financially independent digital entities; which is about as close to a declaration of independence as the internet is ever going to be able to give.
Lessons from computer games
Operation Flashpoint & Armed Assault:
Total Annihilation:
- In a serious gunfight, pretty much everybody dies.
- Don't join the army: It's a dumb idea.
Total Annihilation:
- There is no such thing as too much.
- People set themselves up for failure by limiting the scope of their imagination.
Planetary Annihilation:
- Attention is the most critical resource.
- Play the person, not the game.
Friday, 7 March 2014
Computer and network security in the robot age
In response to: http://www.theatlantic.com/technology/archive/2014/03/theres-no-real-difference-between-online-espionage-and-online-attack/284233/
It doesn't matter if you are "just" eavesdropping or if you are trying to cause damage directly. If you are trying to take control over somebody else's property; trying to make it do things that the owner of that property did not intend and does not want, then surely that is a form of theft?
Possession isn't just about holding something in your hand: It is also about power and control.
The implications of this might be a little hard to see, because right now computers don't have very much direct interaction with the "real" world.... but it won't be like that forever.
The implications of this might be a little hard to see, because right now computers don't have very much direct interaction with the "real" world.... but it won't be like that forever.
Take me, for example. I am working on systems to control autonomous vehicles: Networked computers in charge of a car or a truck.
This is just the beginning. In a decade or more, it won't just be cars and trucks on the road that drive themselves: airborne drones; and domestic robots of every size and shape will be everywhere you look.
What would the world look like if we allowed a party or parties unknown to seize control of all these computers? What kind of chaos and carnage could a malicious actor cause?
We have an opportunity right now. A tremendous gift. We need to put in place the infrastructure that will make this sort of wholesale subversion impossible; or, at the very least, very very much harder than it is today, and we need to do it before the stakes become raised to a dangerous degree.
Saturday, 1 March 2014
Nature vs Nurture; Talent vs Practice
In response to: http://www.bbc.co.uk/news/magazine-26384712
Practice is the immediate (proximal) cause of high performance at a particular task. The notion that anybody has evolved an "innate" talent at something as specific to the modern world as playing a violin is obviously laughable.
However: The consistently high levels of motivation that an individual needs to practice a skill for the prerequisite length of time is very much a function of innate characteristics; particularly personality traits; Notably those associated with personality disorders such as GAD, OCD & ASPDS.
Of course, the extent to which a borderline personality disorder can be harnessed to support the acquisition of extremely high levels of skill and performance is very much a function of the environment. For example:
1. The level of stress that the individual is subjected to.
2. The built environment within which they live.
3. The social culture that they are part of.
4. The support that they get from family and friends.
In summary: To exhibit high levels of performance you do need some innate characteristics, (although not necessarily the innate "talents" that we typically associate with skill), but those characteristics need to be shaped and formed in the right environment: both built and social.
It should be possible to engineer a higher incidence of high levels of performance in selected individuals, but I suspect that the interaction between personality and environment is sufficiently subtle that we would not be able to guarantee an outcome in anything other than statistical terms.
Practice is the immediate (proximal) cause of high performance at a particular task. The notion that anybody has evolved an "innate" talent at something as specific to the modern world as playing a violin is obviously laughable.
However: The consistently high levels of motivation that an individual needs to practice a skill for the prerequisite length of time is very much a function of innate characteristics; particularly personality traits; Notably those associated with personality disorders such as GAD, OCD & ASPDS.
Of course, the extent to which a borderline personality disorder can be harnessed to support the acquisition of extremely high levels of skill and performance is very much a function of the environment. For example:
1. The level of stress that the individual is subjected to.
2. The built environment within which they live.
3. The social culture that they are part of.
4. The support that they get from family and friends.
In summary: To exhibit high levels of performance you do need some innate characteristics, (although not necessarily the innate "talents" that we typically associate with skill), but those characteristics need to be shaped and formed in the right environment: both built and social.
It should be possible to engineer a higher incidence of high levels of performance in selected individuals, but I suspect that the interaction between personality and environment is sufficiently subtle that we would not be able to guarantee an outcome in anything other than statistical terms.
Subscribe to:
Posts (Atom)