Tag Archives: Innovation

The end of coding

During past couple of years there’s been a strong push from the technology industry to teach everyone to code.

“Every student in every school should have the opportunity to learn computer science” — code.org

Everyone should have the opportunity to learn computer science. Understanding computation changes the way you think, and directing it gives you amazing power to realise your ideas. Understanding concepts like abstraction, coupling, generality, complexity and scale change the way you understand and approach problems. Wielding general purpose programming tools changes the way you solve them.

Software is transforming the world more and faster than anything since agriculture. It is at the heart of business growth and innovation today, both in the technology industry and outside it, and is rapidly changing the way individuals live their lives. Software has taken over our ways of accessing knowledge, of storing and processing information, of publishing and receiving news and media, of executing commercial transactions, and of communicating with our friends, colleagues and communities. The world’s largest bookseller and video service are software companies; our dominant music companies are software companies; our fastest growing entertainment companies and telecom companies are software companies. Companies that aren’t software companies are increasingly depending on software to optimise logistics, supply chains, manufacturing processes, and advertising or provide tools for their employees to produce ever more value. Software is on the brink of disrupting the way we teach and learn, borrow and lend, learn about and care for our heath, and find and consume services of all types.

But despite this unprecedented transformation, one day, coding will be rare. The current enthusiasm for and growth of coding is temporary, an artefact of our tools. Coding is, right now, our best technology for directing computation, but coding itself is not the essence of computer science. Computing is manipulating data and directing algorithmic computation in order to solve problems. Code is our current tool of choice, but we must make better tools. One day, it will be commonplace for people to manipulate data and direct computation without writing a line of code. I can’t wait.

 

Programming is a highly specialised skill. Solving complex problems is naturally difficult, and as a coder, I frequently write programs to solve problems of all sizes. I cringe at the techniques non-programmers bring to bear on easily automated tasks. I happen to be blessed with particular logical and linguistic facilities which mean I can crudely simulate a computer in my head and talk to it in an unnatural language with weird, unforgiving rules (I’m less good at simulating humans). Many people are less well adapted to be good at coding, but not much less likely to benefit from solving complex problems. The tools and methods of programming introduce much of the complexity associated with solving a problem with code, and take those solutions out of reach of the majority of us who aren’t trained in the craft. Programming is not easily learnable, and is an unnecessarily distant abstraction from many problems people may want to solve. People shouldn’t have to learn to code to apply software to these problems.

There are a few tools I can think of that today give non-programmers some programming-like general problem solving power.

Calculators

Calculators have come a long way since the introduction of pocket calculators in the ’70s. Programmable calculators allowed scientists and engineers to solve problems more complicated than simple arithmetic could handle (though they might have used some code to do so), and graphing calculators helped them understand the answers visually. Since the popularity of personal and mobile computers, software calculator interfaces have evolved towards representing the problem the user is expressing, rather than the anachronistic accumulator-style implementation (e.g. typing a whole expression left-to-right at once rather than one term and operator at a time and inside out). Innovative designs like Soulver and Calca embed the calculation in its context and show working on the surface, providing some ability to vary inputs and watch results change live.

Spreadsheets

Spreadsheets are some 30 years old but still fundamentally pretty similar to their first ledger book-inspired ancestors. They’re still the best lightweight accounting tool but also turned out to be a great general purpose calculation and modelling tool, and are good at representing tabular data, too. The tabular format is nonthreatening yet general enough to wrangle into so many roles[1], and the live recalculation encourages piecewise problem solving. Lots of people who work with data are great with spreadsheets. They can do craaaazy things. Up the complicated end, spreadsheets are capable at data storage and exploration (especially since the advent of pivot tables), help people develop and evaluate complicated multi-variable expressions, explore simulations and what-if scenarios, and visualise results. Spreadsheets are a somewhat generative tool, making possible things far beyond the tool creator’s imagination. They are as close to programming as many people get.

Spreadsheets have their shortcomings though, especially in light of today’s standards for interface and power. They’re poor at handling multi-dimensional data, and you usually need to decide dimensionality up-front, or start over. They can roughly simulate vector/parallel calculations by using a range of cells and repeating calculations crosswise, but they don’t understand the shape of your data enough to offer much help doing so. Spreadsheets conflate the interface of a flat two-dimensional tabular view of data with the data itself and with the formulae evaluated on it. Alphanumeric cell addresses are opaque and brittle; either moving data or altering layout is liable to break the other and affect computation. The formulae are hidden and it’s very difficult to verify the correctness, or even understand the functioning, of a spreadsheet you didn’t author.

