Why technical debt is key to building better software

Debt.  What does it evoke for you?debt

Greece begging on its knees for another bailout? The Everest-size mountain of the United States national debt? The horror of losing your home and car to creditors?

Most people think debt is bad. But that’s not always true.

Properly managed, technical debt is a hallmark of optimal software development.

It is something everyone ought to be familiar with.

The tug-of-war between features and maintenance

At the heart of every software publisher, there is a conflict between the need for new features to sell and the need to make sure the software works.

If you’ve been working for some time, you’ve probably come across two types of companies.

In a commercially dominated firm, the sales team sells tomorrow’s features and the engineering team is playing catch-up. As code maintenance falls behind, quality deteriorates, exposing the product to performance, scalability or security issues.

In a technically focused company, everyone dreams of creating the next Facebook. The engineering team won’t release the software until it meets lofty technical goals. With no product to sell, the company risks running out of money before its first release.

Thankfully, it is possible to find a happy medium. And this is where technical debt comes into play.

The mechanism of technical debt in agile development

Agile methods consist of short sprints that produce working software to show customers.

In a sprint of, say, a couple of weeks, there isn’t time to introduce new features and tie up all the loose ends. Corners must be cut.

Technical debt is the concerted decision to cut those corners and the documented number of “story points” required to fix the software.

For example, the sales team may ask to include a new feature in the next sprint in order to win a customer. The engineering team responds by building the feature in a fraction of the time it requires.

Once the new customer is on board, the engineering team can spend time rewriting the feature correctly and repaying the technical debt.

Conversely, the engineering team may devote an entire sprint to repaying accumulated debt to avoid serious issues down the line.

Because the consequences of ignoring the debt are clearly explained in the sprint backlog, the sales team can accept the absence of new features in the current release cycle.

As we can see, technical debt is flexible and constantly evolving. Small amounts of debt are accepted in the current sprint and eliminated in the next.

It’s up to the company to decide how to allocate development time. For example, 40% may be invested in new features, 20% in customer-specific requirements and the balance to repay technical debt.

Benefits of technical debt

Technical debt acknowledges the company’s need to satisfy customers. It also encourages the engineering team to explain in layman’s terms the reasons why the debt should be repaid.

Instead of a tug-of-war between conflicting interests, technical debt brings transparency and consensus to the software development process.

The engineering team gains in respect—and job satisfaction—because others in the company see the value of its work.

How about you?

Are you familiar with technical debt? Do you think it could help your company work better?

Let us know in the comments below.

Are You Ready for a Web Browser-Based IDE?


Admit it. You’re skeptical.

Is a cloud-hosted integrated development environment really possible?

Sure, you’ve seen applications such as MS Office—and even your favorite games—move to the web. But those applications are run-of-the-mill.

An IDE, on the other hand, is a complex tool. Is a browser-based IDE even advisable? You can’t help wondering …

The web reinvents itself

Over the past 20 years, we’ve seen the web transform itself beyond recognition, moving from static HTML pages to web 2.0 and now HTML5. Today, even highly interactive applications are web-based, with Google’s Chrome OS playing a significant role in shaping the web.

The web’s dramatic development traces back to several key technological shifts. First, virtualization has commoditized the IT landscape, initially on premises, and now on the cloud. Second, cheap cloud-based computing coupled with affordable high-speed Internet connections has made the widespread use of web applications possible.

In turn, web applications have brought low costs, interoperability, and ease of integration. Each web application operates as a service, seamlessly communicating with other web applications via APIs. Users have been quick to embrace web apps, caring little what lies behind a service as long as it runs.

Mobile applications are now becoming the interface of choice for the general public. It will soon be the case for businesses. Increased CPU power allows today’s mobile devices to run sophisticated web apps, rapidly turning native applications into a thing of the past.

Browser-based development is already happening

If accessing services through a browser has become the new norm, should you be surprised to see it applied to software development?

You’re probably already using a browser-based case system, as well as virtual machines to test and demo your software. You may be storing your source code in GitHub, the popular web-based repository. You likely run unit testing in a hosted environment, whether on Azure, Amazon, SoftLayer or on any other standardized environment (J2EE/node.js/LAMP). You may even use JSFiddle in a browser to test your JavaScript code.

But when it comes to your integrated development environment and local development server, you feel those are different. Why?

Introducing the ultimate IDE

There are no good reasons why an IDE should not run in a browser, with a backend as a service. In fact, there are excellent reasons to switch as soon as technology makes it possible.

First, having a worry free and complete back end of your development environment will help you focus on what is really important: building great software that users love. Software development in a browser cuts ties with a specific machine, location, and time. It brings down the cost of the hardware and software you use and of its associated maintenance.

So prepare yourself for the inevitable. Get ready for your new, browser-based IDE!

PS:In case you are wondering: yes, Servoy is spending serious research in this area.