If you only write one document

If you only write one document (as part of developing software), make it the test plan.

Do it before you start writing the code.

This applies to new features and bug fixes.

• This also becomes the spec.
• It allows you to know when you've written the code to make do everything you should.
• It will make working as part of a team easier.
• It will make code reviews faster and easier.
• It will make testing faster.
• It will make creating automated tests easier. (You can even write them before the code-TDD style.)
• It will make things easier when the customer/client/boss changes their mind or the requirements.
• It will make future maintenance and changes faster.
• It will make creating complete and accurate documentation easier.
• You are more likely to be creating technical debt that you're unaware of without this.

If you don't:

• There will be lots of guessing.
• There will be lots of unvalidated assumptions.
• There will be lots of repetition of effort. (Working out what needs to be done and how to do it.)
• More effort will be wasted on things that aren't important.
• Code reviews and testing of the code will be slower and involve more discussion and clarification.
• You are more likely to ship with bugs.
• Future changes (big fixes or adding new features) will be slower.
• Future changes are more likely to introduce other bugs or regressions.

Who said it doesn't matter

That someone admitted [bad practice the business would not like to admit to] is not the issue.

The problem isn't blaming who said it.

The problem is that it is the culture. 

Trying to hide the issue or blaming someone for admitting it doesn't help. It encourages bad practice, which really only makes things worse.

 

Detecting relevant content of interest

When AI is actually a bit dumb. 

Consider something I'm seeing a lot:

• Content (e.g. news) app shows lots of different content.
• You read an article in the app within a specific category.
• Several hours later, an automated backend process tries to prompt re-engagement.
• The backend process looks at what categories of content you've looked at recently.
• It notices a recent article that is in that category and is getting lots of views.
• The backend process then sends a notification about that content as you're likely to be interested. (It knows you read content in the category, and lots of people are reading this new article. It should be of interest.)
• But the "assumption" was based on a lack of consideration for articles already read. (It was of interest, that's why you read it several hours ago.)
• Enough people click on these notifications to make them look like they're doing a good job of promoting re-engagement.
• People click on the notifications because they might be related to or following on from what they read earlier and not realizing that it is the exact same article.
• Analytics only tracks openings from the notifications, not how much time is spent reading the article they were using to promote re-engagement.

Analysis of analytics doesn't flag this, and the opacity of "the algorithm" doesn't make it clear this is what's happening.

All the while, many people get wise to these pointless notifications and turn them off, and so many miss something actually useful in the future.

I know there are more complex and varied scenarios than mentioned above, including how the above could be considered a successful "engagement" in other ways.

The main thing I take away from this is that I don't want to be creating software that tries to do something clever and useful without being able to accurately tell it is being successful and providing value.

Creating something that is trying to be clever but comes across as stupid because it doesn't make wise or appropriate use of the information it already has does not excite or interest me.

Software development = basketball

This might be a leap but go with me for a minute.

"Lessons in basketball are lessons in life"

 

It's a cliched phrase that was drilled into me at basketball training camps and through basketball-related movies when I was young. We weren't just being encouraged (forced?) to learn lessons that would help us play better basketball, these lessons would help throughout our lives.

Thinking today about the importance of fundamentals, I wonder if the world would be a better place if more developers (had) played basketball.

Sticktoitiveness and software development

I recently heard that there is a common character trait among many developers in that they won't stop working on a problem until they've solved it.

I've always identified as having a similar but different trait, I won't give up when trying to solve a problem.

I came to this trait as a result of some of my first jobs in the industry. Due to the internet and world being as they were, and in combination with the companies, teams, and projects I was working on/with, there was no option to say "I don't know how" and give up. The problem needed to be solved, there was no one to ask who might know, and so I had to figure it out. That's what I was there for. That's what I was paid for.