Tag Archives: Software

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 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 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.

Railcorp, you have a problem

Well, duh.

I think everyone knows you have a problem. Possibly even yourselves. Trains continually run late or are cancelled. The network clogs up causing follow-on delays. Even after degrading performance with a lower-throughput timetable you struggle to meet performance objectives (weak ones, too: eleven out of twelve trains arriving within 5 minutes of schedule). Even this reported performance is artificially high since large segments of the infrastructure are out of service every weekend and not counted. Trackwork is such a likely event that it’s the third most prominent link on the CityRail website, trailing only Home and Timetables.

But these aren’t the problem. These are merely symptoms of your problem. Your problem is best illustrated by your careers page. Or what’s not on your careers page. Apparently you have no need for anyone to work on scheduling, programming and optimisation of the CityRail network. This is clearly a ridiculously hard problem but it seems you don’t want anyone to help you solve it. I can see a couple of possible reasons for this, but they all mean you’re doing something wrong.

Perhaps you think the problem is solved, that what you have is good enough and the problems lie elsewhere. Um, no. I really hope you’re not that blind. You have scheduling problems.

Possibly you already have people employed in these roles. They’ve probably been at CityRail for a long time having moved up from being a station master or locomotive engineer or something equally irrelevant but are deeply familiar with the network etc. etc. Well, it appears that they suck, or have been promoted outside their competence, or just don’t care any more.

Maybe you bought some software from a better rail corporation elsewhere in the world, and you plugged in your network and requirements and out popped the current plan. Wait, so you’re telling me that no-one at RailCorp actually knows how the schedule is created? Please, please let this not be the case. You need to have this knowledge yourselves.

More likely you outsourced the planning and scheduling to some other company. If it was a big consulting firm, we are doomed. But in any case, you probably outsourced it to a team with no idea about rail networks, particularly the myriad complexities of Sydney’s. I’m sure you provided very detailed requirements and they might even have given you exactly what you asked for, but it still sucks. They don’t understand rail. It’s hard! And now whenever you want something changed you need to go back and write a detailed specification and open up the taxpayers’ chequebook and you already forked out millions up front and you’re running a tight budget so really it’s easier just to let it keep sucking.

RailCorp, you need to solve this problem yourselves, and you need to do it with the right people. You need to solve this problem yourselves, build an in-house rail planning and scheduling system, because the problem is really hard and depends crucially on details of Sydney’s particular infrastructure and requirements. You can’t just buy software from someone else. It will have been built with an entirely different set of assumptions, and it won’t work. You can’t outsource it. You already have the complex, detailed domain knowledge from running (barely) the network. You can’t effectively transfer that to another organisation. And the situation will change continually and you need to be able to react, fast.

You need to keep the knowledge of how the network is programmed, and how to create that program, internal. It needs to reside in the collective mind of your employees. The people with the responsibility for an efficient train network need to also have the knowledge and authority required to make it efficient. You can’t pass the buck — it’ll just end up on the floor and you’ll be bending down to pick it up when something … unfortunate happens.

But I have some good news. The people you need exist. In Sydney (and everywhere else). You need people who enjoy solving problems like this. People who get more enthusiastic the harder the problem is, the more complexities and special cases there are to be encompassed by an elusive elegant solution. People who will think about the problem constantly, never resting until they reach a perfect solution (which they never will), but who will reach a really really good solution with imperfections you won’t even notice.

These people are commonly known as computer programmers. Programmers have wet dreams about problems like this. They are hard-problem otaku. There is nothing to match the challenge of a problem like this, the complexities, the endless possibilities. Along with routing road traffic, programming a rail network is one of those problems that many programmers secretly long to attack but don’t have the physical network to try it out on. Good programmers dig a problem like this, and will work tirelessly to create an efficient, elegant and practical solution to it for the sheer joy.

Not just any programmers, of course. Many programmers suck. They’re probably the ones employed by the consulting firms you outsource to. That’s right, you pay a premium to use the crappy programmers who went to work at PWC or IBM because they couldn’t get a better job. You have a better job, potentially, and you need the best programmers to work on it. Perhaps the top 3% of computer science grads would be suitable. Maybe even the top 1%. But they would nail this problem.

You’ll have to do things a little differently though. For a start you need to employ only the very best, which seems counter to the way most government-related organisations work. It might take a while to find them, but you can’t just hire people who are capable, you need people who are brilliant. Luckily for you, they would go crazy for a chance to solve your problems. You’ll need to pay them too. What they’re worth, which is a lot. There are other jobs with challenging problems too, so you need to pay them commensurately or you won’t be taken seriously.

You won’t need many of them though. A team of five, with a great leader and great equipment, should set you back less than $1m a year. Give them what they want (responsibility, authority, freedom, time) and they will solve your problem. Not only solve it, they’ll give you the tools to solve it repeatedly and better. And the knowledge of how to solve it — why the solution works, on what assumptions it rests, its robustness and sensitivities — will be within RailCorp. The experts will be right there with you, and they will take responsibility for what they create.


I’m not particularly optimistic that you’ll ever do something like this. It’s too different to how you’ve worked for the past couple of decades. It might actually work. It probably requires some massive change at the top for you to grow the balls required to do this. No doubt the incumbent management would see all sorts of problems with a plan like this, and it’s not like I personally have deep rail experience. The NSW RTA have the right idea though. Their locally-developed SCATS traffic control system is effective and has been sold to some 80 cities worldwide (brochure). Take a leaf from their book.

In any case, this idea has one definite thing going for it – you’re not doing it now, and what you’re doing now sucks.