See the first post in The Pragmatic Programmer 20th Anniversary Edition series for an introduction.
Challenge 1
While reviewing a draft of the first edition, John Lakos raised the following issue: The soldiers progressively deceive the villagers, but the change they catalyze does them all good. However, by progressively deceiving the frog, you’re doing it harm. Can you determine whether you’re making stone soup or frog soup when you try to catalyze change? Is the decision subjective or objective?
Although not necessarily easy, I think we can determine whether catalysing change leads to stone soup or frog soup and is largely determined by the intent of the change.
- Stone Soup
- Improve a situation for others involved
- e.g. reduce project costs, improve productivity
- Aid in making progress towards goals
- e.g. a new feature release
- Improve a situation for others involved
- Frog soup
- Make a situation worse for others involved
- Introducing a new technology for ‘CV Driven Development’
- Prevent progress towards goals
- Make a situation worse for others involved
The difficulty is that the decision could be subjective or objective. For example, reducing project costs by moving away from managed services (such as AWS Fargate) may be a win for the business (stone soup) but it could have adverse effects on engineering due to the increased work required (frog soup). Introducing a new technology for ‘CV Driven Development’ will cause unnecessary cognitive overhead for other engineers on a project and could also cause problems if a technology is not stable (frog soup). However, it could be frog soup if introduced due to feature that is genuinely useful to the project.
When catalysing change, I think it is very important to clearly and honestly determine the justifications for the change. It is also crucial to re-assess the effects of the change throughout the process. If the soldiers realised half way through making the stone soup that the villagers had contributed a large proportion of their food supplies, it would be wise to stop asking for more ingredients.
Challenge 2
Quick, without looking, how many lights are in the ceiling above you? How many exits in the room? How many people? Is there anything out of context, anything that looks like it doesn’t belong? This is an exercise in situational awareness, a technique practiced by folks ranging from boy and girl scouts to Navy SEALs. Get in the habit of really looking and noticing your surroundings. Then do the same for your project.
Now I’m no Navy SEAL, but I do ride bikes which (to do safely) requires a high level of situational awareness. For example:
- Is there a car behind me?
- Is there a car in front of me?
- What’s the road surface like?
- Are there any pedestrians at the side of the road?
- Are there any pedestrians in the road?
For Software projects, situational awareness is slightly different:
- Is the Software meeting it’s requirements?
- Is it reliable?
- Is it maintainable?
- Is it overly complex?
Periodically, I carry out a number of exercises to help achieve this.
Write a README/Project Overview
Without looking at existing resources, writing a README/Project Overview requires one to be able to describe the purpose, implementation and design decisions of a project. If this becomes difficult to do, it’s possible that the project is deteriorating in quality.
Re-install the Project
Un-install the project (and any dependencies) from your development machine. Now re-install the project using nothing but the existing installation documentation (if it doesn’t exist then make it as part of this exercise!). How easy was it to do? Has the project grown extra dependencies which are difficult to manage/install?
Implement and Test a New ‘Made Up’ Feature
Think of a new feature to add to the project. It should be small enough in scope to not take up a large amount of time but not completely trivial. Implement this feature with sufficient test coverage to be comfortable that the feature works. How hard was it to implement? How hard was it to test?