- Frog Design Predictions (Wired) — designers pick product trends, arrayed from probable to speculative.
- Making Wrong Code Look Wrong (Joel Spolsky) — This makes mistakes even more visible. Your eyes will learn to “see” smelly code, and this will help you find obscure security bugs just through the normal process of writing code and reading code.
- Simple Testing Can Prevent Most Critical Failures — We found the majority of catastrophic failures could easily have been prevented by performing simple testing on error handling code – the last line of defense – even without an understanding of the software design. We extracted three simple rules from the bugs that have lead to some of the catastrophic failures, and developed a static [Java] checker, Aspirator, capable of locating these bugs. One of the tests is a FIXME or TODO in an exception handler.
- Quantum Machine Learning Algorithms: Read the Fine Print (Scott Aaronson) — In the years since HHL, quantum algorithms achieving “exponential speedups over classical algorithms” have been proposed for other major application areas […]. With each of them, one faces the problem of how to load a large amount of classical data into a quantum computer (or else compute the data “on-the-fly”), in a way that is efficient enough to preserve the quantum speedup.
Support experimentation and continuously evaluate to stay ahead.
Businesses have always come and gone, but these days it seems that companies can fall from market dominance to bankruptcy in the blink of an eye. Kodak, Blockbuster and HMV are just a few recent victims of the rapid market disruption that defines the current era.
Where did these once iconic companies go wrong? To my mind, they forgot to keep challenging their assumptions about what business they were actually in.
Businesses have two options when they plan for the road ahead: they can put all their eggs into one basket, and risk losing everything if that basket has a hole in the bottom, or they can make a number of small bets, accepting that some will fail while others succeed.
Taking the latter approach, and making many small bets on innovation, transforms the boardroom into a roulette table. Unlike a punter in a casino, however, businesses cannot afford to stop making bets.
Business models are transient and prone to disruption by changes in markets and the external competitive environment, advances in design and technology, and wider social and economic change. Organizations that misjudge their purpose, or cannot sense and then adapt to these changes, will perish.
The sad truth is that too many established organizations focus most of their time and resources on executing and optimizing their existing business models in order to maximize profits. They forget to experiment and explore new ideas for customer needs of tomorrow.
Variations in Test-Driven Development
“Red-Green-Refactor” is a familiar slogan from test-driven development (TDD), describing a popular approach to writing software. It’s been both popular and controversial since the 2000’s (see the recent heated discussions between David Hansson, Bob Martin, and others). I find that it’s useful but limiting. Here I’ll describe some interesting exceptions to the rule, which have expanded the way I think about tests.
The standard three-step cycle goes like this. After choosing a small improvement, which can be either a feature or a bug fix, you add a failing test which shows that the improvement is missing (“Red”); add production code to make the test pass (“Green”); and clean up the production code while making sure the tests still pass (“Refactor”). It’s a tight loop with minimal changes at each step, so you’re never far from code that runs and has good test coverage.
By the way, to simplify things, I’ll just say “tests” and be vague about whether they’re technically “unit tests”, “specs,” “integration tests,” or “functional tests”; the main thing is that they’re written in code and they run automatically.
Red-Green-Refactor is a very satisfying rhythm when it works. Starting from the test keeps the focus on adding value, and writing a test forces you to clarify where you want to go. Many people say it promotes clean design: it’s just easier to write tests when you have well-separated modules with reasonable interfaces between them. My personal favorite part, though, is not the Red but the Refactor: the support from tests allows you to clean things up with confidence, and worry less about regressions.
Now for the exceptions. Read more…