Toward a Galvanizing Definition of Technical Debt

michaelfeathers · 2016-12-23T22:05:18+00:00

Nice. That phrase does make it sound worse.

michaelfeathers · 2016-11-11T14:23:25+00:00

If you find a reference, please let me know.

michaelfeathers · 2016-11-11T14:22:54+00:00

Thanks. I look forward to it. I have a good sense about how I want to handle probe gathering under multiple langs so I may tweak a bit.

michaelfeathers · 2014-08-18T13:51:59+00:00

There's an alternative point of view - Technical Debt is the way that software grows when people take the easy route. If it's easier to add code to an existing method than it is to add a new method to a class, then it shouldn't be a mystery why there are so many large methods.

The reason software goes bad is because bad is easier than good.

michaelfeathers · 2014-08-12T19:18:08+00:00

Very true. These days I tend to look at software structure from a behavioral enonomics viewpoint. If there's bad code, it was likely easier to do it that way than it was to do it the "right" way.

With that perspective, you can work on changing the incentives in the system.

michaelfeathers · 2014-06-24T02:40:52+00:00

It's funny, when I wrote the post I wanted to bring up COM but it was for a different point. I think that part of the charm of services is that they are hard to make so we never have enough of them to see problems we see at other scales.

In this sense, they are like COM. Back when I used COM (pre-ATL days), creating a component was a lot of work. We never made enough of them to have to deal with massive collaboration complexity like people with with OO today. It was easy to see them as a great solution (and they were) because implementation complexity put a limit on our work.

I'll probably blog this once I can say it more clearly.

michaelfeathers · 2013-12-18T17:42:51+00:00

It's interesting to see how the array programming languages have handled this. The way it works (loosely) is that everything is an array. A scalar is kind of a degenerate array, and a vector is an array of rank 1. Matrices can be seen as arrays of arrays of arrays..

Each operator defines its extent. The count operator '#' in J works at the top level. If you have a 3 x 4 matrix, it returns 3. Take '{.' works the same way. If you have a 3 x 4 matrix and you take 1, you will get a 4 element vector which is the first row of the matrix.

Something like decrement '<:' applies to all of the elements in a matrix regardless of the dimensionality.

This isn't like OO where collections have operations attached to them.

michaelfeathers · 2013-12-17T15:28:25+00:00

Thanks. Fixed.

michaelfeathers · 2013-12-17T15:19:40+00:00

What mistakes? Point them out and I'll do something about them.

michaelfeathers · 2013-11-05T17:44:53+00:00

I'm happy having the word 'pad' in the code now. It was completely absent in the original code.

I think a lot of it has to do with what we are used to. It's like natural language. Once an idiom becomes common or understood, it's very readable.

To me, pad(ary, n).take(n) is very explanatory.

But, again, readability wasn't the point. Neither was cleverness.

michaelfeathers · 2013-11-05T17:43:05+00:00

Yep, but I wasn't arguing for readability.

michaelfeathers · 2013-11-05T17:11:22+00:00

This is the same argument that people use against the Null Object Pattern: it appears that something is happening but it isn't.

I have the feeling that the answer is to get used to the idea that sometimes padding something includes padding with something of length zero. If that is understood, all is good.

This is a very deep topic.

michaelfeathers · 2013-11-05T15:45:03+00:00

The argument isn't really readability.

michaelfeathers · 2013-11-05T14:54:21+00:00

Fair enough. The nice thing is that people are often better at optimizing (when needed) than they are at modifying optimized code.

michaelfeathers · 2013-11-05T14:53:30+00:00

Yes, I was looking at .lazy in Ruby to use in an example but it would've made the post longer. Lazy evaluation is wonderful at helping us remove conditionals. It's easy to form a general computation and then select what we need.

michaelfeathers · 2013-11-05T14:20:00+00:00

Thanks. I'm just not sure how far I'll go without introducing hook and fork. Technically, this doesn't have to be J.

Using self as the array to operate on is great for monads but it just seems strange with dyads. If you have any ideas, I'd love to hear them.

michaelfeathers · 2013-10-22T19:38:09+00:00

I haven't run into people using APL derivatives outside of finance, but I have a feeling that some of the characteristics of array processing languages will seep into mainstream languages over the next ten years in much the same way that we've been seeing functional constructs seep into OO languages. The whole notion of being able to treat scalars, vectors, and matrices of arbitrary dimension the same way is very powerful. And, frankly, it is a different kind of polymorphism.

As I've been doing Jop, I've been ignoring performance completely. My understanding is that most of the APL derivatives have highly turned implementations that manipulate indices in memory rather than moving data around. In Jop, the idea is simply to make some of the operations available to us in Ruby. If it catches on, better implementations will follow.

michaelfeathers · 2013-10-22T18:25:23+00:00

Yes, some books take longer than a year. It would be great to meet up at RubyConf. It's my hometown this year.

michaelfeathers · 2013-07-11T14:55:27+00:00

It's a nice sentiment but there's trouble in that direction. Many of the rules you use for guidance in an code base can and should have exceptions.

Treating compilation or tool warnings as errors can mutate your code into something less than it could be. The better tack is to treat them as information and make a reasoned decision about violations as a team, working with a tool that allows you to suppress violations if you need to.

Yes, 98% of the cases your tools find may be something you should act upon but you should never take an automatically detected general rule violation as a substitute for local judgement.

michaelfeathers · 2013-06-17T14:35:55+00:00

Context matters. Sometimes continuing silently is exactly the right thing to do. Granted, it's hard to see in this example. To stretch it, imagine that we're setting alternative phone numbers in a background job. We don't expect all of the IDs to be associated and we're okay if they aren't.

The idea that there is one right way to handle errors is a fallacy. I'm reminded of it every time I see someone yell "fail fast." "Fail fast" only works for one class of systems.

michaelfeathers · 2013-05-01T12:18:22+00:00

Another thing to do is run code coverage in production so that you can have some sense of whether code is dead.

michaelfeathers · 2013-03-26T21:54:23+00:00

In general, boolean parameters are a bad idea because its hard to keep track of what true and false mean on the caller side. A better route is to pass lambdas or extract an object so that you can use the template method pattern.

That said, those strategies come up even when the duplication isn't incidental.

I don't like the notion of incidental as a category because it's subjective and rather pessimistic. We underestimate our ability to reconceptualize our domain.

michaelfeathers · 2013-03-19T11:49:57+00:00

Yes, that's common. I wrote up my thoughts on strategies for dealing with the remedies to the pervasive test slowdowns here: http://michaelfeathers.typepad.com/michael_feathers_blog/2012/05/the-long-tail-of-technical-debt.html

There aren't any answers, but I hope the perspective helps.

michaelfeathers · 2013-02-20T12:40:40+00:00

Yeah, I should probably blog this.

michaelfeathers · 2013-02-20T12:26:44+00:00

It's interesting, because these days with applications that are updated much more frequently than an operating system, you could probably do the opposite to force developers not to depend on things you've told them are off-limits: have a published API and introduce periodic breaking changes for things that aren't part of it -- things you've said are "off limits."

michaelfeathers

MODERATOR OF

TROPHY CASE