On Technical Debt http://www.ontechnicaldebt.com Online Community Mon, 23 Nov 2015 13:54:08 +0000 en-US hourly 1 http://wordpress.org/?v=4.2.5 Defining Technical Debt: What It Is and What It Is Not http://www.ontechnicaldebt.com/uncategorized/defining-technical-debt-what-it-is-and-what-it-is-not/ http://www.ontechnicaldebt.com/uncategorized/defining-technical-debt-what-it-is-and-what-it-is-not/#comments Mon, 23 Nov 2015 13:54:08 +0000 http://www.ontechnicaldebt.com/?p=3636 read more]]> There is always a battle between the amount of time you have to get things done and the amount of work you have to do to get those things done. There is usually less time than what you need to complete all that work. This time vs. work dynamic is what creates technical debt. Hitting a release deadline is often valued over writing clean code, which leads to technical debt build up. This means the next release you are working on is going to take longer, leading you to take on more debt. A cycle like this is dangerous because it leads to poorly constructed code and can even result in system failures. You need to understand technical debt in order to avoid this.

These are the question on technical debt that need to be answered before you can begin to manage it:

  • What is exactly technical debt (and what isn’t it)?
  • Where does technical debt come from?
  • When is technical debt okay?
  • What issues does technical debt cause?
  • How can you measure technical debt?
  • How can you reduce it?
  • How can you avoid incurring it?

Tech debt is all the internal things that you have chosen not to within a specific release, but will have to address later impeding the speed of your next release. It means quick and dirty development. Technical debt is more than just a mess; messy code has not positives to it, whereas technical debt can have business advantages (being first to market). Taking on technical debt has to do with project constraints.

So what are some examples of technical debt?

The typical example would the huge source file in the code base that every developer fears touching. This module needs to be broken down into manageable pieces, but developers know that doing this could slow upcoming releases by weeks. However, adding onto the module without refactoring just adds onto the present technical debt. So the longer refactoring is put off, the higher interest paid on the debt becomes (interest in this case is added complexity of every change you’ve made on the code). There are other ways technical debt can manifest its costs, from an operational perspective large amounts of technical debt make the risk of downtime extremely high.

If this is technical debt, than what isn’t?

Ultimately sloppy code, dirty hacks, and unreadable code are not technical debt. Technical debt implies there was a decision taken to incur it, poor skills as a developer do not qualify as a cause of technical debt.

It is necessary to know how to exactly define technical debt because without a clear understanding of what it is and what it is not, managing it is almost impossible.

To read the original post, visit here.


http://www.ontechnicaldebt.com/uncategorized/defining-technical-debt-what-it-is-and-what-it-is-not/feed/ 0
How Far is the Healthcare Industry Lagging with its Technology? http://www.ontechnicaldebt.com/uncategorized/how-far-is-the-healthcare-industry-lagging-with-its-technology/ http://www.ontechnicaldebt.com/uncategorized/how-far-is-the-healthcare-industry-lagging-with-its-technology/#comments Mon, 02 Nov 2015 13:25:25 +0000 http://www.ontechnicaldebt.com/?p=3628 read more]]> Healthcare companies, whether they be hospitals or insurers, are just as susceptible to the effects of technical debt as any other company that has technology as the core aspect of its business. Healthcare institutions tend to implement systems that are simply “good enough” and as time passes they become less and less efficient and more brittle. Issues of scalability, software integration, and security become so overwhelming that many times these businesses will have to overhaul their whole systems and undergo a large-scale transformation/replacement of their current systems.

These type of overhaul or rewrite efforts are extremely inefficient, not only because they take up a large portion of the IT budget but because while this undertaking is going on, and the systems are on pause, the outside world keeps moving leaving businesses consistently one step behind the times. If you look at the way technology has transformed in the past few generations: monolith and batch oriented systems were replaced by the rapid spread of networks and personal computing, and the desire for instant responses by consumers made transactional systems start to be cobbled together into self-service systems. Now the expectations for responsiveness and availability of tech services are right here, right now.

