On Technical Debt http://www.ontechnicaldebt.com Online Community Wed, 28 Jan 2015 09:45:28 +0000 en-US hourly 1 http://wordpress.org/?v=3.9.3 CISQ: Establishing Industry-wide Standards to improve Software Quality http://www.ontechnicaldebt.com/uncategorized/cisq-establishing-industry-wide-standards-to-improve-software-quality/ http://www.ontechnicaldebt.com/uncategorized/cisq-establishing-industry-wide-standards-to-improve-software-quality/#comments Wed, 28 Jan 2015 09:45:28 +0000 http://www.ontechnicaldebt.com/?p=3344 read more]]> CISQ is the Consortium for IT Software Quality, a special interest group of the Object Management Group organized to create standards for measuring software quality, including the definition of technical debt and factors that influence it: security, performance, reliability, and maintainability. 

This article, from SD Times, goes into depth about the Consortium of IT Software Quality – what it does exactly and why it is necessary in the software industry. CISQ (managed by the Object Management Group, otherwise known as OMG) was chartered in 2009 to create specifications for measuring source code quality. Dr. Bill Curtis, executive director of CISQ and senior vice president and chief scientist at CAST software, commented in this article that the industry needs “standard, low cost, automated measures for evaluating software size and structural quality that can be used in controlling the quality, cost and risk of software that is produced either internally or by third parties…” Structural quality is an aspect of engineering software that is a cause of many system failures which have been making headlines recently. CISQ aims to set a standard for systems through its specifications: the Automated Function Point sizing standard (AFP) and the CISQ Software Quality standard. 

These two specifications aim to standardize measurements for size, automated function points, reliability, security performance efficiency, and maintainability. These measurements would help simplify outsourcing contracts and service level agreements which involve size and structural quality – allowing them to be based on universal measures, rather than various differing measurements based on contrasting attributes. The AFP provides a low cost and consistent size measurement option, compared to a subjective and expensive measurement based on manual counting. Automation and subjectivity guarantee that one person counting with AFP will produce the same number as two others counting within the codebase.

Why is a software quality standard needed? This standard is needed because a measurement on software quality is often subject to the interpretation of each person who handles the code under scrutiny. A standard like this is designed to create an understanding between developers and enterprises on how systems are analyzed based on reliability, security, efficiency, and maintainability. Structural quality is measured vis a vis pattern matching and code analysis for violations of good architectural and coding practices in source code. This can be done through automated analysis technology which can detect structural flaws immediately. For example, it would be able to detect an entry in the user interface that skips around user authentication functions and authorized data access routines – accessing the data directly. This is a security risk that could end up being a cause of likely data corruption.

Adopting the code analysis tools that are in accordance with CISQ software quality standards would allow for all stakeholders in a project to access which apps possess the greatest risk to a system. Once risks are uncovered the next step would be to establish minimum threshold requirements for quality in critical business systems. When defects within business critical systems have been making headlines and costing enterprises millions, accepting a standard will allow stakeholders to govern and maintain their systems based on measures developed by industry experience.

At the moment the standard is still in the approval process at OMG, however, Dr. Bill Curtis believes that adoption of the standard will be driven by pull rather than a push in the industry as the standard was created due to IT customers asking for it and aiding in its development. CISQ has taken on raising the structural quality of IT software and ultimately reducing the risk and cost of IT software to its users.  In standardizing software quality, CISQ evaluates certain characteristics of extant code, while other organizations approach their standards from the development process looking at software from the product level.

