On coding and timelines

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.