This shift in expectations causes a large strain on healthcare companies that are not prepared for this type of technological evolution. What it comes down to, as it often does when rethinking how we handle technical debt, is a change in culture. This especially becomes the case with companies whose core service is not necessarily technology: it means changing how you manage those who have the technology knowledge within the organization. An environment that is open to experimentation and flexible to change and continuous improvement is necessary.

The example presented in this article is the prime case of a company that started off with a small targeted service and expanded into one the largest cloud infrastructure companies in the world: Amazon. Amazon’s exponential growth can be attributed to a tactic of incremental but continuous development of their core software systems,

This type of continuous and flexible development is not the norm in the healthcare industry for multiple reasons. Healthcare’s core competency is not technology so their prioritization of it is lagging behind tech leaders like amazon. However, whereas this could have been acceptable over 10 years ago when technology was not an integral aspect of customer satisfaction – now the status quo is unacceptable.

Rethinking the way technology departments operate in order to enact continuous mini-transformations and improvements to systems is long overdue for the healthcare industry. Look at how this year alone, health insurance companies (due to poor security measures and old software systems) were hacked and lost the confidence of their customers. This is one of the worst cases that can come about from not adapting to the times. But it can also mean losing time and money on other less newsworthy crashes and system failures. Taking measures to avoid this is extremely important. Creating a culture of periodic refactoring and breaking down monolithic systems into manageable chunks are good places to start.

To read the original article click here.

http://www.ontechnicaldebt.com/uncategorized/how-far-is-the-healthcare-industry-lagging-with-its-technology/feed/ 0
The Case Against Letting Go of Technical Debt http://www.ontechnicaldebt.com/uncategorized/the-case-against-letting-go-of-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/the-case-against-letting-go-of-technical-debt/#comments Wed, 28 Oct 2015 13:06:30 +0000 http://www.ontechnicaldebt.com/?p=3620 read more]]> When starting a new project, it’s assumed that you begin with optimal code. Then when you add a feature, it take E amount of effort. But what if the code you’re writing on for the new feature is less than optimal? The effort it will take is E + T (T = technical debt). This is like going further into debt, you took a loan the first time around and now when you continue to build on that loan the bigger the debt is. In terms of effort, each time you build on sloppy code, the larger the delay will be for the next release.

This is the way the metaphor of technical debt is explained. So is the metaphor not working when developers explain this to business stakeholders and they ignore the warning? Not necessarily.

The metaphor of technical debt does work, it’s just that business stakeholders would rather take the loan than to wait for the release. The uncertainty of when, or if, the next release will occur is too high for the business-end to wait. The next release maybe on a different feature and entirely different code than what the development team wants to work onto improve. Therefore, if business stakeholders comply with the developers and let them work more on the current release to make the next release easier, they may be working code that won’t be added onto later. Making the extra time spent a waste.

This isn’t the only uncertainty that makes the business end hesitate to hold off on a release: it is the uncertain costs of extra complexity. How much did the extra effort needed on a feature with technical debt actually cost? In hindsight technical debt is difficult to calculate. Estimation of tech debt usually amounts to additional man hours spent on project. But this is only a good calculation if you are assuming that developers are simply typists – and don’t take into account the mental effort it takes to resolve technical debt issues.

From this point, the original post finds it hopeless to consider the technical debt metaphor as a useful term to help developers with the conflict between quality and time of delivery. But this hopelessness comes from the assumption that calculating and estimating technical debt does not translate into business terms. If you look at an objective and fact based measurement approach – like what CAST AIP provides – then the estimations that seemed useless before begin to have real value.

The only issue that comes up with the burden of technical debt is not simply sloppy code that adds time to later development efforts – it also decreases application performance, robustness, security. All these are major issues that directly affect the business’ bottom line. If you ignore technical debt, its build up can lead to business interruptions – this can affect customer’s confidence in a product and asides from the short-term outage, lead to long-term losses.

So “letting go” of technical debt is not the most business savvy decision. Measuring it with the right tools so you can prioritize the most critical areas, manage risk, and improve application quality is the best way to go about dealing with technical debt.

To read the original post visit here.