CISQ aims to increase the structural quality of software systems by creating a global standard. To read further clarification on which standards and specification compliment each other and how they work together read the full post: http://sdtimes.com/cisq-aims-ensure-industry-wide-software-quality-standards/

]]>
http://www.ontechnicaldebt.com/uncategorized/cisq-establishing-industry-wide-standards-to-improve-software-quality/feed/ 0
The Technical Debt Singularity http://www.ontechnicaldebt.com/uncategorized/the-technical-debt-singularity/ http://www.ontechnicaldebt.com/uncategorized/the-technical-debt-singularity/#comments Fri, 23 Jan 2015 09:00:00 +0000 http://www.ontechnicaldebt.com/?p=3339 read more]]> A technology singularity, in terms laid out by this post on technical debt, is a point when technology created by humans reaches the point where it can no longer be understood by its creators. A mathematical singularity is a point beyond which odd or unpredictable behaviours can be recognized. In formulating the hypothesis for this singularity the logic follows that eventually humans will create a computer that is smarter than the human brain. Computers will be able to develop themselves at a quicker rate than humans can keep up with; the speed of development will increase exponentially heading towards infinity. This post addresses how the singularity idea can apply to technical debt.

When a software project reaches the point where it gets bogged down and grinds to halt, this is because decisions have been made that accrue technical debt. For example, writing a bit of hacky code now to complete work quickly is a decision to loan ourselves time from the future. We end up paying interest on the loan as we waste time maintaining the poor code over time. When the interest owed on technical debt exceeds the amount of man-hours in a work day a technical debt singularity occurs.

Technical debt is not always a negative thing, but when it goes un-managed it can bring work to a halt. In order to avoid this, paying down interest is necessary. Whether this be by refactoring, writing automated tests, or fixing poor processes. Keeping technical debt under control can be made easier by following some of the strategies outlined in this post:

  • Source control in order to better manage changes made in the code base
  • Automated testing throughout code in order to have continuous integration/delivery
  • Improving communication with business managers so they understand the consequences of shipping too fast
  • Visually monitoring technical debt and paying it back whenever possible

Starting off the new year with a focus on more long term development could keep the probability of technical debt singularity at bay and improve the quality of any software project. Communicating with business stakeholders to make sure deadlines are realistic and don’t infringe on quality is necessary in order to keep technical debt from building up uncontrollably.

To read the full post go to: http://workingwithdevs.com/technical-debt-singularity/?utm_content=bufferfb58a&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

]]>
http://www.ontechnicaldebt.com/uncategorized/the-technical-debt-singularity/feed/ 0
Is Refactoring “Needless Rework”? – Refactoring for Design Level Smells http://www.ontechnicaldebt.com/uncategorized/is-refactoring-needless-rework-refactoring-for-design-level-smells/ http://www.ontechnicaldebt.com/uncategorized/is-refactoring-needless-rework-refactoring-for-design-level-smells/#comments Mon, 19 Jan 2015 09:00:21 +0000 http://www.ontechnicaldebt.com/?p=3335 read more]]> Here’s a post that delves into the necessity of refactoring in software engineering, comparing the practicality of refactoring in software to restructuring in urban planning. It begins by stating that when running software projects that span millions of lines of code the original design is usually good, over a period of time, however, the design begins to degrade. Gradually work slows down and more time is needed to make fixes or enhancements. In order to get work going at a faster speed, developers introduce more shortcuts building more technical debt until it reaches a state where development comes to a halt. There are only two options to follow this: rewrite or refactor.

Most developers would prefer to rewrite but this is a less practical option from a business perspective. Refactoring is the only real practical option. In the example of the city of Bangalore where sudden overcrowding from the IT boom created high amounts of traffic congestion, overhauling the whole city as a solution is not feasible. Refactoring or restructuring is the more appropriate solution and is needed at different levels. In the long term, metro lines would be the best solution but their construction is inconvenient for the citizens in the short term. Therefore, expanding roads, building overpasses, and smoothing out roads are good short term solutions. These examples of restructuring (refactoring) can also be applied to software systems at the architecture, design, and code levels.

The main focus is refactoring for design level smells. Design smells are, going back to the example of Bangalore, symptoms of creaking infrastructure like: missing roads, bottleneck junctions, and footpath roads being used by non-pedestrians. Similar symptoms can be found in software like missing abstractions, deficient encapsulation, and broken hierarchies.

