When I talk about programming or teach in a workshop, I keep repeating one
motto: Try to keep things simple. Whenever I looked at the modern complex
systems which are popular among the users, generally they are many simple tools
working together solving a complex problem.
The Unix philosophy
Back in college days, I read about the Unix
philosophy. It is a set of
ideas and philosophical approaches to the software development. From the
Wikipedia page, we can find four points.
- Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”.
- Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
- Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
- Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.
Do one thing
The first point is something many people decide to skip. The idea of a perfect
system which can do everything leads to a complex over engineered software
which takes many years to land in production. The first causality is the user
of the system, then the team who has to maintain the system up & running. A
simple system with proper documentation also attracts number of users. These
first users also become your community. They try out the new features, provide
valuable feedback. If you are working on an Open Source project, creating that
community around your project is always important for the sustainability of the
Pipe and redirection between tools
Piping and redirection in Linux shells were another simple magic I learned
during the early days in college. How a tool like grep can take the input
stream and provide an output, which in turn can be used in the next tool, was
one of the best thing I found in the terminal. As a developer, I spend a lot of
time in the terminals, and we use piping and redirection in daily life many
Build and try and repeat
I think all of the modern agile followers know this point very well. Unless you
are allowing your users to try out your tool and allow them to provide
feedback, your tool will not be welcomed by the users. We, the programmers have
this attitude that every problem can be solved by code, and our ideas are
always the correct. No, that is not the case at all. Go out in the world, show
your tool to as many people as possible, take feedback. Rewrite and rebuild
your tool as required. If you wait for 3 years and hope that someone will force
your tool to the users, that will not go well in long run.
Do One Thing and Do It Well
The whole idea of Do One Thing and Do It Well has been discussed many times.
Search the term in your favorite search engine, and you will surely find many
documents explaining the idea in details. Following this idea while designing
tools or systems helped me till date. Tunir or
gotun tried to follow the same ideas as much as
possible. They are build to execute some command on a remote system and act
accordingly to the exit codes. I think this is the one line description of both
the tools. To verify if the tool is simple or not, I keep throwing the tool to
the new users and go through the feedback.
Last night we received a mail from Dusty Mabe in the
to test the updates-testing tree for Fedora Atomic. At the end of the email, he
also gave the command to execute to rebase to the updates-testing tree.
# rpm-ostree rebase fedora-atomic/25/x86_64/testing/docker-host
With that as input from upstream, it was just adding the command in one line on
top of the current official Fedora
tests, and followed by a reboot command and wait for the machine to come back
sudo rpm-ostree rebase fedora-atomic/25/x86_64/testing/docker-host @@ sudo reboot SLEEP 120 curl -O http://infrastructure.fedoraproject.org/infra/autocloud/tunirtests.tar.gz tar -xzvf tunirtests.tar.gz ...
This helped me to find the
regression in atomic
command within the next few minutes while I was working on something else. As I
reported the issue to the upstream, they are already working to find a solution
(some discussion here). The
simplicity of the tool helped me to get things done faster in this case.
Please let me know what do you think about this particular idea about designing
software in the comments below.