http://www.ontechnicaldebt.com/uncategorized/the-case-against-letting-go-of-technical-debt/feed/ 0
The Black Hole of Technical Debt http://www.ontechnicaldebt.com/uncategorized/the-black-hole-of-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/the-black-hole-of-technical-debt/#comments Mon, 26 Oct 2015 13:41:01 +0000 http://www.ontechnicaldebt.com/?p=3609 read more]]> Looking at the traditional method of software development (Waterfall) we can see a lot of shortcomings with that method of development in terms of its relationship to technical debt.

Let’s take a quick look at what the Waterfall development method entails:

  • Each release starts by building features and, hopefully, resolving issues that were left behind in the previous release.
  • The alpha stage follows next, which is when features are ready for testing.
  • The beta stage is when enough bugs have been fixed to make the product acceptable for customer feedback.
    • However, consistently fixing just enough bugs in order to receive feedback can create a vicious cycle of doing ‘just enough’ work and creating unstable products.
  • Finally, the golden master stage is when there are no open bugs left. This usually means fixing only known issues and leaving the rest for the next cycle.

This is a dangerous way to make software because it allows for many opportunities to build on bugs and creating a spiral of technical debt. Agile methodology is, therefore, usually used to reduce technical debt and stop a cycle like this from occurring.

But before enlisting agile to solve all these development issues, there needs to be a clear definition of what it means for a feature to be done. If the definition of done is clearly illustrated then quality can be baked into the iterative agile approach. Usually, for a feature to be complete it means that it is ready for QA testing. The issue with this is that by the QA stage there may already be many small defects festering in the feature. Agile teams should be only consider a feature done when it is basically ready for the customer’s use.

In order to do this and keep a quick pace of development, agile teams should employ continuous integration, automated testing, and feature branching work flows. The master branch of code should be the number one priority for agile teams, and should always be in a condition to ship. If this standard is maintained then all new features, in a task branch, will include the code for the feature plus the automated testing attached to it. Once the feature is complete and passes the automated tests it can be merged into the mast branch – if this standard is maintained than technical debt can be kept under control.

Switching out a focus on deadlines, for a more general focus on quality is not resolved just by switching to agile – it is an overhaul of the culture within the development team. Product owners who want to focus on the most valuable work before anything else, should then reduce the scope of a release in order to focus on quality.

This change is not simple it requires education on the true costs and nature of technical debt – but getting out of the cycle of technical debt can be done using some of the tips above, which include switching to agile methodology.

To read the full post visit here.

http://www.ontechnicaldebt.com/uncategorized/the-black-hole-of-technical-debt/feed/ 0
The Symptoms and Causes of Technical Debt http://www.ontechnicaldebt.com/uncategorized/the-symptoms-and-causes-of-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/the-symptoms-and-causes-of-technical-debt/#comments Mon, 05 Oct 2015 13:43:35 +0000 http://www.ontechnicaldebt.com/?p=3601 read more]]> In the development cycle there are many places where technical debt can rear its head and cause problems down the line for the product you’re developing. In order to tackle the problem of technical debt first teams need to know what it’s comprised of, how to identify it, and, then, how to address it’s presence in a system.

Technical debt is comprised of several attributes, each with its own set of ‘symptoms’ that should be signals to increasing levels of tech debt in your system.

They are:

  • Implementation Debt: this manifests itself as code duplication, static tool rules violations, and code smells.
  • Design and Architectural Debt:  this can be seen through design smells and design rule violations.
  • Test Debt: this is either when there is a lack of tests, inadequate coverage, or improper tests in the code base.
  • Documentation Debt: when there is a lack of documentation, poor documentation, or documentation that is severely out of date.

The points mentioned above are tell-tale signs that there is technical debt in your code base, but there are also different types of debt that can be present. These types of debt vary in how and why your development team is incurring technical debt.

They are:

  • Strategic Debt: it is incurred knowingly for strategic purposes (such as first-to-market release) and the debt is taken on in the long term (not to be paid back in the next sprint).
  • Tactical Debt: is also taken on knowingly but for quick gains and is meant to be paid back in the short term.
  • Inadvertent Debt: it is taken on unknowingly due to a developers lack of skill or awareness of how technical debt is incurred.
  • Incremental Debt: is continuous inadvertent debt.

