Nonreligious Articles of Belief

Nonreligious Articles of Belief

Yeah, this is another good thing to get out of the system. As with everything I say, it should be looked at as more tentative than absolute, even when formulated in a creed-y manner. I've thought about these things for a long time, and I believe writing this does me good, mentally.

So, I hereby present: six tentative beliefs of mine. A short version of, and perhaps a table of contents for, the longer version that is 70% done. I just wanted a short version out now.

I believe useful estimation is impossible in software development. (Of course 'estimation' with no further qualification is possible, duh...)

I believe interfaces types are needed to scale well, and 'distribute' well. At least type-'consciousness' is needed, but actual formal types in languages are better, because they can be processed by machines.

I believe organizing code into features or modules is superior to the common layered architecture default.

I believe polyglot programming is really difficult, a really big risk. Something to avoid, the more the languages differ. And one has to consider incongruent data types and gaps in tooling more than just different syntax.

I believe databases as entities separate from the application is one of the things that makes software development terrible. Also, see polyglottism.

I believe optimization (I mean that thing that compilers or query engines do for us) is kind of useless because it is unpredictable, unreliable.

So, in closing; I believe that some of the common thinking and so-called best practices make development projects not scale well, make code less understandable, make tooling harder, make analysis harder. And make me depressed. When in contact with them. And that is one of the reasons for this article. 

Three Big Bad Things

Aha, I'm writing about motivation again. And this time I'm motivated about it. 

I want to just get some things out of my system. The theme is, sort of, things about software development that have been sort of depressing. If I write it up, and put it out there, it might bring about a relaxed state of mind, I hope. 

So, there are mainly two things that are, or have been depressing. Well, actually, one thing that has been depressing, and one that only laterly has crept up on me as a factor of un-motivation, or whatchamacallit. 

Thing one, is this thing about estimation. Thing two, is about the meaning of doing things; and particularly in this case, the point, meaning, or 'why', of developing software. 

Uh, wait, there are actually _three_ things about developing software, that are cause for suboptimal states of mind. 

Third thing: fuck there are a lot of bad ideas, tools, libraries, methodologies out there, some of which I have had encountered. Note that I could not really say 'had the unfortunate luck of encountering' or some such; because it's inevitable to come upon these things, so I don't know if I've been particularly unlucky here, and there might be much worse things, that I've had the luck to not have to contend with. 

So; well I might actually say that the idea about estimation is one of those bad ideas, or methodologies out there. But it is such a big thing with software development. It's inevitable, sort of; I might give the anti-NoEstimation camp half a point there, about it being a fundamental part of human activity, the human pattern of behavior, or that wonderful expression: The Human Condition. OTOH, I am not sure the NoEstimates crowd really disagrees. It's all a bit muddled. The subject matter is muddled itself, by its very nature. 

But I am not writing to set anything straight. I'll let it be muddled. I only intend to write about what I have been thinking about all of this, for the last few years mainly. 

Actually, estimation might be a blog post all unto itself. And so could the meaning or why of developing software. And also the suckiness things. So, that's three blog posts queued up to write. And I feel good about that. 

Last of the month

Whoa: last day of the month again. Happens all the time. I'll just put up a placeholder for now. I want there to be a post every month, and apparently I am not above cheating.

Ten-minute Soul-selfie.

Ouch, hours left of January, but I only have a few minutes to bring together some bits of text from some drafts I made for a more ambitious post.

I think I may just be succeeding in overcoming the major obstacle to worry-free life: the friction/motivation problem. I have been trying to write a post about motivation in particular, a few drafts are the result. I will probably turn it into a blog post here.

For this post, among other bits and pieces, I made a list of motivators and turn-offs, because my current thinking is that it might be good to self-identify of sorts. Painting yourself in a good corner.

But, I'll just make do with my general principles.

