# ENTRIES TAGGED "management"

## Four short links: 1 September 2014

### Sibyl, Bitrot, Estimation, and ssh

1. Sibyl: Google’s System for Large Scale Machine Learning (YouTube) — keynote at DSN2014 acting as an intro to Sibyl. (via KD Nuggets)
2. Bitrot from 1997That’s 205 failures, an actual link rot figure of 91%, not 57%. That leaves only 21 URLs as 200 OK and containing effectively the same content.
3. What We Do And Don’t Know About Software Effort Estimation — nice rundown of research in the field.
4. fabric — simple yet powerful ssh library for Python.
Comment: 1

## Four short links: 26 June 2014

### IoT Future, Latency Numbers, Mobile Performance, and Minimum Viable Bureaucracy

1. Charlie Stross on 2034every object in the real world is going to be providing a constant stream of metadata about its environment — and I mean every object. The frameworks used for channeling this firehose of environment data are going to be insecure and ramshackle, with foundations built on decades-old design errors. (via BoingBoing)
2. Latency Numbers Every Programmer Should Know — awesome animation so you can see how important “constants” which drive design decisions have changed over time.
3. Extreme Web Performance for Mobile Devices (Slideshare) — notes from Maximiliano Firtman’s Velocity tutorial.
4. Minimum Viable Bureaucracy (Laura Thomson) — notes from her Velocity talk. A portion of engineer’s time must be spent on what engineer thinks is important. It may be 100%. It may be 60%, 40%, 20%. But it should never be zero.
Comment

## Everything is distributed

### How do we manage systems that are too large to understand, too complex to control, and that fail in unpredictable ways?

“What is surprising is not that there are so many accidents. It is that there are so few. The thing that amazes you is not that your system goes down sometimes, it’s that it is up at all.”—Richard Cook

In September 2007, Jean Bookout, 76, was driving her Toyota Camry down an unfamiliar road in Oklahoma, with her friend Barbara Schwarz seated next to her on the passenger side. Suddenly, the Camry began to accelerate on its own. Bookout tried hitting the brakes, applying the emergency brake, but the car continued to accelerate. The car eventually collided with an embankment, injuring Bookout and killing Schwarz. In a subsequent legal case, lawyers for Toyota pointed to the most common of culprits in these types of accidents: human error. “Sometimes people make mistakes while driving their cars,” one of the lawyers claimed. Bookout was older, the road was unfamiliar, these tragic things happen. Read more…

## Four short links: 20 March 2014

### Smart Objects, Crypto Course, Culture Design, and Security v Usability

1. Smart Interaction Lab — some interesting prototyping work designing for smart objects.
2. Crypto 101 — self-directory crypto instruction. (via BoingBoing)
3. Chipotle Culture — interesting piece on Chipotle’s approach to building positive feedback loops around training. Reminded me of Ben Horowitz’s “Why You Should Train Your People”.
4. Keybase.io Writeup (Tim Bray) — Tim’s right, that removing the centralised attack point creates a usability problem. Systems that are hardest to attack are also the ones that are hardest for Normal People to use. (Can I coin this as the Torkington Conjecture, with the corollary that sufficiently stupid users are indistinguishable from intelligent attackers?)
Comment

## Four short links: 18 March 2014

1. On Managers (Mike Migurski) — Managers might be difficult, hostile, or useless, but because they are parts of an explicit power structure they can be evaluated explicitly.
2. Big Data: Humans Required (Sherri Hammons) — the heart of the problem with data: interpretation. Data by itself is of little value. It is only when it is interpreted and understood that it begins to become information. GovTech recently wrote an article outlining why search engines will not likely replace actual people in the near future. If it were merely a question of pointing technology at the problem, we could all go home and wait for the Answer to Everything. But, data doesn’t happen that way. Data is very much like a computer: it will do just as it’s told. No more, no less. A human is required to really understand what data makes sense and what doesn’t. (via Anne Zelenka)
Comment

## Four short links: 1 February 2012

### The Invention-Commoditisation Cycle, Software Estimations, Fullscreen Browser API, and File Formats in Javascript

1. Cycles of Invention and Commoditisation (Simon Wardley) — Explosions of industrial creativity rarely follow the invention or discovery of a technology but instead its commoditisation i.e. it wasn’t the discovery of electricity but Edison’s introduction of utility services for electricity that produced the creative boom that led to recorded music, modern movies, consumer electronics and even Silicon Valley. However, utility provision of electricity did more than just create a new world, it disrupted existing industries (both directly and through reduced barriers of entry), it also allowed for new practices and methods of working to emerge and even resulted in new economic forms – such as Henry Ford’s Fordism. This isn’t a one off pattern. The cycle of invention/commoditisation repeats throughout our industrial history, following a surprisingly consistent pathway. Understanding this pattern is critical to anticipating the changes emerging in our industry today – whether that’s the web, cloud computing or the future changes that 3D printing will bring. Simon explains the Business of the Internet in one blog post. Simon is king.
2. Why Are Software Development Task Estimations Regularly Off By A Factor of 2 or 3? — never a truer word spoken in parable.
3. Using the Full-Screen API in Browsers (Mozilla) — useful! The older I get, the more I like full-screen mode. I found myself wishing my email client had it, then someone pointed out that was called “mutt in a shell window”. Fair ’nuff.
4. File Formats in Javascript (GitHub) — pointers to libraries for different file formats in Javascript.
Comment