Every engineering discipline has to manage non-optimal and sub-optimal solutions. Changing requirements and rapidly emerging technologies makes software engineering have more of a need for quick adaptation. This is one of the reasons agile practices have gained momentum in the past years and why it focuses so strongly on refactoring. Refactoring is therefore necessary in forming core practices for creating high quality software.

To read the full post go to: http://www.designsmells.com/article.php?id=7

]]>
http://www.ontechnicaldebt.com/uncategorized/is-refactoring-needless-rework-refactoring-for-design-level-smells/feed/ 0
Technical Debt is Risk Management http://www.ontechnicaldebt.com/uncategorized/technical-debt-is-risk-management/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-is-risk-management/#comments Fri, 09 Jan 2015 09:00:31 +0000 http://www.ontechnicaldebt.com/?p=3331 read more]]> If refactoring code reduces a code base by 80%, then the chance of missing a necessary change in the code base and the risk of missing something in testing that damages the production business are also reduced. Therefore, by this logic, the management of technical debt is in fact risk management. Using the analogy of a kitchen for technical debt can be helpful – a kitchen where everything is in the place a professional chef would expect it to be is a clean kitchen. However, a kitchen where things are in the wrong place and scattered around is kitchen with technical debt because the chef has to clean up and prepare before even beginning his work.

Every development team will have their own definition of where things should be in their code – anything that does not conform to this standard becomes technical debt in the code base and makes working with this code significantly more risky. The types of risks that can be introduced by the presence of technical debt are:

  • Delivery Risk – Technical debt has a habit of blowing up in the test phase were it can no longer be managed by responded to. For example, a bug can resurface several times because of a lack of proper regression testing.
  • Business Care Risk – if code contains tech debt, there is a higher probability that the code will behave in more unpredictable ways than if it were without debt. This means that changes made to code may not present the value expected.
  • Risk to Existing Model – when code has technical debt the likelihood of it causing a failure in production that damages the existing production system increases greatly.

If a team is approaching a project from a risk management perspective, paying off technical debt before making any changes is the more responsible move. By looking at the code base as a portfolio of sold call options makes it so every component of the system has its technical debt accounted for. The measure of technical debt present should be calculated as how much effort it takes to pay it down, how complex the debt is, and how many team members can work on the component. The product owner can create what is called a “tornado map” which is a high level road map for the next 6 months to a year by which the team can decide what debt to address now and which can be left for a later date. In some cases technical debt may take a long time to fix or be too complex to estimate effectively, paying down this debt early is often the best solution.

Technical debt has quite a bit to do with the skills and perceptions of the team working on any code base. One team may consider their code base clean when in reality it contains a lot of risk. This is an instance when someone with a lot of experience in identifying dead code would be helpful.

To read the full post go to: http://theitriskmanager.wordpress.com/2014/12/31/technical-debt-is-risk-management/

]]>
http://www.ontechnicaldebt.com/uncategorized/technical-debt-is-risk-management/feed/ 0
The Three Kinds of Code: Divergent Perceptions about Cost http://www.ontechnicaldebt.com/uncategorized/the-three-kinds-of-code-divergent-perception-about-cost/ http://www.ontechnicaldebt.com/uncategorized/the-three-kinds-of-code-divergent-perception-about-cost/#comments Mon, 05 Jan 2015 09:00:04 +0000 http://www.ontechnicaldebt.com/?p=3316 read more]]> This post discusses the three categories of code that can be found within a certain project and that confusion about them plus a misunderstanding about their actual cost can lead to trouble. The three categories of code follow:

  1. Temporary Code: or code written to throw away within a day or week – if it breaks it’s alright because it was made to be replaced anyway.
  2. Sustainable Code: code built to last with strong automated testing and holds up to standards that the team is happy to maintain.
  3. “Sloppy” (the post refers to it under a different name) Code: pertains to quick fixes, code written by amateurs, rush jobs, things that were meant to be cleaned up but never were.

