olliesaunders

Nowadays I avoid building anything from source if there is a binary I can download and everytime I have to build from source I cringe in apprehension as to whether it will work or not. Too often, if something fails, I just give up.

OK, I’m not really this aiming this criticism at the LFS project. I’m really just griping about shitty this aspect of software development in general. People should be working on solutions to these problems. Or maybe this is a problem with me. I’d be interested other’s opinions.

Video gamers can supposedly differentiate between tones more similar to one another than non-gamers. Perhaps, if you made a theme of very similar colors, you could achieve the same benefit from programming. Although I suspect it might not work because the difference in the colors has to have significance for your brain to really start paying attention to it. So you could have a color-sensitive language. Or maybe color could be the only significant thing, then you could just bind each character to a color in your text editor and use a normal language.

While walking in the wood today and looking at the detail on the ground and searching for ripe fruit in the trees I was thinking about how our brains are really good at picking out specific visual things from noise and how more complex visual things are sometimes easier to recognize than simpler things. Also its possible to get really good at picking out subtle clues from very complex input: think about a native American Indian’s ability to track moving animals over long distances.

So I think what would be really cool is to have a way of representing each function of a program as a visual form, ideally a 3-dimensional one. You could then look at these form and over time you would start to be able to see certain things about the function just by looking at the forms. I wonder if that might be a much faster way of searching for specific things within a large body of code such as you might do in a security audit than actually reading through all the code because it taps into the innate concurrency of the right-hemisphere.

There would be some difficulty would be in generating appropriate visual forms. The form has to be meaningful. The ideal would be if it were meaningful to the point where somebody well used to them could write the code a form represented just by looking at the form or, at least, infer the gist of it. Of course you don’t have to limit yourself to one form per function, you could have 10 different forms per function, each representing different properties, or forms generated from by dividing the code in lots of different ways (not just functions). Or maybe you could simplify everything I’m saying here and just have a lot more statistical static analysis of code then displayed with charts and infographics.

This wiki has been around for a number of years and I always thought it was a great idea. Shame it hasn’t really seemed to have taken off.

You can be hygienic and still cultivate behaviors that increase your exposure to safe levels of microbes. For instance, I always wash my hands after using the toilet but I’m less concerned than most about the use-by dates on food products and prefer to make decisions based on my sense of smell and taste. Not sure if that’s a good example.

Besides, if advertising didn’t exist or was illegal or something, couldn’t we just create a webapp to let people exchange information about interesting products and services and that would be the end of that problem. No need for information about products and services to be so pervasively integrated into every nook and cranny of our society.

> I think we could advance the state of the art if were to find a way to quantify engineering debt. As a starting point I suggest a ratio of line changes aimed at servicing vs. line changes aimed at creating new features. If 100 lines of new functionality require 10 lines of base code changes, the debt is low. The opposite is true, the debt is high

That’s the thing with this debt. You can only quantify it once you’ve paid it back because its quantity is predicated on the cost of paying it back, which differs depending on your aptitude for doing so. And because it’s invisible neurotic programmers like me can start to actively fear it, leading to poor decisions.

Citation needed.

In designing another system recently, I wrote down my entire thought process as it developed in the form of questions and answers to myself. When I read it back now I can see how I had this mixed up set of ideas and was actually quite confused. Then, as you read down, things start to become clearer and ideas become more developed. I guess it still has quite a long way to go as well because things certainly aren’t as clear as I would like them to be.

So the point I’m making is that definition and clarity can take as long, and sometimes--although I think this is infrequent--longer, than the software development.

As for the question of whether you should blog about it. I think it’s a difficult call. In a way you could say this story has wasted everyone’s time because I still have no idea what the app drupeek’s developing is about. But on the other hand we wouldn’t be having this conversation now were it not for it.