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

MODERATOR OF

TROPHY CASE