Archive | technicaldebt RSS feed for this section

Startup Suicide – Rewriting the Code « Steve Blank

Perhaps the most dangerous side-effect of embarking on a code rewrite is that the decision condemns the old code before a viable alternative exists. Who is going to want to work on the old code with all its problems when the VP Engineering and CEO have declared the new code to be the future of the company?  The old code is as good as dead the moment management introduces the word “rewrite.”  As a consequence, the CEO has no fallback. If the VP Engineering’s schedule ends up taking four years instead of one year, there is no way to make incremental progress on the new features during that time.

(Full Story: Startup Suicide – Rewriting the Code « Steve Blank)

Gartner pegs global IT 'debt' at $500 billion and growing | ZDNet

According to Gartner, what organizations have is a “backlog of deferred liability,” which can be looked upon as a debt, incurred over a period of years, that will need to be paid off at some time. The recent economic downturn has exacerbated this debt, since projects and maintenance have been deferred. “This ‘IT debt’ is a hidden risk for many organizations, and given continued tight economic conditions, this IT debt is growing, and the associated business risk is growing,” the consultancy warns.
(Link: Gartner pegs global IT ‘debt’ at $500 billion and growing | ZDNet)

Technical Debt: Refactoring vis-a-vis Starting Afresh

Before opting for new software (in preference to refactoring the old software), I would recommend you compare the economics of the two option. My rule of a thumb for the calculus of introducing new enterprise software to replace legacy software is straightforward:

For a period of about two years, assume the run rate for dev/test/support will be 150% of your current investment in development, test and support of the old software.

Please note that the 150% figure is just the expected run rate for running the new software alongside the legacy software. You will need, of course, to add the cost of acquiring/producing the new software to the economic calculus.
(Link: Technical Debt: Refactoring vis-a-vis Starting Afresh)

Yahoo pays its 'technical debt' with IT overhaul

“One of the things you have to understand. Yahoo’s IT wasn’t built on one uniform infrastructure. It was built by acquisition and building up properties,” says Pullara. “We had a lot of technical debt.”

Sound familiar? Yahoo went through what every companies does. Simply put, it had too many legacy systems that were strangling the company. The biggest hurdle: Resisting the urge to build your own stuff. Pullara says:

When building your own systems or should you be leveraging the open source community. Are these the kinds of things as opposed to reinventing the wheel. What we’re finding is not reinventing the wheel has a great benefit.

Here are some of the key parts of Yahoo’s IT overhaul and my notes.
(Link: Yahoo pays its ‘technical debt’ with IT overhaul)

Link: Coding Horror: Paying Down Your Technical Debt

Coding Horror: Paying Down Your Technical Debt
Beyond what Steve describes here, I’d also argue that accumulated technical debt becomes a major disincentive to work on a project. It’s a collection of small but annoying things that you have to deal with every time you sit down to write code. But it’s exactly these small annoyances, this sand grinding away in the gears of your workday, that eventually causes you to stop enjoying the project. These small things matter.


Follow

Get every new post delivered to your Inbox.