Looking at the breakdown of technical debt, from its symptoms to how it is caused it’s easy to see that debt is inevitable. However, in order to keep that debt from taking over your code base and slowing down developments, steps to stop this debt from accumulating need to be taken.

How do we do this?

The first step is heightening awareness around technical debt; holding team meetings where technical debt is explained (as above) and then introducing and putting into place relevant processes to address it. In order to prevent technical debt build up, development teams should hold training sessions in order to learn and, in the future, perform best practices.

Once preventive measures are put in place within a development team, the team should focus on repaying existing technical debt. When technical debt builds up in a code base it slows down development and can cause breakages and outages. Therefore, paying back tech debt  needs to be a priority. But there is a paradox that needs to be resolved: it is not always feasible to stop development in order to pay back debt and letting tech debt run rampant is also not a possibility. So how do teams find the balance between maintaining continuous delivery and best practices for technical debt repayment?

  1. Identifying, documenting, and tracking technical debt is the first step. Without the knowing how much and where there is technical debt in the code base, a plan can’t be set up to pay it back. There are several static-code analysis tools that enable the tracking of technical debt to help this.
  2. Prioritize what parts of the code base need to be dealt with first. The areas most susceptible to breakages or user experience should come first.
  3. Make reduction in debt an aspect of each iteration.
  4. Incentivize team members to deal with technical debt. This will create a culture where technical debt repayment is not labor, but something that is rewarded.
  5. Keep an eye out for large-scale debt payments that can be fit into the development schedule and improve the overall status of the code base.
  6. Repay technical debt horizontally. This means not just paying back test or design debt, but recognize that all types of debt are ultimately interrelated and need to be dealt with cohesively.
  7. Some debt doesn’t have to repaid – this is the debt that is incurred in prototypes or products that are reaching the end of their life-cycle.

Ultimately, in order to deal with technical debt a systematic approach needs to be taken; pragmatism is also key when dealing with debt.

To read the full post visit here.

http://www.ontechnicaldebt.com/uncategorized/the-symptoms-and-causes-of-technical-debt/feed/ 0
The Prisoner’s Dilemma and Technical Debt http://www.ontechnicaldebt.com/uncategorized/the-prisoners-dilemma-of-technical-debt/ http://www.ontechnicaldebt.com/uncategorized/the-prisoners-dilemma-of-technical-debt/#comments Thu, 01 Oct 2015 13:03:07 +0000 http://www.ontechnicaldebt.com/?p=3591 read more]]> The prisoner’s dilemma is a great theoretical game showing the value in cooperation. If you’re new to the concept it works like this:

  • Two prisoner’s are held in two different rooms each being questioned for the same crime. Each one is told that if they sell out the other they will be set free and the other prisoner will serve a full term; if they both sell out each other they will serve equal terms; however, if they both take responsibility they will each serve the shortest sentence offered.

The most self-interested action would be for one to defect and sell the other out before the other prisoner has the opportunity to do the same. But this leads to both prisoner’s betraying the other and both receiving the full sentence. Therefore, the most beneficial action for each prisoner is to cooperate and receive the lightest sentencing – but self-interest and doubt plays a great role in making this a difficult position to take. Neither prisoner knows what the other will do and they are most likely to assume that the other one will sell them out. Therefore, they prefer to be the first to betray before they fall the victim to a similar action by the other prisoner.

But how does this apply to technical debt and refactoring?

In most development teams, the senior engineer usually takes the charge on paying down technical debt. This is a rational decision for every individual on the team, because each person who is not the senior engineer benefits from less work, but it is not the most rational decision for the whole team.

Below is an infographic that demonstrates the cycle of development and refactoring when only senior engineers refactor vs. the ideal cycle:

technical debt

When looking at these opposing cycles, we see that the payoff of the default state is not as high as the desired state. However, just like in the prisoner’s dilemma, there is a reason why most teams fall back into that default mode. In the vicious cycle of development laid out above, refactoring work often comes with high time pressure and risk. This type of refactor also comes with strong possibility of costly code breakages. The high stakes for these refactoring projects thus make it easy for team members to lay responsibility only on senior engineers, rather than coordinate as a team.

