I was watching an interesting talk about how the Pinterest engineering team has created an abstraction layer to control views at a behavioural level for iOS applications. The speaker pointed out that as programming matures, we keep adding layers of abstraction to simplify our jobs as developers. When he mentioned controlling views at a behavioural level, it reminded me of behaviour driven development, where the tests are defined in an extremely abstract manner. For example:
Given that I have logged in
When I check my shopping cart
I should see any items that I added previously and did not buy
Declarative programming hasn’t quite reached this level of abstraction yet – even with BDD practices, developers still have to implement each statement themselves. But we’re edging ever closer. With recent improvements in machine learning, how long will it be before we can simply give a series of behavioural tests to the system and have a complete application created for us?
Of course, to be completely abstract, we could even enter the request “Make me an application that solves my shopping problems”. A supremely smart machine learning system could hypothetically take a statement like that, as well as any data it has already on your existing shopping habits, and produce a new app that you might enjoy. Perhaps you only need to give it minimal feedback such as “I don’t like the colours” or “I was hoping to find more scented soap”.
Putting that aside for a minute, consider the nature of the kinds of programs we make at the moment – they’re typically general-purpose and require reasonably strict sets of requirements. Creating a system driven only by a series of high-level tests makes perfect sense for an application like this. Good behavioural tests firmly define the boundaries of a system, providing simple binary outcomes that a machine learning system can evaluate against. Implied requirements such as “the application should not crash” are patterns that a sophisticated machine learning system should recognize over time, leaving only the desired system behaviours and regular user feedback as the required inputs.
Perhaps future programmers will in fact be testers? Programmers already have plenty of reasons to learn testing to further their careers, and here is just one more.
Further reading: The End of Code (Wired Magazine)