Per connascence.io: Connascence is a software quality metric & a taxonomy for different types of coupling. I use it as a taxonomy and the mere concept is, to me, of huge help in both building and maintaining systems. Understanding and actively tracking connascence surfaces dependencies between components that sometimes never even touch directly. I use it to track values, names and algorithm dependencies between components written in different languages and that are developed in different development lifecycles.

NOTE: These are rough notes imported from… Notes on the book “A Philosophy of Software Design”. Btw - love the title and the use of “a philosophy”. Too many folks believe that their philosophy is the philosophy. Solving pass-through variables through global - Paul and I talked just about that recently. Globals solve the original problem but introduce other problems: harder to understand, harder to unit test, higher dependency on the surrounding process state.

At the end of 2016 one of my ex-managers approached me to see if I wanted to do a series of lectures for one of the courses on software development that he was designing at the time. The purpose, if I recall correctly, was to enable engineers from other professions to transition to working software developers in 6 months. At the end nothing came out of it but I just stumbled on the list of lecture themes that I wrote at the time so here it is - with warts and all (it clearly becomes rather sparse at the end).

Reading this article: Software Architects: Do We Need ’em? Great quote and often the hardest thing to do: “I wasn’t the one pushing things in the wrong direction, but I should have been the one to stop it.” – Chad Fowler The way I see it, the technical problems are mostly easy and it’s the people problems that are predominantly hard: communication, coordination, dominance games, different levels of commitment, likes/dislikes biases and so on.

Note: an early draft imported from heavily broken LinkedIn draft (they must have done a lossy migration in the past 10 years). Leaving it pretty much as it is with light edits for clarity and formatting. I’ve been programming for more than 25 years now, almost 20 of it professionally. As with many of us it started as a hobby and then somebody offered to pay me for it and here I am.

I’ve been thinking on HTTP API versioning lately. Troy Hunt’s Your API versioning is wrong… is the 1st hit when googling “HTTP API versioning” but I think it’s limited in its scope to dealing just with GET verb in public non-authenticated APIs. This isn’t explicit in the article but Troy was writing about the API to his Have I Been Pwned public service which only serves GET requests. I want to extend this discussion to other HTTP verbs and also authenticated APIs.

For when nothing else will to place a warning, in your code, to your future self or your fellow developers paste this: // // NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE // NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE // NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE // NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE // NOTE NOTE NOTE NOTE NOTE NOTE NOTE // It looks like hell here but trust me - after you copy/paste it into your editor, it will look something like this:

In the wild I sometimes see the following as implementation of NSCopying:copyWithZone: -(id)copyWithZone:(NSZone*)zone { MYClass* copy = [MYClass new]; copy.property1 = self.property1; ... copy.propertyN = self.propertyN; return copy; } This is wrong as accessing the copy and the original objects through . during the copying process itself must be avoided as each of those . may actually introduce side-effects. We are copying data here and the resulting copied object should faithfully reflect the state of the original object, not invoke methods on either of these objects.

I just figured out what bothers me the most (among several other things) about Objective-C: in its current incarnation it is being to too clever with names. It heavily breaks the principle of least surprise (in this case being: “name things as I wrote them, don’t make stuff up”) I figured this out by working with Angular-JS and its attributes on directives. Namely, it also tries to be too clever with names and translates e.

Last night I presented a small introductory talk on Swift under hopefully-not-too-pretencious name of “Swift Design”. I talked about what could have been the primary goals of Swift and how Apple has achieved them, doing sort of speculative reverse engineering of Swift design choices. I have uploaded the PDF and the source of the presentation for the excellent Deckset app. The talk went on for exactly 30 minutes (in line with the two practices I did today) and then we had a Q&A session for about 25 minutes (though obviously I insisted from the start that I’m far from any kind of Swift expert).