Possible demotivator: seemingly pointless businesses. Immoral or amoral could be an interpretation. Examples: the gaming or gambling industries. Not that I could not work for them, but it'd have to be mostly for the money; short term, unless I would be in dire straits, of course.

Possible motivators: utilitarian stuff. Examples: medical stuff; science, research; bioinformatics; tools like travel planners; knowledge, education; or the super-meta-good of them all: developing computer meta-software, such as developer tools, better databases, etc.

Techical demotivators: high-friction technologies. Impedance mismatches, misadaptations, unsuitable tools. ORM. Slow tests. The common arbitrary project structure. Motivators: the opposite. Well, this actually demonstrates that technologies can really only be friction. You want low friction, small demotivators. 

Psychological demotivators: gung-ho-itude. Opinion. Attitude. Pessimism, optimism. Dis-humbleness. Self-evidential, gut thinking. Common sense. Motivational speech, motivational travels, motivational money (besides pay, of course). Paradoxical, huh? Nope. I wrote a draft post to explain this from how I believe creative processes work, but look up recent motivational research that shows this result.

Well, got to be going.

ByteArrayOutputStream Checked Exceptions

Just realised...

ByteArrayOutputStream actually doesn't declare 'throws IOException' on the methods it does override. I thought it did, because the method I use all the time, write(byte[]), does declare throws IOException, just to annoy us.

What it could do, but doesn't do, is that it could override the other methods so that you don't have to be annoyed by their declaring throws IOException, even though it will, of course,  never throw them.

Checked exceptions...yeah, that experiment turned out great.


----

Update: Here's a variant of FileInputStream which avoids checked exception in try-with-resources; which you could instantiate inside of a utility method, say 'public static FileInputStreamNoce istreamForFile(File srcFile)' wherein you catch FileNotFoundException.

 public static class FileInputStreamNoce extends FileInputStream {
  
  public FileInputStreamNoce(File file) throws FileNotFoundException {
   super(file);
  }
  
  /**
   * This avoids having to catch checked exception in try-with-resources.
   */
  @Override
  public void close() {
   try {
    super.close();
   } catch (IOException e) {
    // well, I don't know what to do here. Log? Re-throw wrapped inside RTE?
   }
  }
 }
 

In-App Web Browser Security

Don't give 'foreign' credentials to applications/apps. They might steal them. For example, if an app wants you to connect to your Facebook identity in an in-app browser. The information fed to an in-app browser can be read by the application.

http://furbo.org/2014/09/24/in-app-browsers-considered-harmful/
http://inessential.com/2014/09/24/craig_on_in-app_browsers [via]

Trying IntelliJ

One or two months ago, I tried the NetBeans IDE. Editing was painfully slow. With reservations for the unlikely possibility that it has something to do with my local environment, I can't understand how you can release something like that.

Now, I'm trying IntelliJ. It has pretty solid key bindings emulating the Eclipse bindings, which is great for trying out your normal activities. It also comes with Subversion built in, which is lucky for me because that is what I use when programming on my own.

With only a subset of my needs tried out, it's looking good. I miss two things so far: the linking of current open file to the file hierarchy, so that it (almost) always shows in the file tree; and, I haven't managed to see output from debugging/running. I fear this might be that IntelliJ won't run code until there are no errors, even in unrelated code, and I couldn't find a setting to allow it. (Or maybe it did start my main(), but I didn't see it?)

Other promising areas, both from seeing it first-hand and reading comments to that effect, is the indexing engine. Haven't tried refactoring yet, which is also important. I hear debugging is also faster, which is good. Eclipse's debugger is OK, most of the time, but sometimes grinds to a frustrating stand-still. I think that is caused by the mis-designed communications protocol, e.g. it will try to send a whole stack trace in one go, which is bad for example in the common scenario of recursion gone infinite. I noticed the option of using 'shared-memory' in the IntelliJ debug settings, which might help (but suspiciously not turned on by default?).

So, in summary, trying out IntelliJ can be recommended for Eclipse users, thanks to the ease of getting into it.