So how do we resolve this cooperation problem within a development team?

The first step is awareness and access to information. This is where quantifying technical debt is extremely important. If you don’t know how deep into the red you are, coming up with a plan to address this debt will be extremely difficult. You need to know how much work will be needed for weekly refactoring efforts

In order to gain an understanding on the amount of work that will be needed for refactoring, a date-driven team planning meeting needs to occur. Getting this type of data, requires setting up a feedback loop of work done within each sprint and seeing how much effort major refactors take up. The next step after developing a plan that shines light onto the problem of technical debt within the team is to use this knowledge and share it with junior developers.

Including junior developers into the refactoring process does two things:

  1. It resolves the problem of cooperation within the team and makes it easier to refactor tech debt before it reaches extreme levels.
  2. It creates accountability at all levels of the team hierarchy which encourages better development practices – stopping technical build up early on.

Ultimately, quantifying technical debt is the solution to the prisoner’s dilemma of technical debt. Once both prisoner’s know that cooperating leads to a better pay off for both of them and have the ability to communicate this they will work together. The same applies with development teams. Once it’s made clear that the current system in place is inefficient and the team communicates that working together will, in the long term, reduce the amount of high pressure refactoring – this will seem like the only rational option.

To read the original post visit here.

http://www.ontechnicaldebt.com/uncategorized/the-prisoners-dilemma-of-technical-debt/feed/ 0
In Praise of Doing Agile the Right Way http://www.ontechnicaldebt.com/uncategorized/in-praise-of-doing-agile-the-right-way/ http://www.ontechnicaldebt.com/uncategorized/in-praise-of-doing-agile-the-right-way/#comments Thu, 17 Sep 2015 13:48:50 +0000 http://www.ontechnicaldebt.com/?p=3588 read more]]> Agile has become an increasingly useful methodology for CIOs who need to meet the rapidly evolving demands of digital businesses. Where other traditional methods, like waterfall, failed to be responsive enough for the new digital environment that these businesses operate in – agile has been able to fill that void.

However, the most important thing to keep in mind when using agile is that in itself it is not a flawless development method and requires disciplined execution. The emphasis on execution is because agile isn’t one single method of development but a set of many methods that can be designed to fit a solution for any set of specific problems. Keeping this in mind will help make sure you’re using agile “the right way”.

So what does doing agile the right way entail?

  • Make sure that the software development process also includes business leaders, management, and users.
    • Comprehensive communication between those who are going to benefit from a project is necessary to understand how to address certain development issues. If business stakeholders don’t understand the limitations of agile, then impossible-to-meet deadlines and a strained relationship between technical and business leaders can lead to a poorly designed final product.
  • Understand that agile, on its own, is not the solution to every problem that can arise during the development process.
    • When Agile is used for a specific issue it needs to be employed systematically and fully embraced. For example, if you are going to be employing sprints for a certain part of the development process you can’t ignore that technical debt build up needs to be dealt with after each sprint. If you ignore technical debt, you’ll reap the short term rewards of continuous delivery but eventually stall as technical debt reaches untenable heights.

Ultimately, agile can’t be seen as the end all for good development practices. Technical debt is often pointed out as a consequence of poor development practices, and even more with the sprint-oriented agile methodology. Just keep in mind that there are caveats to using agile the right way.

Read the full article in praise of agile here.

http://www.ontechnicaldebt.com/uncategorized/in-praise-of-doing-agile-the-right-way/feed/ 0
Technical Debt Build-Up Fueled By Unfettered DevOps Practices http://www.ontechnicaldebt.com/uncategorized/technical-debt-build-up-fueled-by-unfettered-devops-practices/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-build-up-fueled-by-unfettered-devops-practices/#comments Thu, 30 Jul 2015 18:44:22 +0000 http://www.ontechnicaldebt.com/?p=3580 read more]]> What would you do if you found out that a major American automobile manufacturer knowingly picked from 27 versions of outdated, under-performing, and poorly built mufflers to place in a brand new model of a car? You would most likely respond in outrage if the product you are purchasing is being compromised by one component that is subpar to the rest. You would demand that rules be put in place to prohibit this. The automobile industry does not engage in such practices and no organization would give a designer free reign to place whatever product components she/he desired into a final product. It would mean mayhem for testing a product’s functionality if the same model had different versions of mufflers in place and would also hike up the cost of maintenance. But there is one highly used and important industry that does just this: the software development industry.

