Your Code Base is Your Book

Medieval scribe by Jean Miélot

Many software projects are needy: needy of documentation, of conventions and tests. These needs often reflect problems with the organization such as faulty management, weak specifications and bad communication.

Insolvent projects often start with a new product request with negligent definitions and “flexible” (1) deadlines, from the clients and weak discipline, from the developers.

When those projects are in the middle of their development, things begin to go wrong and desperation assaults everybody. The project is, for a long time, being developed without proper testing and observation. You’ve come to a phase where it is hard to add a feature, for instance. You’re not confident to your code any more, instead, you are afraid of it.

So when things are like that, everybody starts to feel discouraged. You feel no enthusiasm for coming to the office and running that project. Well then you, for one, must say: that’s enough.

I suggest that we developers face our code as books. Just like novelists do. The process of writing a fiction, for example, is very complicated (as complicated as writing software). And being a fiction does not mean the book should not be convincing with its characters and scenarios, after all the reader should feel confident to your book (just like you should to your code).

In the writing process, the novelist spends a lot of time trying to eliminate incongruences. In Software we want that too and in our case, we must always write code as if it is going to last forever and be maintained by a lot of different teams. So, more than novelists, programmers must be careful to write consistent code because it not only will exist for a long time, but will also be maintained like that.

Also, a novelist will write a book to have it published. It can’t be bad or it will ruin his reputation. Similarly, your program can’t break when the user is about to finish a purchase or a medical equipment is being saved to the database. You are the primary and ultimate owner of your book, say, code. You name is in it, be attentive. If you do bad things, you’ll some times find yourself barely able to work around your problems.

This approach to your job helps you see your code as an artistical work. Artists get recognized for their work in their lifes and after they die, too. A great programmer creates good software and is recognized and recompensed for his competence. He is remembered and further exist as inspiration to others.

Being attentive is far more difficult than being negligent. But it is also nobler.

Romancists (talking about the best ones here) want to write only in the best imaginable way to avoid getting disappointed during the writing. So should you developer. It is really bad when, because of negligence, you come to the point where you are no longer unwillingly working in a project.

You and your team are like a writer and her editor’s staff in a way: you’re all together to develop and deliver something. Do your best to develop the software and your team will be eager to help you in the process.

I’ve been in a project like that, which for wasn’t planned or developed like that and after 10 months no one enjoyed working on it anymore. Everyone started the week wishing for friday to come sooner. Everyone was exhausted and bored.

I’ve seen projects built this way. You develop something without compromise to quality and maintenability, because you’re in a hurry/your boss is going crazy/no one cares/the customer wouldn’t mind about our awful code. Believe me, this is the path leading to demotivation in Software Development. Someone will always suffer the consequences of bad written code.

I believe that your software is a reflection not only of your profissionalism but of your passion, too. The best teams ship the best products. It happens when individuals are honestly commited to the development of something really useful, something some people will enjoy having.

Whenever you’re in an ill project do yourself a favor and think like a novelist. Ask yourself: “Am I really going to publish this?” and “Can’t I do it better?”. In a bad project you’ll likely answer: No and Yes, respectively. You will see that it is much better (although much harder) to do things the right way. Satisfaction is all about commitment. Your code base is your book, have it well done and have it published.

(1), By flexible, I mean projects whose owners aren't compromised enough to really follow the deadlines who often extend the deadline, augmenting costs and decresing efficiency and agility.