When a business person expresses what the want (something cheap and quick but not fragile) they propose a solution that falls into the sloppy category. Developers react poorly to this solution demonstrating divergent perceptions about cost between developers and business stakeholders.

Screen Shot 2014-12-31 at 12.35.35 PM

Given that the perception of costs differ, it is natural that the business person would prefer the sloppy action – it is more valuable than the temporary option but doing things sustainably costs cost more. The developer side rejects what they see as the high cost option. From each of their perspectives they are right, they are just looking at different costs.

Rewriting the headers can demonstrate this:

Experienced developers are more aware of longterm costs because those are generally assumed to be their problem. The maintenance of sloppy code adds up and is not often attributed to excess schedule pressure from business stakeholders. Developers, however, can be perceived as increasingly unproductive and unreliable. Sloppy code build-up (sometimes referred to as technical debt) is not just bad for developers but for the whole organization. If the cost of software continuously increases than it becomes a powerful advantage for competitors who are more thoughtful and disciplined in their processes.

Many parts of the agile world either explicitly or implicitly rule out the use of sloppy ode. In the example of extreme programming, a project is begun with a number of sustainable practices including: pair programming, test driven development, and constant refactoring. Quality is a fixed variable in the planning process. In order to avoid the creeping use of sloppy code make sure that everyone on the development team are invested in the long-term. Stakeholder’s should be educated on how expensive supposed cheap solutions are. Temporary solutions should be truly be temporary by agreeing in advance on an end date, if a permanent solution is the follow up it should be included in the budget, and when the end date approaches push back should be denied and the team should be reminded of the previous agreement. Ultimately, keeping a keen eye out for sloppy code in disguise is important. For example, out sourcing or off shoring a project can seem cheap and easy but it can end up being sloppy code sold as sustainable code.

To read the full post go to: http://agilefocus.com/2009/06/22/the-3-kinds-of-code/ 

]]>
http://www.ontechnicaldebt.com/uncategorized/the-three-kinds-of-code-divergent-perception-about-cost/feed/ 0
Not all Technical Debt should be Treated Equally http://www.ontechnicaldebt.com/blog/not-all-technical-debt-should-be-treated-equally/ http://www.ontechnicaldebt.com/blog/not-all-technical-debt-should-be-treated-equally/#comments Tue, 30 Dec 2014 09:02:24 +0000 http://www.ontechnicaldebt.com/?p=3309 read more]]> The on going management of technical debt has become viewed as critical for the development of high quality and maintainable software, even by those who promote agile development processes. This consideration for tech debt management has contradicted the notion that development decisions should almost exclusively be driven by business value because of the difficulty of assessing the value of paying back tech debt or investing time into solid software architecture. This post posits that the value of managing technical debt increases more with project size; if a project is just a few thousand lines of code with a team of just 2 or 3 people it is relatively easy to add architecture on with continuous refactoring. Once a project has tens of thousands of code lines developing new features becomes more difficult. Integrating management of technical debt and investments into a solid architectural foundation would then pay off with big dividends. The problem is how to measure technical debt and focusing on the right kind of debt.

In order to measure technical debt more accurately more precise definition of what doing things right is needed. The definition of right can be based on programming rules, architectural rules, or any other set of rules – then by counting the number of rule violations in the code an estimate of technical debt can be calculated. This method is offered in several basic technical debt calculators but can give misleading numbers that lead to fixing irrelevant problems. The important aspect of calculating technical debt is knowing which rules are most vital to the quality of the system and apply those to the measurement platform being used. In order to decide if a rule makes it into the ruleset to measure technical debt ask how much impact a violation of this particular rule will have on the quality and maintainability of the system and how difficult it would be to fix those violations in the future.

