Entrepreneurs’ guide to profitable code

This post is about “programming from business point of view”, and it is a very dear subject to my heart. It blends both worlds that fascinates me the most: coding and business. I tried to use the minimum tech terms as possible to make it an easy read for you all. 

Profitable code, what!??

Yes, programming should be about producing an economically valid pieces of code. And it took me ages to realize this simple fact. In this post I am trying to safe you some frustration as a programmer setting up a business, or an entrepreneur managing one programmer or more in his/her startup. Just sitting on a computer to write code that solves a problem and making a sale of the final software is not always a profitable business. And the most part sit on the programmer shoulders, not the business development team. What a big claim? Well, rest assured that the following will explain in details how we, programmers, might affect the software business/or any software-dependent business in a destructive way. First, let’s dismantle the root cause of the problem: the programmer's mind:

Almost all good programmers are introverts:

It needs no psychological studies to proves this plain fact. Have you ever met any good programmer with an outgoing and extroverted personality? If you did, then congratulation you have met one of the most rare human beings on this planet. Or I doubt your judgment on his/her skills.

Introversion appeals to programmers. And introverted people get attracted to programming. It appeals to their nature. They dont need external motivation to work on their passion. They are ok with being lazy sitting doing nothing but putting plans or solving ideological challenges. They are ok with not getting another human being feedback, but they are not ok with seeing their code giving the “Errors Reported at Line #272!”.

Programmers are code-centric:

Because they are fragile inside, due to lack of outer world experiences, they tend to be code-centric. They get sensitive to one particular issue: their produced code!. They are ok to be judged, they are not ok with their code being judged. It’s their self-image/reflection. Everything evolves around their "code master-peice". 

Programmers are attached to their code:

I think we share this issue with most art-creators: musicians, painters, writers ...etc. We get attached to our code. The hardest thing to do for a programmer is to “drop out part of the code” he/she produced. It’s exactly like imputing one of your arms. Same feeling…almost. 

Programmer’s try to understand the world through logic:

That’s exactly the reason why they can’t fit with others. And it’s the same reason why they feel awkward in social circles. Programming is a logical process and it tends to draw upon logical side of the brain. And to our astonishment this world is not particularly a logical one!. And apparently logic is not the suitable tool to use to understand human behaviors. Well, programmers can’t get around that idea, at least most of the time!.

What is a profitable code:

Profitable code is any piece of code which total costs to produce is less than it’s total sales value. In ideal world if you sit for one month to produce a piece of code – ie software- and that same code is sold to a client for a $2000 – for example- while you got paid $1000 for your monthly salary, then you have produced a profitable code. Now, remember what I began my last sentence with? [In ideal world]. So that implies it’s far more difficult in real world to calculate and make a profitable code. And yes, it’s very very hard to make such thing. The reason being the nature of coding process and the code end result: hard-to-read-by-humans-piece-of-writing.

A piece of code life cycle:

Let’s go through a piece of code life cycle and see how it goes through its life stages from inception to death.

1- idea out of a problem or requirement list.

2- some code trials and debugging. [For non-technical readers: debugging is a programming term means to resolve mistakes or problems in the produced code.]

3- piece of code takes the right number and types of inputs and produce the right output.

4- All tests passed. [For non technical readers: for quality assurance, programmers test their produced code against pre-set list of requirements and standards.]

5- [working and happy piece of code] sets in a store, or a code database with some tags to easily search for it in case needed to be used in another project.

6- [working and happy piece of code] get used in the current project and makes the client happy.

<< Few months later >>

7- Another project have some similar functionality and can use some part of our [working and happy piece of code].

8- [working and happy piece of code] get used in this new project and also makes this client happy.

<<More months passes>>

9- Another project have some similar functionality and can use parts of our [working and happy piece of code].

8- [working and happy piece of code] couldnt fit exactly to the requirement, and some changes and modifications need to be done. This produced a variation of our working and happy piece of code. Let’s name it: working and happy piece of code version 2. magic?

<<a year or two passed>>

The cycle will be repeated ending up in various versions of our [working and happy piece of code], and the more versions created the harder it will be to maintain the original code. This all leads to one inevitable outcome: [working and happy piece of code] becoming very expensive to use with every cycle, which will lead to the final stage:

9- Death of the [working and happy piece of code]. By death here I mean: no longer usable, or a new alternative is needed to be coded, or another technology making this code obsolete.

How to make profitable code?

While all these tips are not new for any programmer who worked for a big corporation or on any multi- developers open source project, most small companies with one or few programmers might ignore those tips trying to speed-produce code. While applying some or all these tips might result in small decrease in code-production, they will guarantee triple or more profitability of the same produced-code.

1- Readable code:

A Lot of programmers hear about this from day one in their programming career, yet the funny part is that they rarely stick to this advise. While producing code that “runs successfully” and produce the “expected output” is something to be praised about, producing readable code that “runs successfully” and produce the “expected output” is far more important for profitability of the company. And as you have noticed, the only difference between those two sentences was “readable”.

Why?

1- Far less time is required to debug a readable code.

2- Far less time is required for another programmer to get up and running with that code.

3- Far less time is required to modify the code by same programmer or another programmer after few months/years pass from the day of code production.

So in short, code readability ensures less-expensive “maintainability” and “acquisition” of the same piece of code.

How to maintain readability of code?

Plain and simple: stick to the standards. Of course you have to learn standards first, or develop one for you and your team.

2- Well commented code:

If you stick to “readability” from point no (1), most of the time you dont need comments in your code. Yet, in some cases you still need to comment your code to help yourself/or other programmers working on the same code to understand what you mean by every code section.

3- Code History Log and Version Control:

Believe me that I’ve seen companies and government organizations with more than 10 programmers and they still dont use any version control systems!, and GIT and Subversion seemed to them like a completely out of this world tools. A version control system will ensure that all code branches and versions are kept in proper database with proper tags to be retracted any time needed. No need to waste time to figure out what you did at this copy-folder or compile the wrong version with the unresolved bugs you already solved in another version!…. Things that most of us -programmers- face on a daily basis!.

4- Proper documentation:

Proper documentation of your code and processes is crucial to high profitability of any piece of code. Always spend enough time to document your code properly. From my experience you need to spend at least 20-30% of your coding time on creating good documentation. Just think of any tool that you use daily, the main factor on selecting any tool in programming is their clear documentation. And it is the same for your produced code.

5- Extremely modular:

I like to use the phrase:”Atomic code”. Remember the word “Atom” meaning from science class in your elementary school? “Atom” means: can’t be divided any more. And that applies to your code too. If you can think of any chunk of your code as a separate piece that can be used by another part of your code or by another programmer working on another project, then it is a good candidate of “reuse”. So put it in a separate class or module or function.

6- Decoupling on every stage:

In programming world, decoupling means to make independent. And it is a good practice to produce decoupled code. It increases the life-time of the produced code, and lower its maintainability cost.

Conclusion:

While programming might be one of the most fascinating subjects for many people, producing profitable code should be the main objective for programmers setting up a business. If there’s one trick that would make your produced code increases its profitability, I would suggest being “highly readable” is that one factor. Combining all other factors will guarantee the most Return On Investment (ROI).

Hope you enjoyed this post.