\u201cA \u2018startup\u2019 is a company that is confused about - 1. What its product is, 2. Who its customers are 3. How to make money.\u201d - Dave McClure, Founder 500 Startups\r\nDuring its journey, a tech startup has three levers of success: cost, speed, and quality.\r\n\r\nUnfortunately, you can choose only two at a time. So, if you pick speed and cost, you might have to sacrifice quality. Or, if you chose speed and quality, it\u2019s likely to cost you millions. This choice of two over three leads to software entropy, which is a case of \u201cwhat's done cannot be undone,\u201d as Lady Macbeth says, or in tech terms, you\u2019d say, \u201cIn a closed system such as software technology, a depleting quality of product cannot be improved over a period of time.\u201d\r\n\r\nWe will discuss more on software entropy, factors leading to it, and possible solutions. Before that, it is important to understand what leads to software entropy.\r\nThree Levers Of startups\r\nSpeed\r\nOnce you wade into the waters of startups, you realize that time is the most limited resource of all three aforementioned factors. Until a startup starts seeing some traction in terms of revenue, it\u2019s never termed a company.\r\n\r\nTo make the best use of the bootstrapped amount, a quick product usually called the \u2018beta version\u2019 and often of a \u201csubdued quality\u201d (compared to the goal product), is released to capture the market as early as possible.\r\n\r\nStartups drain most of their resources to reach the market as soon as possible, putting all efforts into achieving \u2018speed\u2019, which in most ways is the most popular lever of the three.\r\nCost\r\nWhen compared with time, the cost is tangible in every sense. It is the heartbeat of a startup.\r\n\u201cThere are only two priorities for a startup: Winning the market and not running out of cash.\u201d\u00a0- Ben Horowitz\r\nThe more the balance in your account, the longer you survive. During the initial phase of a startup, most of the resources are spent arranging important assets (read liabilities too) for your organisation, such as paying for the office, furniture, internet, salaries, and a whole lot more.\r\n\r\nMore often than not, startups struggle to afford the top developers from industry because of budget constraints. Usually, top coders or senior managers are left for later, with the intention of hiring them when money flows in.\r\nQuality\r\nGood work is expensive, great work is more expensive, and quality work comes at an exceptional cost. Quality is the most difficult to achieve. Good quality requires a great amount of time and cost to attain. And this is where most startups suffer.\r\n\r\nMost startups start with limited funds and strive to make profits as soon as possible. They aim to be production-ready and sell before they run out of capital. Until the company is at a growing stage, an entrepreneur strives to produce rapidly and penetrate the market. This allows these startups to acquire market share and collaborate to build on customer feedback.\r\n\r\nMost companies start with a \u2018beta-version\u2019 which can generate some traction and fund their requirements as they move up the ladder in a market characterized by severe competition for their product.\r\n\r\nStartups typically hire fresh developers and engineers (few have the budget to hire senior developers) who understand their requirements, have some sense of development, and can create the product with the least amount of resources. And no doubt, these developers come at a lower cost. They are easy to mould and can often work in odd shifts.\r\n\r\nRaghav Chandra, Co-founder\/CTO, Urbanclap, says\r\n\u201cQuality is often viewed as a compromise on speed (longer sprints, more code writing\/testing, etc.) and cost (more engineers, better quality infra, etc.). However, in the younger stages, good quality is a huge boost to speed and cost.\r\nQuality has multiple aspects: its the architectural design (!= infra) that plays the biggest leverage in the early days.\r\n\r\nThe biggest time-sink happens either on finding bugs (going through the call chain) or building features on badly designed code - both products of bad segregation and upkeep of the software.\u201d\r\n\r\nAs the company starts to grow and make a profit, the requirement to build a stable product pops up. The previous version of the product created needs to be improved, and codes have to be re-worked.\r\n\r\nAs customers begin to appear, quality soon becomes a priority. To improve this quality, an employee with more experience and a better understanding of the market is added to the team. Senior developers who come at a greater cost are hired to work on the existing product. These developers spend most of their time improving old lines of code while also quickly developing new, top-quality features.\r\n\r\nFixing old lines of code to developing new features, most of the developers struggle in getting the desired result. But as the months pass, and with all the efforts of the teams to improve a product, the quality refuses to improve.\r\n\r\nThis factor is termed software entropy.\r\nWhat is software entropy?\r\nBased on Wikipedia's definition, with respect to the second law of thermodynamics in a closed system (where no input or output is made), the disorder cannot be reduced over a period of time.\r\n\r\nThis law seems to be relevant even in the case of software systems; as a system is modified over a period of time, its disorder only tends to increase rather than decrease with all the effort.\r\n\r\nAs new developers try to improve the existing piece of code to improve quality, the product quality gets farther away from desired results. As the modifications are made to correct the existing lines of code, the \u201centropy\u201d keeps on increasing, leading to more complex code which is difficult to fix. This often leads to frustration among the developers and software engineers. Most of the time, growing startups take the hard route of writing codes from scratch to fix this entropy.\r\n\r\nIn the book The Pragmatic Programmer: From Journeyman to Master, Andrew Hunt and David Thomas write,\r\n\u201cSoftware entropy is contagious and if not controlled, becomes an epidemic.\u201d\r\nThen, how can we fix the problem and what would be the best measures to hire a developer who can produce quality work in less time and budget?\r\n\r\nSo, should startups focus on cost, speed, or quality?\r\n\r\nAnand Thaker, CEO & Founder, Intelliphi says,\r\n\u201cThe quality of the system should achieve a minimum threshold so that it doesn't create constant headache with user's experience"\r\nThere are exceptions where systems operate critical or life-death operations.\r\n\r\nDuring these early stages, startups are still figuring out their product-market fit. In a noisy and highly competitive SaaS-based world, product-market fit makes or breaks a startup. In addition, the team dynamics and leadership of the team are also at a rapidly developing stage. The lean startup fail-fast-cheaply is a sound philosophy for that reason. Consider it the first entropy challenge.\r\n\r\nAs the product-market becomes solidified, a startup either plans quality rebuilds on parts or the entire platform completely. At this point moving forward, quality efforts that translate to better customer experiences impact growth. Good growth provides greater funding and customer retention.\r\n\r\nPersonally, I favour product-led startups and startup founders. Usually, the solutions and vision are robust and their approach incorporates resiliency... and their exits and multiples are far greater (3 to 5 times more than other typical startups). \u00a0For these types of startup\/founders, they are very likely to respect entropy, however, even their understanding of the earlier stages is about speed and fit to gain critical initial momentum.\u201d\r\nHow can startups reduce software entropy?\r\nStart with minimal technology\r\nUrbanClap CTO talks about using minimal and reusable technology as \u201cthe inability to properly segregate concerns which leads to bad and bloated team designs and over-inflated infra costs. To solve it well, the biggest and foremost leverage is to ace the culture of intentional architectural design.\r\n\r\n \tstrong design-review culture focusing on modularity and intentional-design for reuse\r\n \tframeworks over guidelines \u2013 with small teams, evangelizing best practices is a slow process. It\u2019s better to "automate" best practices by engineers building frameworks and tools to standardize different pieces of engineering.\u201d\r\n\r\nMost startups start with a certain idea, and it evolves over a period, adding new ideas, features and sometimes it turns into a completely new product. Ensure that technology A you use during your initial days of the foundation is compatible with technology B which can merge with technology C which you might use in the future.\r\n\r\nAs the vision of a company evolves, so does the product, and various technologies are introduced (or disrupted) during this journey. Make sure you use minimal technology until your product is stable and ready to use. Optimize your code.\r\nConsider code optimization\r\nWrite and rewrite an integral part of the code and make it a habit to do it as you go forward. This helps you keep a track of all the code which goes live at the backend of a glossy product.\r\n\r\nWriting an integral part of the code helps a new employee revise important parts before sending in a new commit. Integral parts help to differentiate the good part of the code from the bad one.\r\nRecheck the commits\r\nEver committed a code? If not, put it on your bucket list.\r\n\r\nIt\u2019s a measure of the effort and the commitment developers put into an organization. The first committed code is celebrated in most startups. Its time is to recheck these commits. Not the first, not the last, but all.\r\n\r\nMake it mandatory for peers to go through all the code commits to ensure no stone is left unturned in getting the best quality code out.\r\nDon\u2019t forget assessment tools while hiring\r\nOver a period of time, you will realize that you cannot justify the poor quality of codes to your clients, blaming it on time and cost.\r\n\r\nUsing technology assessment software from your first hire ensures that you deal with employees who understand your requirement and are capable of yielding results under pressure.\r\n\r\nEvery wrong hire in a startup costs close to $18,000, from salary and perks to all the processes involved in hiring \u2014 most importantly, the interview and assessment hours spend by a small team, working on important projects.\r\n\r\nTechnical recruitment software comes with features such as multiple programming languages, automated test creation, and detailed candidate reports. Extensive plagiarism features help teams remain free from the usual hassle of \u2018keeping an eye\u2019.\r\n\r\nTasks like \u2018Java Project\u2019 (part of an existing project that\u2019s shared as an assignment) could be shared with candidates who work in a real coding environment committing actual codes, which gives the right picture of the work that has to be done.\r\nDo your homework\r\nLast but not least, do your homework. Follow influencers, read books, connect with people in a similar field.\r\n\r\nThere are a lot of people who have worked hard to improve software entropy in their organization.\r\n\r\nAnand Thaker says,\r\n\u201cKnowledge and communication are critical to improving on entropy. \u00a0We've experienced entropy when there is a departure of a team member who had deep knowledge in a part of the system.\r\nAnother is when certain parts of the software remain untouched for several months or years. Ensure regular revisits of those capabilities and the underlying code\/logic.\r\n\r\nAlso, consider setting a tone\/culture on the philosophy of development.\r\n\r\nEntropy will always exist, however curtailing its growth so is an art. As technical or executive leads, you may already know this, but software development is a disciplined process. Good team members take pride in their work. Recognition of that effort from their peers goes a long way.\u201d\u00a0Talk and discuss the learnings people have learned over time.\r\nConclusion\r\nDuring their initial phase, should startups focus on quality?\r\n\r\nBad code quality has been a major reason for the failure of many startups. A lot of time, money, and efforts have been lost in improving it over a period of time. Simple comments like \u2018the code is bad\u2019 to \u2018improve this line\u2019 are better than doing nothing to improve the code.\r\n\r\nStartups are an economic phenomenon breaking new grounds and changing the world.\r\n\r\nRaghav Chandra\u2019s suggestions for startups suffering from entropy is \u201cFor smaller teams, I have found better leverage in having more teams, and keeping the organization flat, where everyone is hands on.\r\n\r\nAs Tech Leads \/ Managers, it is important to groom the team to "think" better. Efforts put in thinking better is what helps, this results in less time fixing things later.\r\n\r\nAnd brainstorming and deep thinking before implementation isn't a compromise on time or cost \u2013 it's indeed the cheapest way to build for system-level quality.\u201d\r\n\r\nIt\u2019s time we care about the entropy and hire the best developers who can help reduce it from the products which we build.