Software products start out as great ideas. However, many of them get arrested in an invisible chasm and cannot see the light of the day. It wastes not only the time and money invested but also the opportunity. It is therefore important, especially for entrepreneurs who own a product or who aspire to own one, to understand this chasm.
Readers may have come across the great book “Crossing the Chasm” by Geoffrey Moore. It makes new companies aware of a chasm where they may get stuck. Similarly, a chasm exists for new software product development too, although its nature is quite different. The latter is covered in this article.
This is a 2 part article. This first part builds this awareness and lists the patterns. From the patterns, it then derives advice that needs to be followed. In the sequel of the article, soon to come, we shall see some powerful strategies followed by Acism.
Here is an infamous storyline:
- A business owner hires a software developer (or a small team of developers) to create a product.
- Everything is fine initially. Some minor problems start surfacing occasionally.
- The original developer quits one fine day.
- The owner finds it surprisingly difficult and expensive to take the product ahead.
This script is oft repeated in real life. (See the stories below.) Most of the times, the owner gives up at this stage or postpones it indefinitely (which is probably another name for the same).
Here are some true stories, omitting the real names and identifiable details:
A school got a developer to develop a custom school management system for them. It was a client-server desktop application. After a while, the developer took up a job in a well-known software company, and the school started looking for someone to take it ahead. All the various modules (student, classes, fees, library etc) were already in place, and the school just needed a few bugs fixed. On further dialog, the staff admitted that in spite of the system being in place, it could not be used. They maintained a parallel muster and worked off it. Clearly, there were severe issues — right from the way the requirements were analysed and designed.
Here is something that many will find hilarious: Every dialog, every frame in the application had the same title — the name of the developer’s company. I am sure the developer must have meant it as a branding opportunity for their company. But I was wondering how they would communicate any instructions — “In the R Systems frame, click the Add button and it will open the R System dialog. Then click the arrow in front of a record and that will bring another R Systems dialog. If there is any error, it will bring up yet another R Systems dialog.” What the hell?
A large US based corporate was in the process of changing the vendor doing the maintenance and further enhancements of their software systems. It turned out that the only installation of the system that was working was the production environment. No one knew or cared about setting up a development environment. Any changes that were needed were directly pushed to production.
An American employee, Robert, was also getting the KT (knowledge transfer) of the system. When he heard my bewilderment over lacking such simple best practices, Robert said, “Don’t worry. These problems mean job security for us!”
A business owner has got a set of web applications and mobile apps developed. He has a track record of conceptualizing products that become commercially successful. The development was done by a small company well-known to the owner. “After all, who is more trustworthy than the people one has already known for years?” he must have thought. The vendor company was a small team. After a couple of years of slow development, the developers left the company and the work came to a halt.
A fleeting KT is all that the new vendor got from the earlier vendor, as the old developers were already gone. There is zero documentation. As per the cover story, the system was already tested and just 4-5 small bugs needed a fix before the system could be deployed to production. However, under the hood, there were many problems, painfully coming forth one after the other. They could have been easily found if some serious testing was really done.
Adoption of Best Practices
There are well-known best practices that can take care of many common problems.
The Capability Maturity Model Integration (CMMI) formalizes the adoption of best practices in the organizational processes. They assess and certify organizations in terms of their maturity levels. Most small organizations cannot afford the certification though. Beyond this process maturity, there is programming maturity. Unfortunately, it is not easy to measure.
However, without getting into complexities, let’s note that some best practices are quite basic. For example, take the practice of version-controlling your code, that of creating different environments, or taking periodic back-up of production data. They are so basic that one hardly talks about them.
Yet, this basic hygiene is missing many times. That lowers the immunity of the system, and problems are just waiting to happen. An innocent “oops” can make the production system fail, and your telephone starts ringing with angry customers on the other end. While attending the phone, you are praying and hoping that the problem is recoverable.
Why should any business owner ever have to deal with such nonsense, when the solutions are available and well-known?
Some common patterns emerge from such stories:
Choosing Software Developers
Most of these business owners are not from the IT background, and do not understand the nuances. Nor do they have the patience to understand those. They cannot assess the maturity of developers. They also make the mistake of underestimating the software development part. (Many non-IT founders have often stated that software development is commoditized. You just get a quote, pay the money and it gets built. Alas! It is not that much simple — at least not yet. Why would the rate of failure of software projects as high as 70% if that were the case?) With no qualitative evaluation, they usually gravitate towards the cheapest bidder.
Not Keeping Tab on the Progress
Most business owners are good people. Good people like to assume that other people are also good. They trust the developers blindly, without any guards of their own. They are also busy with other stuff. Especially, if they are small time entrepreneur, there are many things vying for their attention and it is easy to get lost within the juggernaut. Keeping tab on the development progress means extra work. It is far easier for them to just hand over the requirements and leave them alone to implement those.
The sooner one can start following the best practices, the better it is for the product. Thus, it is best that you spend some effort in setting them right at this stage. If they best practices are not followed, the problems are bound to happen sooner or later. However, the symptoms start manifesting in early phases itself, if one is sensitive. Initially, they are small and can be kept under control when the systems are small, and because the original developer knows the system.
Ignoring the Symptoms
The original developers keep ignoring the symptoms as long as they can be kept under the hood. The best practices need some set-up, after all. They would rather develop a screen and earn brownie points with the business owner, than to do that. Especially when they afford it less and less to work at the cheap rates they quoted to get the work, they would try to save any time and cut corners as much as possible. Some times it is also the skill issue that they genuinely do not understand these best practices.
Problems on the Rise
With the system growing, the problems also start growing. It becomes increasingly demanding to keep troubleshooting them. This is when the developers get bored of the strenuous and repetitive work, and start looking for greener pastures.
Original Developer Quits
When they quit, they leave it in a bad shape for the next developer to take over. There is no adequate documentation, nor is there an adequate knowledge transfer. Business owner is still unaware of the actual problems, and buys into the story that the system is ready overall, except for a few simple issues. (This cover story is convenient for the business owner as well.) The business owner starts looking for a new developer (or a team) to take it over and continue.
New Developer Faces Challenges
Most smart developers are reluctant to take over the code developed by someone else. That’s why the business owner is lucky if they find a good developer to own the system at this stage. If not, then it is the end of the product there itself.
What makes the developers reluctant? Oh, there are good reasons. Firstly, every individual’s thought patterns are different and that makes it difficult to understand the code written by someone else. In addition, the unknown code could open a Pandora’s box in terms of unknown issues and blatant disregard of best practices. Worse, the business owner thinks that the issues are few and easy to fix, and wonders why the new developer takes so much time over every one of them whereas the original developer could have solved it in no time. The new developer is now responsible for the product along with all inherited problems, and are seen as unproductive for no fault of theirs.
Because of their unfamiliarity with the system, the new developer is scared to take bold reforms with the code, and the basic issues remain unaddressed. The development proceeds at a snail’s pace. Urgent production issues become a regular feature, and that stretches everyone — not just the developer and the business owner but the early customers as well. By this time the system has become quite complex, and no one knows how to make the situation better. The new developer’s productivity gradually improves because of the time that they spent with the code. But by this time they have already started looking for other opportunities… and the story repeats.
Because of the continuous problems, customers start losing interest. Somewhere the owner loses interest too, and the product gets lost in the chasm — forever.
The Way Out
The patterns provide us hints of what could help solve the problems:
- As a business owner, however busy you are, understanding some basics of the product development is essential. Do not engage a developer just because they are the cheapest. Make sure you understand their value proposition and are okay with them. Find time to review the progress. Set periodic meeting with the developer to review the progress. As far as possible, insist on seeing a demo of the product in the making. Click here to check our new year resolutions for customers.
- As a solo developer, your responsibility extends beyond coding. If you do not understand the best practices then you are not a complete developer. You should also take the necessary steps for the longevity of the product, that it should be easy to take forward for someone else beyond yourself. Part of your responsibility is to educate the owner on the essentials. Click here to check out our new year resolutions for software vendors.
- As a developer who is asked to take over a codebase written by someone else, you need to check the basic hygiene, or else life can become quite tough for you soon. You need to communicate adequately and timely. Do not say you have reached a good understanding of the code unless and until you truly have. Correct the basic issues even if it means asking for additional time.
- Everyone, think long term… please! What starts as a small product can quickly grow before you know. Many big products have started small. Putting all best practices upfront may be an extra overhead in the beginning — especially for an MVP; but definitely have a plan for it. Treat it as a part of the technical debt that needs to be paid some day.
Beyond these generic guidelines, we have something more based on our unique value proposition. The sequel of this article is coming soon, and it will cover that. However, reach out to us if you are in a hurry, or if you have anything specific.
Software product development often takes a hit as the original developer leaves and someone else is expected to take over and continue. The cover story is usually that almost all development is done and very little work is remaining. But that may not be true. Often there are chronic problems due to disregard of best practices. Fixing those is important. Otherwise, the product may die in the chasm.