I've been a software developer for close to 20 years so I thought I'd share some thoughts that might be of interest to fellow Fastlaners looking to get into the software business.
Running a business based on software requires a correct perspective. Failing to do so can be deadly to such a business. One of the main factors that must be managed correctly is technical debt. I'll expand more on the concept of technical debt later.
What is a business that relies on software? It's a business whose core product either is the software itself or it relies heavily on its *own* software. Such a business develops this software in-house and does not rely on an external supplier. Examples of core software is either shrink wrapped (ex Microsoft Office), software as a service (SaaS) such as AWS (Amazon Web Services). An example of non-core software is a company web site that is just the company's web presence and nothing more.
There are two divergent views on developing and maintaining such software in such a company:
* Businessmen: Get the software out there as quickly as possible and start making money.
* Techies: Software must be architected, designed, developed, tested and deployed carefully.
The first school of thought involves the old adage that time is money. If a company doesn't release its product on time and start making money, then its business is threatened. Perfect is the enemy of the good. Lots of rock-solid businesses have been built on mediocre code that was good enough.
The second school of thought is that software is inherently complex. Such complexity can result in dire consequences for a given business if not managed correctly. One extreme example is a software bug that accidentally deletes customer data under a specific software use scenario. Furthermore, software evolves over time. Software that is not correctly designed can not only become progressively buggier over time, but become more difficult to add new features to. Additionally, certain software libraries and frameworks used by the software can become obsolete over time. They need to be updated and if those inevitable updates are put off, they can cost more the longer they're delayed.
This alludes to the concept of technical debt. Technical debt, like financial debt, is used to fund a business. Similar to financial debt, accumulating technical debt can fuel massive early expansion. Also similar to financial debt, a large amount of technical debt can result in interest payments to service it. These technical debt interest payments take the form of:
1) An increasing rate of newly discovered bugs in the software
2) An increasing rate of difficulty in developing new features on top of the shaky software foundation, and each new feature leading to more of 1)
3) As more software developers leave the company over time, new developers must climb the steep learning curve of understanding how software domain and codebase
Also similar to financial debt, repaying part of the debt leads to lower interest payments. These repayments take the form of overhauling or redesigning the software to remove part of the technical debt. This eliminates some long-standing bugs and makes subsequent development of new features easier.
So what's the right answer? Well, the astute business owner needs to balance the need for rapid expansion with software maintainability. A startup, especially one with at most three employees, doesn't have the luxury of designing software perfectly. You need to get your product out there and start making money. Shortcuts, even shortcuts requested by a single client, can mean the difference between the life or death of the business. Still, another consideration is what will happen years later when it comes time to sell the company to a larger competitor. Will the accumulated technical debt become a consideration when setting the sale price of the company? Might a large enough technical debt make the company unattractive altogether?
There is a strategy to deal with this. It's developing the 2.0 version of the software. At one point in its history, a software company could rewrite its software product completely in a way that removes the debt. All the best features, as well as the failures and mistakes, associated with the current product are catalogued into requirements for the rewritten product. The benefits are a more maintainable product that has a stronger foundation to add new features. The risks are that the original unwritten requirements were misunderstood and customers are no longer served correctly as they were before. Furthermore, the company could eventually lose the will to devote so many resources given the inevitable delays and missed deadlines.
Some 2.0 products have succeeded. Many more have failed. An example of a failure is Copland, Apple's 1990's failed attempt to replace MacOS Classic: the Mac's first ever operating system. Apple had to kill the project because of bad execution. On the other hand, Mac OS X eventually succeeded in replacing MacOS Classic, and is still the Mac operating system to this day.
So my advice to any of you starting a software business is to take the above factors into consideration and find the right balance based on your judgment and assessment of the specific situation.
Running a business based on software requires a correct perspective. Failing to do so can be deadly to such a business. One of the main factors that must be managed correctly is technical debt. I'll expand more on the concept of technical debt later.
What is a business that relies on software? It's a business whose core product either is the software itself or it relies heavily on its *own* software. Such a business develops this software in-house and does not rely on an external supplier. Examples of core software is either shrink wrapped (ex Microsoft Office), software as a service (SaaS) such as AWS (Amazon Web Services). An example of non-core software is a company web site that is just the company's web presence and nothing more.
There are two divergent views on developing and maintaining such software in such a company:
* Businessmen: Get the software out there as quickly as possible and start making money.
* Techies: Software must be architected, designed, developed, tested and deployed carefully.
The first school of thought involves the old adage that time is money. If a company doesn't release its product on time and start making money, then its business is threatened. Perfect is the enemy of the good. Lots of rock-solid businesses have been built on mediocre code that was good enough.
The second school of thought is that software is inherently complex. Such complexity can result in dire consequences for a given business if not managed correctly. One extreme example is a software bug that accidentally deletes customer data under a specific software use scenario. Furthermore, software evolves over time. Software that is not correctly designed can not only become progressively buggier over time, but become more difficult to add new features to. Additionally, certain software libraries and frameworks used by the software can become obsolete over time. They need to be updated and if those inevitable updates are put off, they can cost more the longer they're delayed.
This alludes to the concept of technical debt. Technical debt, like financial debt, is used to fund a business. Similar to financial debt, accumulating technical debt can fuel massive early expansion. Also similar to financial debt, a large amount of technical debt can result in interest payments to service it. These technical debt interest payments take the form of:
1) An increasing rate of newly discovered bugs in the software
2) An increasing rate of difficulty in developing new features on top of the shaky software foundation, and each new feature leading to more of 1)
3) As more software developers leave the company over time, new developers must climb the steep learning curve of understanding how software domain and codebase
Also similar to financial debt, repaying part of the debt leads to lower interest payments. These repayments take the form of overhauling or redesigning the software to remove part of the technical debt. This eliminates some long-standing bugs and makes subsequent development of new features easier.
So what's the right answer? Well, the astute business owner needs to balance the need for rapid expansion with software maintainability. A startup, especially one with at most three employees, doesn't have the luxury of designing software perfectly. You need to get your product out there and start making money. Shortcuts, even shortcuts requested by a single client, can mean the difference between the life or death of the business. Still, another consideration is what will happen years later when it comes time to sell the company to a larger competitor. Will the accumulated technical debt become a consideration when setting the sale price of the company? Might a large enough technical debt make the company unattractive altogether?
There is a strategy to deal with this. It's developing the 2.0 version of the software. At one point in its history, a software company could rewrite its software product completely in a way that removes the debt. All the best features, as well as the failures and mistakes, associated with the current product are catalogued into requirements for the rewritten product. The benefits are a more maintainable product that has a stronger foundation to add new features. The risks are that the original unwritten requirements were misunderstood and customers are no longer served correctly as they were before. Furthermore, the company could eventually lose the will to devote so many resources given the inevitable delays and missed deadlines.
Some 2.0 products have succeeded. Many more have failed. An example of a failure is Copland, Apple's 1990's failed attempt to replace MacOS Classic: the Mac's first ever operating system. Apple had to kill the project because of bad execution. On the other hand, Mac OS X eventually succeeded in replacing MacOS Classic, and is still the Mac operating system to this day.
So my advice to any of you starting a software business is to take the above factors into consideration and find the right balance based on your judgment and assessment of the specific situation.
Dislike ads? Remove them and support the forum:
Subscribe to Fastlane Insiders.
