“It ain't what you don't know that gets you into trouble. It's what you know for sure that just ain't so.”
Often attributed to Mark Twain, but maybe not. (https://en.wikiquote.org/wiki/Talk:Mark_Twain) The problem is that we are all full of such “facts”, which may or may not be, and most of us don’t double-check.
I actually found the quote above when searching for some information on the word “ain’t” – for reasons which will soon become apparent. In the past, many teachers treated it as gospel that “ain’t” is bad, but I would wager that the vast majority of them didn’t know WHY. If you want to make authoritative statements, probably a good idea to have at least a passing familiarity with what you are talking about.
As an example of this, I found a blog post (https://www.dailywritingtips.com/whats-wrong-with-aint/) which described teaching junior high school English. This is a good illustration because it’s an authoritative comment from someone who is clearly not an authority.
The reason given for not using “I ain’t” was that “I’m not” is a “standard expression”, while “ain’t I?” was acceptable because
the usual “standard” form of “aren’t I” was not exactly grammatical. Would anyone ever say “are I not?
While my initial response was “WTF?”, my refined response was: “Am I not justified in pointing out that ‘are I not’ is in no way grammatical, and that the grammatically correct ‘am I not’ is also a standard form, which renders this entire argument invalid?”
Before looking into this to learn a bit more, I was aware of “I ain’t” as a predictable evolution of contracting “I am not”, and thought that other usages were technically “incorrect”. I did not realize that the situation is even more interesting than that. Check out the Wikipedia article (https://en.wikipedia.org/wiki/Ain%27t) for more. (Linguistics is fascinating!)
How does any of this relate to technology, though?
We frequently hear “rules” which are stated as if they are carved in stone tablets, but it is always worth digging in to the question of “why”, rather than blindly accepting them as fact. One example is the “password complexity rules” we often hear about – See https://www.til-technology.com/post/infosec-bullshido-password-complexity-rules for my comments on that topic.
Another example is an old, but still-relevant and hilariously funny video about mySQL vs MongoDB (https://www.youtube.com/watch?v=b2F-DItXtZs). Not safe for work, but a great illustration of the difference between someone who knows what they are talking about, and someone who has memorized a few buzz-words and thinks they are an expert.
While following rules blindly is a recipe for disaster, knowing when and how to break them is a vital skill for navigating the complexities of our current world. Standard disclaimer: “Situations in example are always more complex than they appear”
So, take a theoretical organization in which technology teams are broken into development (focus on larger-scale product evolution), maintenance (focus on maintenance, bugs, and small-scale enhancements), and support teams (who work with clients/end-users on operational issues and support).
In such a case, you might decide that Scrum (https://en.wikipedia.org/wiki/Scrum_%28software_development%29) is a valid way to manage the development team, that Kanban (https://en.wikipedia.org/wiki/Kanban_(development)) is a valid way to manage the support team, and that some hybrid approach such as “Scrumban” (https://en.wikipedia.org/wiki/Scrumban) is a valid way to manage the maintenance team.
On paper, if all of the teams were totally separate and lived in separate silos, this might work. But in the real world, reality usually sets in immediately. (Sigh.)
Many organizations will want to avoid having multiple methodologies for managing different groups, due to the cost of implementation, training, and support for each one, and the challenges associated with cross-team communication. In practice, such organizations will often prefer to either develop their own hybrid approach (based on one or more standards), or select a single methodology and then develop rules for applying it to non-standard situations.
In addition, many organizations have the same teams or resources supporting both development and support, which means that the same resources will need to use multiple processes on a regular basis, make significant changes to their team structures, or both.
Without some awareness of the rules, or some familiarity with different methodologies and their associated benefits and drawbacks, you will end up with a “process” made up of half-baked ideas and convoluted workarounds which will inevitably create a “process zombie apocalypse”, which seems like a great idea for a follow-up to my other post on process zombies... (https://www.til-technology.com/post/attack-of-the-process-zombies)
That said, if we understand the rules and when they apply, we can develop an approach which is formal enough to support good process management, tracking, and audit, while being flexible enough to handle all the situations we find in our organization.
But what about project management?
Ah! You caught that, did you? Good!
A project is “a temporary endeavour undertaken to create a unique product, service or result” (https://www.pmi.org/about/learn-about-pmi/what-is-project-management), but much of what is described above is more operational in nature.
Exactly.
In a theoretical perfect world, we would have dedicated project teams which focus on single projects. I’ve heard of such projects (eg, in construction, or in very large-scale software development), but I have never actually seen or worked on one. In my experience, I have normally had to deal with formal projects (ie, formally defined and reported to leadership), informal “projects” (eg, major software version upgrades, server migrations, and such), and operational work – often all at the same time.
All of this work needs to be managed in a disciplined way, and project management methodologies are usually involved to some degree (because they are effective). Without significant organizational changes (which may be outside one’s sphere of influence), we need to make practical decisions regarding how to work.
How can we do this?
As noted above, a lack of understanding of the “rules” often leads to very poor outcomes, but if you understand the benefits and costs of different approaches, you can select which rules to follow and which to break. In the past, I have found it helpful (if not vital) to “projectize” operational work and “operationalize” project work, to come up with a hybrid solution which can be used to manage both. Not elegantly, maybe, but effectively.
In the longer-run, I would advise learning about these approaches, educating others as best you can, and promoting the development of organization-wide policies and practices which best fit the reality of your organization.
By learning and understanding the “rules”, we can see where they apply, and where they don’t. Then, we can understand whether we should break them or not, and how.
Cheers!
Comments