To start prioritizing rules, setting up rule categories can be useful. For example, local programming rules (no empty catch statements), rules based on automated testing and test coverage, rules based on software metrics (metric thresholds), and rules based on architecture and dependency structures are a few. Measuring the general impact of these categories in terms of repair cost impacts on visible quality and code maintainability would be the first step to focus on what debt needs to be dealt with first. Visible quality impact describes what is directly noticeable by the user of a software system, i.e. bugs or undesired program behaviour. Maintainability describes things like code comprehensibility and code changeability. The post then applies these terms to each of the formerly mentioned rule categories:

 Screen Shot 2014-12-27 at 8.49.41 PM

Programming rule violations are found to be easy to repair because fixing them usually only requires changing a single file. Meanwhile, testing and test coverage violations can have high repair costs if tests are creating after initial development. The impact of testing violations is also high because a lack of testing makes visible bugs muck more likely to occur – maintainability is only affected in that good test coverage makes global refactoring easier. Metrics based rules are classified as having low repair costs unless the metric applies to a global parts of the system, like coupling within the overall system. Architecture problems don’t necessarily cause visible issues, but fixing architecture after the fact can be testing and expensive.

It is common for development teams to focus on those rules that have high visible impact because user experience has high business value. However, when asked what issues have the highest cost on the lifetime of a project it is most often agreed that architectural rule violations (or architectural debt) is the greatest hinderance to keeping debt low. Therefore, closing the gap between visible costs and maintenance costs is likely to have good returns on investment and demonstrates that not all debt should be treated the same.

To read the full post go to: http://blog.hello2morrow.com/2014/12/not-all-technical-debt-should-be-treated-equally/

]]>
http://www.ontechnicaldebt.com/blog/not-all-technical-debt-should-be-treated-equally/feed/ 0
Bad code isn’t Technical Debt, it’s an unhedged Call Option http://www.ontechnicaldebt.com/blog/bad-code-isnt-technical-debt-its-an-unhedged-call-option/ http://www.ontechnicaldebt.com/blog/bad-code-isnt-technical-debt-its-an-unhedged-call-option/#comments Mon, 29 Dec 2014 09:05:51 +0000 http://www.ontechnicaldebt.com/?p=3307 read more]]> This is a post that discusses an alternative to the metaphor of technical debt for ‘bad code’. The problem with technical debt as a metaphor is that for managers debt can be a good thing – it can required for financial needs or encouraged by tax breaks in certain financial situations. However, the debt that is often spoken about in codebases does not fully capture the risk that comes along with writing short cuts.

Maybe the better metaphor would then be a call option. A call option is when the right, not the obligation, is sold to someone to buy an agreed on quantity of something at a price that is fixed now. From the seller perspective, if the price stays to low they get to keep the payment and are ahead but they also run the risk of still having to provide the good even when the price has increased greatly. This is can be referred to as an unhedged call – where no matter what the a product costs to the seller they have to supply it.

Call options is a better model for code issues because it captures the unpredictability of what can happen when writing in certain features and code. For example, a feature can be added to a system without cleaning it up and the benefit is collected immediately (the premium is collected). If that code is never called upon again than it would have been foolish to clean it up in the first place. However, lets say a radical new feature is going to added – these quick fixes and become very expensive to deal with. Time has to be taken to fix these issues right before deadline or no one on the team remembers pertinent information need for the code to make sense in the first place – the market by then has moved away from where it was expected to be and the option has been called. No matter what the cost to input this feature it must be delivered.

Therefore, even if it is more expensive to do thing clean from the start, it would also be less risky. A messy system is full of unhedged calls that can be called upon at an unpredictable cost to the organization. Technical debt does not communicated the risk of writing sloppy or quick fixes into code – debt is something to be managed and just another tool. When talking about implausible delivery dates it may make more sense to talk about unhedged call options.

