I’ve been extending a network, where the baseline requirement is for a comparatively cheap, POE-compliant (802.3af), gigabit, VLAN-capable switch.

A (now EOL) Netgear GS724TP is great! You need to be open-minded about using Firefox v3 Portable to talk to the web UI because it’s so old, but aside from that it’s got 24 ports and is functionally bang on the money.

Except for the noise.

It sounds like a Dyson vacuum on turbo mode. This thing is cheap. Like, £60 on eBay cheap. And there’s the reason!

Except, is that a reason? Really?

I’ve tried to order replacement fans – there are blog posts and videos about silencing these things, usually by hacking an ugly 12cm hole in the case and putting in a different fan altogether. I opted for near-silent 40mm fans to fit like-for-like, but I’m damned if I can find anything that matches the wattage (12V @ 0.18A).

But there is an elegant solution if you’re willing to wave a soldering iron about for a few minutes: add an in-line 200ohm resistor (£0.04 each) and those stupid fans will slow down to be near silent yet still pump through enough air. (Into the red-wire if you’ve Googled this looking for a solution).

And this is my gripe with Netgear. They produced a pretty neat piece of kit costing hundreds and couldn’t be bothered to put in 12p of resistors to make it right. Like the airline saving pennies by scrimping an olive from the in-flight meal on a £10k F ticket, they’re cheap bastards.

Like many organizations, mine is one that has adopted agile in name rather than in spirit. That is to say, agile terminology is liberally scattered around, but little of it refers to the true definition or traditional application.

Take sprints.

In a product-centric structure, agile (and sprints) makes a lot of sense. By focusing on a functional outcome at the end of every sprint, you get to truncate the feedback loop, and time necessitates focus on the truly important rather than the nice-to-have periphery.

But we are not product-centric: We are an enterprise-scale project delivery organization. Not unlike many others in fact. I have a number of delivery and governance functions, all of which cater to different technologies and demands.

So do I slice horizontally, with a backlog and sprint cadence for each project? Or slice vertically, with a backlog and cadence for each function? With the former, I have a challenge of assigning and managing human capacity across project sprints. With the latter I have to manage project demands and conflicts across functions. It’s a lose-lose situation manifested by long delivery times, serialization across functions, and systemic capacity management challenges.

I’m trialling a new cadence that aims to address these challenges. Of course we won’t put out a working product each sprint: we don’t make products. But the rest just might work.

When people write articles on the subject of blockchain, they usually repeat the same explanations of how it could work rather than how it actually will work. A recent LinkedIn post with just such an article is a great example.

“It would require a cultural shift towards the adoption of new working practices, but if successful it could prove, for example, that money went on organic fertiliser instead of chemicals.”

https://techerati.com/features-hub/comment/erica-stanford-cuts-through-blockchain-bs/

This is the bit I don’t understand, and nobody has realistically explained.

15 years ago I worked on e-Conveyancing and one of the biggest challenges was network effects. A system that provides authenticated, instantaneous end-to-end transactional completion was effectively worthless as long as a single transaction existed outside of the network.

Similarly here, at some point money exits the supply chain into fiat so suppliers – ultimately people? – can buy things like food or other basic staples. They’re not doing so with integrated* digital currencies and likely never will. And at that point the value of the entire network collapses.

(*Integrated is a key theme. While blockchain is a gold-rush and there are many players there is little incentive to interoperate, and thus the network chain is even shorter before collapse. Ultimately things will coalesce into a small (single?) pool of chain suppliers, reducing the risk of collapse. But at this point the decentralized benefit of blockchain disappears and the solution is no different to an existing centralized transactional log, i.e. blockchain doesn’t need to exist anyway.)

As with e-Conveyancing the solution is an all-or-nothing adoption that is to all intents and purposes impossible to implement and enforce, particularly in a world that can’t politically agree on, well, anything!

In my view, this is why blockchain is so much hype over substance. I get the math and it sure works in theory, but it relies on a technologist’s utopian ambition that just doesn’t acknowledge the reality of the world.

I think Erica tries to hint at this at the very end, despite falling back on a banking paradigm that she herself criticizes of the mainstream media:

“But once people have access to “mainstream” wallets that allow anyone to send any amount of money, pay direct debits, interchange between crypto and fiat seamlessly and with insurance – many if not all will have no need for an ordinary, day-to-day bank account ever again.”

My point is that for the promised benefits to materialize it’s not “people”. It’s all people. And it’s not “access”. It’s use.

I’m yet to see a proposal to overcome this issue.