In a study released in 2015, large software development organizations sourced 27 different versions of open source components that had been used throughout 2014. In other words of 100 or so open source components – 27 versions of each component had been downloaded. That’s 2,700 downloads. The procurement of open source components is often a free for all. Some organizations, however, do have certain rules in place when it comes to open source procurement. For example, Google has restrictions so that no more than two versions of a given component can be downloaded. By simple arithmetic such guidelines drastically reduce complexity.

Open source cannot simply be be defined as a bad practice. Neither can devops, which promotes open source use in order to speed up development and improve innovation. However, when there is little oversight on how to execute the use of devops and open source, building up high levels of technical debt due to poor software supply chain practices should be expected.

Downloading components that are outdated, when there are better versions available, places speed above any other priority. This has its costs, which manifest themselves as technical debt and security debt. In order to properly avoid these consequences guidelines have to set in place for downloading software components. Just like Google, some kind of limit should be in place to keep unnecessary downloads in check. Again, just for the sake of simplicity keeping components downloads under control is helpful. But logically it also makes sense to only use components that are up to date and do not hold obvious flaws and vulnerabilities.

When your systems are not running on up to date software components the risks are high and the benefits are minimal. Improving innovation doesn’t mean just putting out software quickly, but improving the quality of what you are pushing out as well. Improving what components you are using to build your products is just the first step you need to take to reduce your technical debt and improve the quality of innovation you are giving to consumers.

To read the full post visit here.




http://www.ontechnicaldebt.com/uncategorized/technical-debt-build-up-fueled-by-unfettered-devops-practices/feed/ 0
Technical Debt, Transparency, and the Iron Triangle of Development http://www.ontechnicaldebt.com/uncategorized/technical-debt-transparency-and-the-iron-triangle-of-development/ http://www.ontechnicaldebt.com/uncategorized/technical-debt-transparency-and-the-iron-triangle-of-development/#comments Tue, 21 Jul 2015 13:30:07 +0000 http://www.ontechnicaldebt.com/?p=3564 read more]]> There are a lot of blog posts floating around out there that try to talk about technical debt in a new and interesting way. Few actually achieve this goal. There’s not much you can add to a concept that has been explained over and over again. This podcast with Microsoft veteran exec, Bill Bliss, gives a talk on technical debt that although not revolutionary, touches on some ideas about technical debt that are enlightening.

1. No matter what your company does, if you are relying heavily on software for your product’s success you are a software development company.

More and more we are beginning to see companies, which rely heavily on technology for their offerings, being managed by non-technical stakeholders. This has become the norm, but it causes a problem because these non-techies often forget that their businesses, at their core, are software development companies. When you forget this, you tend to mismanage your technical team: resulting in unrealistic deadlines and mountains of technical debt.

2. Technical and non-technical stakeholders lack of proper communication leads to a development black box (be aware of the iron triangle of development).

The barrier between technical and non technical people is an issue of language. Business and technical sides of an organization are unable to communicate their needs and limits effectively. Because of this, the technical side of a company ends up being a black box where non-technical leaders don’t understand their development teams and simply expect them to perform. This leads to an untenable relationship where development teams are expected to do things fast, cheap, and well.

The iron triangle of development says that this is impossible. You can do two of these things at once (fast & cheap, fast & well,  or cheap & well) at the expense of one. But, if you consistently build code quick and cheap – you will be creating technical debt.

3. Once you have technical debt, if you can’t communicate what’s so bad about it you will probably keep piling it on.

Keeping an eye on your technical debt can be incredibly difficult when you can’t communicate the impact it has on your operations. The underlying issue is that technical debt manifests itself, in the eyes of business stakeholders, as a tax. But those working on the technical-end feel the burden of technical debt heavily. It can manifest itself in scripts that take over an hour to run, breakages in code, and a brittle code base that makes adding features time consuming and demoralizing.