To read the full post go to: http://nblo.gs/12c3vP

]]>
http://www.ontechnicaldebt.com/blog/bad-code-isnt-technical-debt-its-an-unhedged-call-option/feed/ 0
What’s Your IBM i Application Debt? – How To Start App Modernization http://www.ontechnicaldebt.com/blog/whats-your-ibm-i-application-debt-how-to-start-app-modernization/ http://www.ontechnicaldebt.com/blog/whats-your-ibm-i-application-debt-how-to-start-app-modernization/#comments Fri, 26 Dec 2014 09:02:08 +0000 http://www.ontechnicaldebt.com/?p=3304 read more]]> In a survey conducted by Micro Focus it was estimated that mainframe shops around the world average around $11 million in application debt; the backlog of unfinished and un-started IT projects have increased by 30% in the last 2 years. The study did not go into IBM i shops, but the numbers are assumed to not trail far behind. Application debt was a term coined as a reference to the amount of resources it takes for an organization to complete a the backlog of application modernization projects needed to keep systems up to par with the median state for a given organization in a certain place and time. Discussing application debt can be a useful when addressing problems associated with application modernization or the lack of such modernization.

The study by Micro Focus involved 590 CIOs and IT Managers in 9 countries – it does not provide definite answers for mainframe application debt problems but spending more money does demonstrate itself to be part of the equation but is not the only variable in play. The research calls for a multi-pronged approach to modernization with tools, technology, processes, and skills in mind. Some of the applications had been designed and built over 40 years ago, and the processes, technology choices and skills may not be aligned for the way business needs to work currently. Modern applications today can mean several things – it may mean that it has a mobile or web interface or it runs in the cloud. And many problems affecting mainframe shops, including the prevalence of decades-old code, procedural code maintained in a green screen environments, and a lack of young people with mainframe administration skill are also problems in IBM i shops.

However, what is not easily explained by the study is the trend in organizations swapping out mainframe to more ‘modern’ systems like SAP. Swapping out and replacing one system for another newer one is not necessarily an improvement, what typically happens when a system is replaced with something ‘better’ is that it ends up being the equivalent of what was used before. This is because the competition can swap out their system’s for the more ‘modern’ one at the same time – a new system cannot do as good a job as what was used before as it takes years to replace, therefore barely making a difference.

Implementing agile processes is an integral part of reducing application debt whether the organization runs on either mainframes or IBM i servers – 20 0r 30 years ago slow releases may have been feasible but that quickly seems to be less and less the case. So how does the $11 million in application debt translate in terms of IBM i servers? Mainframe shops tend to be larger (although IBM i servers are not strictly used by smaller and mid-sized businesses), therefore it would be safe to assume that application debt is halved for IBM i severs at $5.5 million. This is an important take away for IBM i shops in order to begin the conversation about app modernization and help organizations start to think in terms of technology tools and skills. In order to begin to address the issues brought up by app debt what is possible to do within the organization is necessary.

To read the full post go to: http://www.itjungle.com/tfh/tfh033114-story05.html

]]>
http://www.ontechnicaldebt.com/blog/whats-your-ibm-i-application-debt-how-to-start-app-modernization/feed/ 0
Technical Debt: Is Management Only Getting Half the Picture? http://www.ontechnicaldebt.com/blog/technical-debt-is-management-only-getting-half-the-picture/ http://www.ontechnicaldebt.com/blog/technical-debt-is-management-only-getting-half-the-picture/#comments Mon, 22 Dec 2014 09:00:32 +0000 http://www.ontechnicaldebt.com/?p=3301 read more]]> Despite advancements in IT management’s visibility into the cost and quality of application  development, one issue remains to give IT management a full picture of their app development. This issue is how technical debt is calculated and presented to management, which usually does not present an accurate estimation of technical debt.

In most cases only changes to the code itself are factored into estimations of technical debt and validation efforts were left out, so when management asked for the final product IT would say they needed more time to validate changes in code to make sure breakages didn’t occur in standing code. This would become frustrating to management who use estimations in order to plan for future projects and dictate budgets – past estimations didn’t take into account things like size of the application, its interdependencies, and the technologies connected to it, leaving the estimates incomplete. Fixing a local violation of code is simple; however, the need to correct an issue increases greatly when it involves multiple teams and technologies. With multiple variables to take into account how can management ever get a correct estimate to address and reduce technical debt? How can the gap between estimates from development teams and the final cost for defect correction delivery be reduced?

