My Pinned Wiki Post Template

If you use this, please link to this blog post.

This is our Wiki

There are many like it, but this one is ours.

Our wiki is our guide. We support our wiki through comments and additions.

Without updates, our wiki will become outdated. Team members will become frustrated when information is missing or no longer correct. Being a good team member includes being a contributor to the wiki.

That cool reference you found that you will always remember? One day, when you need it most, you will forget it.

That awesome solution to a code or design issue that is perfectly clear and understandable now will look like a foreign language in 2 years (months, weeks, sometimes even hours). Add an explanation to the wiki.

When in doubt if something should be added to the wiki, add it. It can always be deleted later.

This is your wiki. Keep it clean but not too lean.

The Architect
(A serious parody of The Rifleman’s Creed )

(“Obligatory WIki Photo” by cogdogblog is marked with CC0 1.0. To view the terms, visit https://creativecommons.org/publicdomain/zero/1.0/?ref=openverse.)

If you found this interesting, please share.

© Scott S. Nelson
eBook Transition legacy systems

Rumors of Death Once Again Exaggerated…and Misplaced

I freely admit that I often run out of things worth saying. Lately, I have been rooting through my old LinkedIn posts for reusable gold and dug up this gem today (if Google stuck an add right below this, keep scrolling to the LinkedIn post):

To save you scrolling through the glitchy LinkedIn iFrame, it is:

Scrum is dead: Breaking down the new open development method

It is one of those that I posted with no context, which is a habit I think I will break starting today. Anyway, I went to re-read before re-posting, especially given the show-and-awe headline. Well…turns out Scrum really isn’t dead (gasp!). Other than a theme based on a very narrow view of how software is built, the article does have some valid points about good habits in open source.

What hit me was the irony. The conclusion has a link to a GitHub repo that has not been updated in many years. The main link on the page points to a site dedicated to the articles’ key concept. Well, I assume it used to. Currently it goes to one of those cheesy, spammy Buy this domain pages.

I’ve certainly written my own poor predictions over the years. And, come to think of it, my domain changed since then, so any links to those errors publicly posted will have a similar result. And so will the correct ones.

This morning ramble brought to you by PTO and writing before coffee.

If you found this interesting, please share.

© Scott S. Nelson
Empty meeting room

Be Prepared for Meetings

The concept seems like a no-brainer, and maybe it is just my personal experience, but anytime a poll of the meeting attendees is run asking if they reviewed the material sent prior to the meeting, the overwhelming majority response is “no”.

I was reminded of the importance of being prepared while listening to an episode of one my favorite podcasts, “Think Fast, Talk Smart” (please see my YouTube channel for a link to the podcast playlist and subscribe to my channel while you are there so I can finally get a vanity URL). The episode was titled Communicating Our Mistakes: How to Avoid Common Flaws and Make Better Decisions, which I admit was not one of my favorite episodes, but it did spend some time on this topic of preparation, which triggered a confirmation bias response from me. It started with a learning approach where the teacher asked students to complete the lessons before the lecture so that lecture time was spent building on top of that, then moved on to how meetings are more effective if people review the material in advance and discuss in the meeting…

[sounds of wood scraping across the floor as the author pulls his soap box out]

There are corporate cultures where materials are not provided in advance, probably because of the tendency for people not to review them. This makes the problem worse. These same cultures also frequently have meetings schedule with no agenda. I had someone on one of my teams who refused to attend meetings without an agenda. It was difficult for me to fault him, as I agreed with his reasoning.

People hate meetings because they are often inefficient and inclusive. My approach is to go the opposite direction of those who stop sending the material in advance and including agendas: I avoid reviewing the material in the meeting and instead advise those who didn’t to take notes and review it after the meeting. Depending on the purpose of the meeting, I may just reschedule it and advise everyone to come to the next meeting prepared. This may seem anti-[your pet sentiment here], but my experience has been that people become much more productive when they come prepared as a result of the meeting being more productive and few meetings because things were accomplished  the first time.

Finally, if your organization has the ability to record meetings, do so. Notes taken during meetings require that the note taker split their attention, so either something will be missed or they have a great auto-writing process that most do not. And memories are worse than notes, and even worse when prompted by notes that were taken with the expectation that all context would be retained when reviewing (hint: it won’t). Most meeting software that records has an auto-delete time period, so preserve elsewhere if necessary or let it expire if it turns out it isn’t needed. The recording may just save you from another meeting to go over the same agenda (or even non-agenda).

[author returns his soap box to easily-accessible storage location]

If you found this interesting, please share.

© Scott S. Nelson

Things to Determine before Projects Begin

This post is a perpetual Work-in-Progress. As of now, it is only starting (stalling would be more accurate, I’ve been playing with it in various forms for a few years now).

Whether you are starting in a new enterprise role or are a consultant with a new enterprise client, learning the customs of the culture are critical to long term success. Perception of value is more important than actual value (though those with a conscious will work to provide both) and great work will be overlooked if expectations are missed (even if they are less relevant than what was accomplished).

Here’s what we have so far (please add your additions in the comments):

Project Type Artifact
All Release schedule
All Release process
All Coding standards
All Other StakeHolders that may be impacted
All Where and how architecture decisions are logged
All What artifact reviews are required? What is the review process for each?
If you found this interesting, please share.

© Scott S. Nelson