A few mid-80’s spreadsheet programs attempted to address some of these shortcomings, primarily by decoupling the data from the tabular display: Javelin, Trapeze and Lotus Improv; but they’re long gone and sadly we haven’t seen anything similar in consumer software.

Personal databases

Sometimes a spreadsheet just doesn’t cut it when you have complex or multidimensional data. Data manipulation, query and reporting are the essence of a large range of problems people want to solve. But unlike spreadsheets, it’s my impression that personal databases have sharply reduced in popularity over the past couple of decades. Have they gone out of fashion, or do I just move in different circles now? Perhaps the presence of programmers in any sizeable organisation has discouraged people from using them, on “expert” advice. I remember the distaste I had for MS Access back in university: point and click query building over my dead body! But I was naive, just high on the power of SQL. The capabilities embodied by personal databases should be taught to everyone; not instead of coding, but maybe before it.

I now discover that MS Access can pretty much build CRUD applications for you, and Filemaker much the same. I’m also pretty keen to try out Zoho Creator next time I need to prototype a data-heavy app. Still, while they have evolved a bit, these tools are still not flexible enough to build a real application, just easy forms and views.

 

There are a few more specific fields where non-programmers have tools by which they perform something very much like programming, but without much code. Game development provides a good example: a game is a computer program providing a particular interactive experience. Games are typically really complicated programs, dominated by “user interface”, but a game development team is typically dominated by artists and designers, not programmers (the mix does vary depending on game requirements). These artists and designers use tools built by programmers to realise much of the creative output a game embodies: art, textures, terrain, models, animation, cinematics, level design, puzzles, interaction, narrative. To propose a process whereby, say, a level designer provides drawings and written guidelines to a programmer who then manually translates the design into code, and then repeats that cycle until the designer gets what they want, would be just ridiculous (yet this is how most application interfaces are built today). No, the programmers build a game engine and level design tool and then the designers can work directly in an environment that closely matches the finished game and produce output to be directly loaded into the engine at runtime.

Sadly, today’s user interface design tools are not usable by non-programmers, nor used by many programmers. Point-and-click has been looked down upon by “real” programmers since the invention of the mouse, just as assembly programmers looked down on early Fortran pioneers, C programmers look down on Java, and Vi/Emacs users look down on those who harness an IDE. Those who have mastered one tool or process have great difficulty letting go to adopt something different enough to be significantly more powerful.

For a long time, GUI builders were crap. GUI builders are still crap: they often provide a poor representation of what the rendered interface will look like, are not powerful enough for developers to achieve exactly what they want, and are too complicated and laden with programming concepts for non-programmers to use them[2]. Programmers understandably decide to just fall back to coding, since they’re going to be doing some of that anyway to work around the tool’s deficiencies. This is a mistake, though an understandable one. Code provides a terrible representation of visual concepts with a huge mismatch in thinking modes, especially when that code is procedural rather than declarative or you’re designing the interface as you build it. Recompiling and launching your program to observe each UI tweak is an inexcusably slow development process. I get the motivations (e.g. here, here) but it’s a scandalous waste of effort that designers do all their work in Photoshop and a developer starts from scratch to replicate it. Our tools must improve so that designers can build the real UI, with programmers taking over later for the back-end (Spark Inspector and Reveal hint at the future).

Other tools providing programmer-like power to non-programmers include batch processors (e.g. in Photoshop), node- and layer-based compositing tools (e.g. Shake, Blender), Apple’s Quartz Composer for node-based image processing and rendering, Automator for scripting Mac OS and applications, Mathematica, Matlab, and LabVIEW for scientific and engineering design and analysis, Yahoo! Pipes and IFTTT for web and API mashups, and wikis for content management and presentation. And I must make a special call-out at this point to HyperCard (1987-2000), one of the most influential application design environments to date. I fondly remember building stacks and writing HyperTalk long before grasping any of the concepts I would now consider fundamental to programming. I made things I was proud of and saw people in both my own and my parents’ generation (i.e. educated pre-computers) do the same[3]. If you missed out, do read this reminiscence. HyperCard’s legacy lives on though its influence on hypertext, the web, wikis, and derivatives like LiveCode.