Split and sum is a plausible method by splitting efforts into categories: code remediation, unit testing, integration testing, and validation overhead – the sum = sum of efforts. If development teams had structural quality tools that could be configures to model the cost of remediation and validation more accurately, more realistic estimates of technical debt could be generated. This can be done by associating technical debt effort to each vulnerability identified. Therefore each time a quality check is run management receives a realistic estimate of the time needed to remediate and validate the code based off of past experience.

This allows for technical debt to become more than an interesting notion, but to maybe become more of a qualifiable metric. To read the full post go to: http://blog.castsoftware.com/technical-debt-is-management-only-getting-half-the-picture/

]]>
http://www.ontechnicaldebt.com/blog/technical-debt-is-management-only-getting-half-the-picture/feed/ 0
Move Fast, Minimize Technical Debt http://www.ontechnicaldebt.com/blog/move-fast-minimize-technical-debt/ http://www.ontechnicaldebt.com/blog/move-fast-minimize-technical-debt/#comments Wed, 17 Dec 2014 09:00:07 +0000 http://www.ontechnicaldebt.com/?p=3298 read more]]> This is post with some tips for start-ups to minimize their technical debt. First, it needs to be decided which code is going to be kept. Start-ups will often make code that is temporary and some code that will definitely be around later. Therefore, when code needs to switch from temporary to sustainable the developer team should make sure they clean up properly.

For the code that is intended to be kept, there are several steps that are helpful to making sure that technical debt does not build up in the codebase. Writing tests is always helpful, because if the code doesn’t have automated test coverage it either means that manual testing is occurring or no testing at all. Manual testing does not scale well and slows down feedback loops, while not testing at all slows down slows down development by instilling fear of breaking things and hinders bold changes. Refactoring is also key to keeping tech debt quantities low – it is important to default to keeping code very clean or else once things begin to get messy nobody feels bad about adding onto it. If making a mess intentionally, it is also important budget time later to clean it up.

This post mentions the phenomenon “normalization of deviance” where organizational cultures get used to things being broken, which can cause major issues in the code base. Therefore, when a bug appears a test should be written to expose it, then the bug should be fixed and the cause of the bug should be found and fixed as well. Being able follow some of these tips requires time, which is only possible if schedule pressure is under control. Non-technical stake-holders often want projects done quicker than the ability to produce than them well allows, finding a method to turn schedule pressure into productive ends is helpful. By making sure that hazy features are not attached to fixed dates. Production monitoring is another mode in which to make sure nothing is broken that developers are not aware of. When something is broken and unidentified it will either hover over the production logs or blindside the project, both end up wasting time. Starting with simple loggings that page every time there is a problem is one way to address unknown issues.

Building code with future improvements in mind is necessary for start-ups.  Simple code that later needs to built upon is easier if things are kept modular, preventing messes from spreading. Start-ups also use a lot of A/B testing, which helps with technical debt by keeping changes smaller as longer changes are harder to A/B test. Therefore, when an experiment was performed in the code and it succeeds and the feature will be kept and scaled up, that is the time to invest in the code. The post also recommends using a continuous integration server also allows for issues to be known about sooner, meaning it will cost less to fix them. Considering pair programming is also suggested, as it is like an instantaneous code review and the knowledge sharing aspect of it reduces bottlenecks and silos making new entrants easy to bring on.

All of these suggestions, although they may take time, are better than the alternative of accumulating technical debt which in the long run is much slower than using these tips. To read the full post go to: http://www.quora.com/How-can-startups-move-fast-while-minimising-technical-debt?utm_content=bufferdd182&utm_medium=social&utm_source=linkedin.com&utm_campaign=buffer

]]>
http://www.ontechnicaldebt.com/blog/move-fast-minimize-technical-debt/feed/ 0