Technical Debt Quotes

We have entered an era where the kinds of data and analyses that people run have gotten incredibly complicated. So you have researchers using sophisticated software programs that they probably don't understand but are generally accepted and everyone [in the field] uses.

Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves.

In software engineering, we have the term 'technical debt.' When you don't do a job correctly, unaddressed problems become harder and harder to solve.

There will never be a day where the depth of integration, unless it was all built from the bottom ground up, will be integrated as any of us would like.

All software sucks.

Inside every large program is a small program struggling to get out.

Early in my career, I was involved with engineer-led projects, where designers came in late in the game and were expected to put lipstick on an existing code base. This almost never works.

Prolific programmers contribute to certain disaster.

Computer Science is the only discipline in which we view adding a new wing to a building as being maintenance.

All the PHP code I've seen in that experience has been messy, unmaintainable crap. Spaghetti SQL wrapped in spaghetti PHP wrapped in spaghetti HTML, replicated in slightly-varying form in dozens of places.

I think a lot of great software has been written by people who are scratching a short-term itch, something which has been niggling them for ages, but in the back of their mind they’ve got a wonderful long-term plan.

"Legacy code" often differs from its suggested alternative by actually working and scaling.

Software is like gardening - one day I'll go behind the shed and clean up. But if nobody ever goes there, does it matter a lot?

FORTRAN, the infantile disorder, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use.

Complexity control is the central problem of writing software in the real world

The combination of threads, remote-procedure-call interfaces, and heavyweight object-oriented design is especially dangerous... if you are ever invited onto a project that is supposed to feature all three, fleeing in terror might well be an appropriate reaction.

It's easy to make mistakes that only come out much later, after you've already implemented a lot of code. You'll realize Oh I should have used a different type of data structure. Start over from scratch.

I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say Yeah it works but you're leaking memory everywhere. Perhaps we should fix that. I'll just restart Apache every 10 requests.

The most disastrous thing that you can ever learn is your first programming language.

I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

Systems program building is an entropy-decreasing process, hence inherently metastable. Program maintenance is an entropy-increasing process, and even its most skillful execution only delays the subsidence of the system into unfixable obsolescence.

I think complexity is mostly sort of crummy stuff that is there because it's too expensive to change the interface.

There's an old maxim that says, 'Things that work persist,' which is why there's still Cobol floating around.

The Wesnoth devs are good but not exceptionally so, and we're weighed down by a crappy implementation language (C++). Nevertheless our productivity, in terms of goals achieved per hour of work, is quite high.

Be suspicious of any work that is not building product or getting customers. It's easy to get sucked into an infrastructure rewrite death spiral.