So we have some data analysis and calculation tools for maths, crappy UI builders for interface, and some application-specific tools for games, graphics and hacks. The next generations of these products should radically expand what non-programmers and programmers can achieve without coding. They won’t write code for you, but they will make coding unnecessary. I hope similar tools emerge to cover most of what is now achieved by writing code, enabling the creation of arbitrary useful and high-quality applications by anyone. In particular, we’ll reach a critical point when these tools become recursively self-improving, so that a non-programmer can create a tool which will in turn be used to create more applications, including better tools.

That six-figure-salary engineers don’t consider translating a Photoshop render and some instructions into a functioning user interface to be a tragic waste of their time shows how valuable this problem is to solve. If you’re a programmer and this offends you, consider how much more value you could create if you didn’t spend half your time as a glorified PSD->HTML translator. Yes, yes, I know, front-end is hard, it’s really complex[4]. But so much of its complexity is due to the tools we use, not essential to the problem. All that deep software engineering insight and hard-won domain knowledge is so valuable because building a UI requires thousands of lines of code. When it doesn’t, you can apply your towering intellect to something better.

Most previous attempts at programs that help non-coders make programs have sucked, especially the more general-purpose ones. But we’ve learned a lot about user interface recently thanks to the billions of people now using our interfaces and consequent value of improving them. The challenge of creative tools is presenting an interface that extends expressive power without crushing the user with complexity. While in every domain there will always be experts working at the boundary between impossible and easy, as tools improve things that once required sophisticated knowledge and technique become accessible to amateurs. Witness the explosion in quantity and quality of amateur music and video as the tools of production became good enough and cheap enough to pick up in a weekend. I’m optimistic that as our ability to design interfaces for complex domains improves we’ll create better and simpler non-programmer tools for designing and implementing a wider range of software. For some, these will be the stepping stone to expertise, but for most the tools need only help them get the job done.

 

Coders have a tendency to make tools for coders. It’s much easier to build a tool that works when you can assume a high level of technical sophistication for your users. But tools usable by non-programmers will help programmers too. Reducing the cognitive load of directing computation will enable coders to solve more complex problems faster. Like the mythical successful employee, we should be aiming to do work so great we put ourselves out of our job. We’ll still need programmers and engineers–experienced and creative practitioners of modelling problems, designing algorithms and data structures, taming complexity, and managing process–but they might become like farmers today: a highly leveraged sliver of the population.

A future where everyone can code would be wonderful, but code is only the means to directing computation for now. When our technology reaches the point where everyone has tools for thinking and creating but few need to code we’ll be far better poised to conquer our society’s challenges. Programmers could start building that technology now.

Teaching more people to code is a great step forward, but a future where few need to is even better.

 

Thanks Jessica, Natalia, Nik and Glen for your feedback on my first draft.

[1] Joel Spolsky (once PM for Excel) recounts learning how people actually used Excel.
[2] Apparently Microsoft’s tools have led the pack for a while, but I haven’t used them for a long time.
[3] James Davies: I still remember your dad proudly showing us his stacks and soliciting feedback. That and him ejecting a bone that was choking me with the Heimlich manoeuvre.
[4] I underestimated this complexity for a long time when I was more interested in back-end engineering. Front end is really hard, and the tools are weak.

If you’re in a race, your impact is marginal

Many people are motivated by money, fame and the lure of success. Some of them achieve it. Others, probably a smaller collection, are more deeply motivated by aspirations to have meaningful impact, to make a difference, to change the world (perhaps profiting along the way). This post is directed at you, the aspirational others.

To make a difference, to change a future that has not yet happened, the world needs to end up significantly different thanks to your actions than it would have had you done nothing. This aspect of “what would have happened anyway” that is easy to skip over if you don’t stop to think about it. Will the world become a better place because of your actions, or is it on track to improve in a similar way anyway and you’re just hanging on? Are you actually causing the improvement you wish to see?

This perspective is valuable both within companies and teams, and within society in the large. Michael Abrash tells an enlightening story of his first few weeks at Valve (the company that makes games like Half Life, Counterstrike, and Portal). Valve run a very unconventional organisation, and one of their defining cultural features is that there is no management hierarchy, no authority, and no-one to tell you what to do. So everyone has to figure it out for themselves. This quite understandably leads to an initial period of loss and confusion for people who are used to having at least some direction imposed on them. Abrash found an existing team who were working on a problem in which he was also quite experienced. He writes:

…most of the Source engine team was working on Portal 2 optimization; I’ve done a lot of optimization, so I suggested to Jay Stelly that maybe I should work on Portal 2 as well. Jay said, “Yeah, you could do that, but we’ll get it shipped anyway.” After a couple of discussions like that, I realized that he was saying was that I should think about whether that was really the most valuable thing I could be doing – there were plenty of people who were skilled at optimizing the Source engine already working on Portal 2, so it would be more useful to think about what high-impact things I could do that no one else was doing.

Working on the Portal 2 engine sounds like an obvious fit: joining a great team on a highly-anticipated title, a game that would be enjoyed by some four million people while continuing the genre-defining innovation of its predecessor. But, as Abrash came to realise, his contribution wouldn’t have real impact because all that would happen anyway, without his help. His marginal impact would be minimal, maybe a slight performance improvement or a few weeks earlier ship date. That’s not making a difference.

Think of your role in our society, in our global civilisation, in the same way. We’re all in this together and we (aspirational others) share some common goals and values of improving life and furthering humanity. There are lots of exciting projects going on. It’s an amazing time to be alive. Seemingly boundless possibilities are opening up before us as our knowledge and our technology accelerate us into a future unimaginable a generation or two ago. There is a ton of buzz around some of these ideas and the companies pursuing them, and some of them, no doubt, will have huge impact.

But they’re going to have that impact anyway, whether you jump in or not. Unless you have some unique insight or perspective, a true innovation beyond the obvious consequences, or unmatched talent, your involvement would be marginal. Someone else will probably arrive at a similar insight before too long, especially in areas with a lot of attention. Even if you were highly successful, even if you dominated the market that forms, your impact would be small if someone else would have done approximately the same thing had you not been there (although it’ll be a lot easier to delude yourself about your impact if you do succeed).

The clue to look out for, the hint that maybe your impact will be marginal, is whether or not you are (or will be) in a race. If  being first to market is a significant factor in your odds of success, and there is some chance you won’t be, then you’re racing. If you’re racing and you just stop then someone else will win. And if someone else winning implies that the world sees a more or less similar outcome to that you are trying to bring anyway, then your participation isn’t making a big difference. Society doesn’t care who makes the next crowd funding platform, the next group chat app, the next ride sharing market. The good variations on those ideas will be discovered, tested and marketed by the many people motivated by money and success. If you’re racing against them, if you’re worried about being beaten to find those winning combinations, if the pressure is on to launch first, then you are not making a real difference. If you want to have real impact, if you want the world to be better because of your actions, then you need to do something different, something that other people are not doing, something where you won’t be racing to the same finish line.

Don’t confuse this warning against racing as a suggestion not to improve on existing products or ideas, as a suggestion not to do something better (as opposed to just faster). If you can solve a problem better that everyone else, that’s of real value. There’s nothing wrong with making an incremental improvement. Many products which have had huge impact over the past few years started out essentially incrementally, taking an existing idea and doing it better or differently than anyone had tried before. Where multiple social networks had failed to stick, Facebook did it better and is still growing eight years later. Everyone thought search engines were boring and a solved problem when Google set out to make the world’s best. Smartphone and tablet manufacturers could already reflect on years of failure when iOS and Android devices hit the shelves. The market had conclusively proven that no-one really needed a file synchronisation service when Dropbox decided to make one that normal humans could actually use. None of these products were racing against competitors who were producing a similar product with similar quality. Indeed, most were overturning a stagnant industry segment, upsetting a market already thought to be explored. They had real, unique differentiation and their developers had no need to race except behind their desire to bring their benefits to the world as soon as they could.

Of course, the time pressure brought by competition has many advantages: a race incentivises rapid development and release, products reach the market faster, benefits arrive sooner, and poor ideas fail before sucking up too much development effort. But the role of competitive foil is not high impact, it’s marginal. If you have high talent or insight or experience and you really want to make a difference, leave that to someone else. Alternatively, accept that that is your role for now. Accept that together with your competitors you will effect some change and that your part will be small. Understand what your impact really is when evaluating the cost to your lifestyle, your health, your relationships, and your time.

If you’re pursuing something innovative, something really new, then you shouldn’t have to race. You should be laying down the track for everyone else. If you think you do need to race, consider that if you’re right then even if you win, your marginal impact was small. Someone else would have realised the same value a little later. You might succeed in reallocating some wealth towards yourself, and that’s great as a stepping stone to higher impact later, but if you have loftier goals already then consider doing something else. If you really value changing the world, you need to change it some way that no-one else will.