Communicating technical debt in terms of the cost/benefit of fixing or not fixing those areas with debt, is the best way to resolve the lack of understanding between the non-technical and technical dichotomy of the business. Once there is such an understanding, steps can be taken to reduce technical debt.

4. The ‘big rewrite’ can be a big waste of time.

The urge is often to rewrite a section that is heavily burdened with technical debt. This is a bit of a paradox, since once a section of code base reaches the point where a rewrite is warranted, it is probably too complex to be discoverable and be able to rewrite. In other words, the code that needs to be rewritten is so entrenched in the code base that rewriting it would be like changing a tire while the car is still moving. Ultimately, if the code does the job it is intended to do then keeping it is the best decision. If the decision has been made to rewrite, an API has to be built in order to wrap the code and make rewriting easier.

5. Be weary of open source, it won’t solve all your problems and may create new ones.

It must be kept in mind that technical debt is not always the result of bad architectural decisions, but the result of changing technological needs. Because of uncertain needs, businesses have started to turn to open source software – which creates another black box for business stakeholders in relation to the technology they use. A framework for decision making needs to be implemented when deciding what to build and what to buy. Buying packaged software can be useful, but also creates uncertainty on the quality of code within the opaque package. Transparency is always helpful when trying to manage technical debt and the quality of your software, but the expediency of buying something pre-made is also a benefit to business operations. Depending on what problem(s) you are trying to address lies the answer to whether open source is right for your business. If you are simply looking for 1 feature, then building it yourself makes more sense.

Ultimately, managing your technology assets needs to be a transparent and well documented process. Understanding between the business and technical sides of the organization need to be improved and made a priority because the success of keeping a clean code base depends on it.

To listen to the full podcast visit here.

http://www.ontechnicaldebt.com/uncategorized/technical-debt-transparency-and-the-iron-triangle-of-development/feed/ 0
How the Public Sector is Dealing with their Legacy Systems http://www.ontechnicaldebt.com/uncategorized/3558/ http://www.ontechnicaldebt.com/uncategorized/3558/#comments Mon, 20 Jul 2015 14:44:35 +0000 http://www.ontechnicaldebt.com/?p=3558 read more]]> There’s a new wind blowing in technology, specifically in the public sector, on how to handle the crossroads between systems that have been around for decades and upgrading to the latest wave of new technologies.

While this is a concern in every organization where technology is central to their functions (which in this day and age is every single one) – it’s a concern that resonates strongly in the public sector. Government agencies are often allergic to risk, which makes their speed and level of innovation slow when compared to private enterprises that jump on the chance to be first-to-market. However, there’s been a shift within government (exemplified by the Department of Housing and Urban Development) where CIOs are beginning to focus on modernizing decades old legacy systems. Such a transformation requires intense organizational scrutiny and oversight.

At the Dept. of Housing and Urban Development there has been a large scale move to consolidate or in-source many of its core systems. In 2014 they began to in-source their finance management and administrative functions to the department of treasury. This would help the agency to pay down its technical debt by narrowing the complexity of their systems while also removing barriers of scale for future development.

This is the best case scenario, where consolidating your systems reduces redundancies, dead code, and inefficient processes. But for many, solving the problem of technical debt in legacy systems is more of an overhaul process. Consolidation, is usually a safer bet for public sector organizations because it doesn’t add innovation but merely streamlines current processes. But we’re reaching a point where that just doesn’t work anymore.

Look to the recent events at the OPM – where 21 million past and present federal employees social security and other personal information where stolen – as an example of halted innovation that had a serious backlash. At the OPM, over a period of 7 years they received warnings that their systems were falling behind on security measures and on resources to keep their applications healthy. They failed to do heed these warnings and now there’s a long list of evidence demonstrating their incompetence. The culmination of all these failures? A severe data breach and the theft of millions of records.

This is the extreme case, but it exemplifies how handling innovation and modernization can cause severe problems if its not attended to promptly. This is what is so often preached in our posts on technical debt: if you don’t deal with it while its small and manageable, it will reach a point where things will go very very wrong.

To read the post on public sector technical modernization, click here.

http://www.ontechnicaldebt.com/uncategorized/3558/feed/ 0