13th June 2021
A warm welcome to new subscribers who joined us in the last two weeks. I hope you will enjoy your stay here.
I was on holiday (or "on hols" to use the industry vernacular) last week. I had a lovely time, thanks for asking. I did not travel far from home as I’m still nervous about THE INFECTIOUS DISEASE, but I managed to get some sun and sangria, so it wasn’t too bad.
Now I'm back to drawing boxes & arrows on Miro boards and delivering stakeholder value from the comfort of my home.
With that intro out of the way, let’s read on, shall we? (。◕‿‿◕。)
#NewsOfTheWorld
Marc (Cloud King) Benioff on the company's record first quarter and Slack acquisition 💸 [source: Yahoo Finance!]
Meet Tableau’s new CEO - Mark Nelson [source: Geekwire]
Einstein Relationship Insights automagically discovers relationships between customers, prospects, and companies 🤖 [source: VentureBeat]
Salesforce CEO expects half or more of employees to WFH [source: CNBC]
Salesforce continues to support India through Covid-19 crisis [source: ExpressComputer]
Financial Services Cloud buffed up with investment, corporate banking tools 💪[source: zdnet]
#BlogPosts
I enjoy reading How-to posts about refactoring code, and James Simone (IMHO) is a darn fine writer - so this post about fixing an improper abstraction instead of letting it fester was the highlight of my week. I hope you'll enjoy it too.
🚨To all the CTA aspirants🚨: Johann discusses the criteria to consider to decide when you're ready for the CTA board.
7 things Architects should know about Flow [source: Salesforce Architects blog]
Philippe Ozil has built a cool apex code scan tool that'll help you identify instances where your code is violating the security update enforced in the Summer'21 release [source: Salesforce Developers blog]
🆒 Salesforce Maxim shows us a neat trick to execute scheduled jobs NOW without writing an anonymous Apex script
Narender walks us through an example to describe how Before Save flow works
Finally, the SFXD collective has released their latest abridged Release Notes for Summer'21 [source: Reddit]
#ThinkPiece
In this #thinkPiece, we will explore the impact of tactical programming and introduce a developer species that you probably don't want to become or possibly avoid having on your team.
There are two ways to approach software development - tactical or strategic. With a tactical mindset, you focus exclusively on working code, i.e. you want to get something to work ASAP. There are several reasons for this. Some of them can be considered valid, like a hard deadline; others are more sinister, like lack of standards, ownership, or just plain lazy thinking.
This tactical mindset leads to several problems:
You are trying to finish the task as opposed to trying to get it right. This usually leads to a sub-optimal solution.
When you start making numerous short-term fixes, the system's overall complexity goes up, becoming unmaintainable over time.
You tell yourself that you’ll come back and fix the kludge later, but that never happens, and the technical debt keeps compounding.
Another tactical decision that a lot of engineers make is not to create sufficient documentation. This makes the system even more unmaintainable due to a lack of shared knowledge.
There is a developer/engineer in every organisation who takes tactical programming to an extreme. In his book A Philosophy of Software Design, John Ousterhout calls this individual a Tactical Tornado [TT]. This individual, at first glance, looks ultra-productive (perhaps akin to the mythical 10x developer) because they crank out code faster than others. They are quick to fix a bug. Heck, they also deploy the change straight to production, bypassing UAT and other quality assurance steps because they are confident their fix works. When it comes to implementing something, nobody does it faster than a Tactical Tornado. Working code is good enough code for a TT.
In many organisations, management loves a TT; they are a hero because they get stuff done. They assume that this one engineer's apparent "productivity" saves them from hiring 10 other engineers. They feel that the company will fall apart if these TTs leave and reward them with public praise, pay rise, unwarranted promotions etc.
However, if you happen to review the Tactical Tornado’s implementation properly, you’ll most probably find it shockingly tactical, non-standard, comments less, possibly unreadable and therefore unmaintainable. You realise that the Tactical Tornado has left behind a trail of destruction. A mess that’ll take weeks (if not months) to fix. In fact, if you attempt to fix this mess, you will appear to be making slower progress compared to the TT. Your thoughtful, strategic design approach will be seen as a disadvantage.
If you’re a manager or team lead and you’ve realised that you have a TT in your team, you could do one of the following:
Encourage a culture with a strategic programming mindset; instead of "working code" as your primary goal, you should focus on producing a great design.
Coach the TT and stop rewarding their behaviour; Promote behaviour that encourages collaboration so that individuals make decisions that benefit the team and move much faster.
Focus on improving the teams bus-factor1 to reduce dependency on the TT.
If none of the above changes the TTs behaviour, consider removing them from the team or organisation.
These tactics are not just about putting speed bumps on the road to ensure that you’re not driving 70 mph on a 30 mph road; it’s also about ensuring that as a team, everybody is rowing together towards the same goal.
Facebooks (and many other valley startups) slogan for years was "move fast and break things" - they actively encouraged tactical programming. Even though the company was successful, the codebase became unstable and hard to understand. Eventually, they pivoted to "move fast with solid infrastructure"2 to encourage their engineers to spend more time on good design and think about maintainability. Adopting a strategic mindset acknowledges that code does not always equal value, and the time spent working out the detailed design will deliver 10 times more value than a Tactical Tornado ever could.
Thanks again for reading. I hope you enjoyed the #thinkPiece. Let me know your thoughts in the comments. Until next time. Adios. ✌(-‿-)✌
I’m @SalesforceN3rd on Twitter, should you wish to follow me for more Salesforce news and occasional non-salesforce tweet.
I will write another thinkPiece on how to do this
Oxymoron much