Growing Software Tools25 January 2016
For a major part of our career as designers, we dedicated our
time towards designing visual interfaces. We worked with dozens of
teams over half a decade designing UIs and if time and budget
permitted, we illustrated it’s workings with an interactive
prototype. When it was time to turn these visual artifacts into a
usable product, we would handoff our work to developers’ hands and
a pretty interesting process unfolds.
After some iterative development cycles and much back and forth,
the result would range somewhere between outright unusable mess to
delightful products. Delightful products were almost always a
result of great engineering and insightful business planning but
failed ones resulted from a myriad of reasons ★1: due to
miscommunication, lack of understanding of the domain,
misalignment with business goals, and so on.
Both of these outcomes, resentment resulting from inferior
products and curiousity at how the proficient engineer brings
about delightful software impelled us to learn the craft of
software engineering and thus enabling us to be fully accountable
for our creation. Thus about 4 years ago, we decided to learn how
to program a computer.
There were moments of joy, frustration, and glimmers
of enlightenment before the next problem brought us to a grinding
halt in this journey. Some of these experiences lead to a clear
view of the lay of land allowing us to solve certain problems but
most aspects of how to overcome failures on our way to build
robust systems remain elusive. Looking back at our past
experiences and drawing inspiration from a range of domains, here
we try to distill an outline of our approach towards our next
2 / Computer is a Construct
Computer lends itself to be
shaped into a multitude of models. Alan Kay
identified computers as the first meta-medium
— that it could incorporate all other media★2. This “protean” nature
of computers means that it could be anything it is
shaped to be. But this flexibility comes with a
consequence: what the computer has come to resemble
at this point is nothing but one realization
amongst many it can be. What it is now, is a
resultant of thrusts from various fronts that have
been exerted over the course of it's history.
A recurring observation in our
exploration is that in this tug of war, a lot of what got adopted were
imagined and implemented at a time a lot different than ours. Our current
technological and mental models originated at a time when hardware had
many practical limitations, a different knowledge context than ours,
and certainly a very different audience for computing. Many
interesting ideas of yore that were abandoned and can now seen to be
resurfacing ★3 in
Computer Science since the technology and people around it are
becoming more favourable for them to flourish.
An understanding of history is crucial towards understanding any
technology. A lot of concepts in programming has a long backlog behind
them. In order to understand why a certain technology is used in a
problem space, it is crucial to understand it’s historical
trajectory. A great many lessons can be learnt by examining these
ideas (and their predecessors) and the philosophy possesed by the minds behind them.
A large part of our undertaking in building
software systems is to dedicate ourselves to unravel the towers of
abstractions before us and to investigate ones that have
disappeared. We hope it will lead us to a coherent view of
computer science, the lack of which we faced first hand when we
We have always had immense respect for the people
who build products drawing experience from their diverse
backgrounds; the ones who have their creative vision expressed
over all aspects of their creations. One such niche where small
groups of people with multidisciplinary backgrounds expressing
their software craftsmanship is the Demoscene. The idea is to
build a so-called “demo” which is an tiny program
limited to kilobytes in size that executes to generate an
audio-visual world. Even within it’s tiny confines, the
creativity expressed by the artists knows no bounds ★4.
One exceptional talent who we have come across in our journey is
Charles Moore. He is responsible for building not only his own
programming language called Forth, but went on to design the
hardware to run it on (he designed this in a software written in
his own language!) . He not only has an astounding array of systems
he has built in his life but also has an pretty interesting
philosophy driving in his work ★5 that is derived from deeply
understanding the machine.
This joy of learning about new things from diverse backgrounds is
one of our primary drives. It grants an opportunity to have more
than one perspective towards product making. It facilitates taking
apart the elements of computing and putting them together to
create novel combinations. We have felt that this exposure to a
wide variety of domains, not only guides us in new creations, but
also helps to develop an authentic style.
This of course comes with the cost of having to split your
time and mode of thinking between abstract nature of software
logic and subjective cultural symbols for expressing it. But if we
could successfully sythensize software in this manner, all the
components of the software would have a sort of coherence
displayed across it’s marrow and joints.
It’s not just intellectual gratification
and authenticity that inform our approach but also an
overarching idea of creating an ecosystem of software. The
metaphor we have adopted to see our ventures collectively is
by understanding them as a farm. As rightly revealed by the
metaphor, some of our products will emerge from cross
polination of ideas, are prone to wither on the wine, and
most importantly will need constant maintenance. It’s the
slow and steady work leading to fruition over a long period
of time that we wish to remind us with this metaphor ★6.
This in operational terms means creating applications that
interoperate with each other. My undergraduate thesis was on
creating a software ecosystem for students. Though I had ambitious
goals with the project, the progress made over an year was pretty
meagre. Eventhough from whatever headway I could make, I was able
to see how enriching such an ecosystem of applications could be.
What we have in our minds, is a
software suite that works as an ecosystem sharing their data in
visible ways. Time tracked in your project management application coming up in your
calculator. A calculation done on it piped in to your note taking
application and so on. In this way, each application in the
setting would be enriching to the other ★7. This is
obviously not a new idea, but so far, we have only seen such
system of applications expressed with limited patency.
5 / Wonder ➝ Blunder ➝ Refactor ➝ Repeat
Nature of software is something that has kept us wondering. From
what we could gather, software building stands at the cross section
of logic, engineering and human psychology: math, machine, and
man. Software is a tool that is borne by shaping our thought in to
the machine which inturn results in shaping our behaviour. This
means that when developing software we need to take these factors
into account in our feedback loop. That is the code should be
correct, performant, and understandable.
We admit that we only have an inkling on how to
go about implementing any of the systems that we have envisioned.
But we are going forward because no decision or tool made at the
end of the day is perfect. It seems like a reasonable decision
since we are in the infancy of understanding these systems and it
still gives us a kick to explore new things in programming. We
will be constantly trying to refine our approach as we go forward
and trying our hands at different things to gain more experience ★8. There’s so much more left to learn and practice.
Software has a unique characteristic that lends
itself to make it better. Known as refactoring, it is the practice
of making the code better in small transformative steps which
allows for better management of it’s complexity. It is much like
how constant rewriting leads to better writing. This practice of
code reorganization leads to a better understanding of the code
and many a time unearths bugs which would be tough to spot
Seymour Papert in his seminal work, Mindstorms
borrows the concept of debugging from Computer Science and applies
this notion to epistemology. He eloquently writes ★9
on how your brain can be debugged of it’s misconceptions and
incorrect intuitions. Our learning theory is based on this idea
that you can debug your own thinking by refactoring your mental
models. It’s a very empowering notion to adopt for it enables new
ways of seeing.
Don’t feel as if the key to successful computing is only in
your hands. What’s in your hands, I think and hope, is
intelligence: the ability to see the machine as more than when you
were first led up to it, that you can make it more.Alan Perlis
With this vision, we are choosing to first
build small systems of our own and use them in helping us carry
out our daily activities. We have tentatively titled them as
Decent Tools. Although, the bigger projects that we have
envisioned under this idea are ones that we think we will come to
their full fruition only 5 years down the lane or so. We are only
at the stage of taking baby steps converging towards this goal.
It’s simply because of time required to understand and
explore breadth and history of these areas that we have
identified. They warrant thorough exploration to come up with
Our intent is to stay small, create
products that can fit both of our minds and use this as a
constraint towards assembling this ecosystem. But this approach we
have been outlining so far is by no means to be taken up as a
principle set in stone for we are iterating as much on our
approach as we are involved in building our software tools. If
anything, it’s only a rough sketch outlining our vector of
progress; an in medias res peek at our evolving philosophy.
A lot of planning and a few prototypes have
been done in past years which have strengthened our current
view. But it remains to be seen if it would continue standing the
test of time. We will be constantly putting it under scrutiny for
determining it's fruitfulness as an approach towards growing
So here's a start to our journey, setting sail
towards unseen shores.
April 1, 1922 - February 7, 1990
Known for his pioneering work in programming languages and to an wider audience through his epigrams on Programming. Received the first ACM Turing Award for excellence in Computer Science.
Born: October 4, 1936
One of the most important architects of 20th Century who influenced a wide range of domains with his work. Even with having read only his Notes on Synthesis of Form we plan to soon follow up on this with his other books.
Born: February 29, 1928
Mathematician reknown for his work in AI, learning theories, and for building educational programming language LOGO for children.
Born: September 1938
Charles Moore is best known for his invention of Forth, a stack based programming language that has even found its applications in NASA's space mission. He has an incisive view on Computer Science that cuts across all boundaries and is explicit in his language design.
Born: May 17, 1940
Originated Object Oriented Programming and Window based GUIs at Xerox PARC. His writings and talks distill knowledge from vast variety of domains into overarching narratives. Be sure to watch at least one of his talks. We recommend Normal Considered Harmful for starters. Drawing Courtesy: Jack Shaedler.
Born: July 12, 1977
Explorer of new ways of thinking with Computers. His showcased work and writing at his website are treasure troves for software designers.
Born: July 12, 1977
Karsten Schmidt is a creative coder who merges art, code, and music in his creative explorations. He had his early roots in the 8-bit demoscene and has been actively designing audio-visual experiences under his banner, Post Spectacular.
Born: August 20, 1970
Pioneered many 3D game techniques in popular games by him such as Doom and Wolfenstein that were major stepping stones towards the current gaming scene. He now works at Oculus bringing VR to the world.
A Demogroup dedicated towards consistently churning out high quality demos.
A series of vignettes on human-technology interaction. Jointly written by Sep Kamvar and Jonathan Harris.
Research group aimed at inventing new ways of thinking with Computer. Recruited by the group comprises of Vi Hart, Toby Schachman and many more talented people.
Great treatise on how to solve complex design
problems and create forms that exhibit good fit with their context.
Highly recommended read to any problem solver.
Seymour Papert’s work on designing programming environments that foster learning and exploration.
A great read to that opened up our world to philosophy of learning.
Alan Kay's thoughts on Computer Software that appeared in the Scientific American.
An autobiographic post by visual artist Karsten Schmidt. He looks back on his journey that spans bare metal programming, demoscene, programming languages and many more.
Internal lecture given by John Carmack at Facebook.
Bret Victor's look at some of the rich ideas from the past that
never made it mainstream. He also gives an analyzes the context that
lead to the germination of these ideas.
Mercury's fascinating demo. Captivating shape transformations with on-key music.
If you any have comments, feedback or kudos on this post, we would love to hear it.