According to Western astrology, there’s this thing called “Mercury Retrograde”. Before you dismiss it as mumbo-jumbo remember that this “science” is several thousand years old. And probably too complex for even software engineers like you and me to understand.
During a this “planetary” alignment some activities (like hosting long meetings or code-refacturing) are safe, others are not.
Below a list of the most common challenges we face during retrogrades along with some proposed solutions. I’d like to present these ideas as “Astrology Driven Software Development” (ADSD).
ADSD will become the next big thing in Software Engineering and complement other popular movements such as Agile or DevOps. (a full blown “ADSD Manifesto” will follow as soon as the planets are in favorable alignment).
During mercury retrograde messages are jumbled
This could bring out bugs concurrency previously which went undetected and head are now raising their ugly.
Meanings are confused during a retrograde
Errors that we have never seen before are now causing grief. Web Data Analytics platform confirms that during a retrograde, sites like stack-exchange, stackoverflow, quora et al, users post far more dumbass questions. Things like, “Should I migrate from Java to PHP to fix my performance and scalability problems?”, get downvoted more often during retrogrades than any other times of year.
Because not all information is available to us during a mercury retrograde it’s vital that we don’t jump to conclusions when troubleshooting. Instead assume you don’t have all the facts and wait until after retrograde before announcing your solution to the team.
There is also a high chance that a sneaky colleague (you know the one who never shuts up about “mutability” and functional programming, never showers before pair-programming and smells like canned soup) will invalidate your hard work by providing the last piece of the puzzle. Yeah it doesn’t matter even you did all the foundational legwork – it’s common that this little shits (often Virgo or Scorpio) get all the praise during a retrograde.
Wasn’t it time that the Software Engineering community wakes up and finally tackles mercury retrograde problems head on?
There is so much we could do to make our computers and networks more reliable. In only a few steps we can drive down IT infrastructure costs and reduce OPEX/CAPEX and improve Quality of Experience (QoE). (just in case you need business arguments justifying your implementation effort to a technically ignorant management)
Let’s rethink our R&D processes in the following way. Here is what we can do, …
On the infrastructure level:
System scheduling software such as CRON or AT:
CRON jobs should be extended to take the calculation of upcoming mercury retrograde schedules into account. Currently all versions of cron (anacron, vixi, fcron …) require us to manually enter jobs which are only executed during retrograde (data back-up, forced maintenance modes and file-system checks, system audits, etc). Cron should take the planetary constellation into account and add support to express it with additional syntax in the crontab. Something like this:
# For example, run a job every minute during the 12th hour of the day,
# but only if the day is the 10th, the 12th, the 14th or the 16th of the month, and
# only when it's also mercury retrograde:
* 12 (10-16/2)[☿℞] * *Monitoring tools and protocols (nagios, rrdtool, SNMP, etc) must be extended to help us better understand the data and make us aware of mercury retrogrades. We could even create support for other short lived “planetary” cycles like full-moons or eclipses (it is well known that software from https://eclipse.org tends to only work reliably during lunar or solar eclipses and cause out-of-memory exceptions all other times!!)
On the HR level:
→ identify those developers in your team who were unlucky enough to be born during a retrograde cycle. You can probably guess who it is because it’s usually those who fail to write proper testcases and tend to ignore all code quality guidelines. These guys also tend to look very shifty when asked to pair-program. They should not be touching code or be in charge of critical infrastructure EVER. If you haven’t done so already, disable their git/subversion account stat (!!) and discuss how to promote them into a different position. (promoting them into Project Management, has proven a good career path for most). Don’t worry about whether this is too harsh … it’s probably their own fault (due to past sins or bad reddit karma) and the universe wants to teach them a lesson. Ultimately it will help them grow towards greater love and greater good.
Benefits on the business level:
→ Once these changes are implemented we can then structure more flexible Service Level Agreements (SLA) taking these planetary constellations into account and provide a better pricing structure to our clients/users. Especially cloud service providers would be able to offer discounts during non-retrograde times and market additional services for retrograde monitoring into their product.
