Coding and creating
apps or software out of it needs time and space. It should be treated as an art
like painting , sculpting or writing a novel. By this I do not mean to compare
in the sense of the abstract or subjective nature of other art forms. But mainly
from the point of view of giving its due time to completion. Like you cannot
put a gun on some ones head and generate a great novel, you cannot do the same
with writing code also.
It is a
misunderstanding that you can have an army of people to manage and manage the
managers and generate beautiful and meaningful software products. Corporations
have people mainly to handle people or customers. But when the same thing
extends all the way to putting a gun on the head of a developer and make him
sling code, monitoring it with spreadsheets and project plans, the whole thing
loses its beauty. It is like making a beautiful painting with a team effort. I
am not again saying this in the sense that software should be developed only by
individuals. I mean it mainly that it would be beautiful to have highly skilled
and experienced individuals write good apps all by themselves if it is
possible.
Coding is not the
same as hunting. When you face a mortal enemy you need support. Or when it is
voluminous you need assistance. But coding is not about any of these. It is
about finding the most elegant and beautiful way to solve a problem using a
programming language. This is better done by a very few experienced and
skilful programmers than a group of hunters going about without a clue.
Making a team write
a software is not analogous to a conductor playing out a symphony with a
troupe. In this case the notes for each of the musician is laid out , rehearsal
is done and the conductor has got the final outcome in his head. This is not at
all the case with software developed by a team. It is probably 10% of it. A
large portion is simply chaos and unwieldy with a ball of mud after a while.
When you have just an individual coding the software who has the experience and vision of the final outcome, it becomes a lot
easier to cater to the 'ups' and 'downs' as it happens while keeping the code
still beautiful. May be there can be a few more skilled individuals working
together. But when you start to have 'projects' with a lot of people who do not
code tracking it, the coding is seen as a factory output. When? How long? Why
so much time? Why can't we cut short here? Why should we do this feature? etc.
Part of the issue
comes from the case that the person who codes do not understand the big
picture. So you need the other who understands the big picture. But he cannot
code. It is like the story of a lame guy walked around by a blind guy carrying
him on the shoulders. The lame guy keeps telling where to go or navigates and
the blind guy moves in that direction carrying him. While practicality does not
allow the luxury of a single person who has the vision and the skill to make it
happen in many situations, it should be seen at least to the extent that the
vision and the timelines to achieve it should in no way compromise on the
elegant nature of the code. In fact, part of the vision should be to 'also produce an
elegant code'. Having a manageable, readable and clean code is like half the
distance crossed already in your effort to build a product. A well written code
saves a lot of time when you start to scale in terms of features down the line.
Iterative nature of
adding features is good, but the iterations of coding should be done in such a
way that one builds over the other easily. It should not be a thoughtless ,
hurried release and then throw away to do the next.
The best coders use
less code to achieve more. DRY (Don't Repeat Yourself) principle is of utmost
importance. When you can write code in a way majority of your features are
resting on few building blocks which in turn rest on even more fundamental
blocks of code, it is a clean construction. You can communicate your code very
easily to others. Human brains operate on abstraction. When large parts of your
code can be abstracted to some usable, easy to remember function it becomes
very easy to get the picture and the flow. And further dissection can be done
cleanly into smaller parts, it is a delight to maintain, enhance and operate a
piece of software.
Writing bad code and
getting a market share for your software is like conquering new territories in
the colonial era only to leave them soon. You better not do it.
