Some years ago, I noticed I had grown increasingly frustrated with the modern trends in the software engineering field. People I had worked and conversed with felt reckless, unwilling to build quality, aggressive towards collaborating with others and hoarding knowledge to themselves.
Every novel idea I brought forward felt to them as if I was preaching words from a cult. Indeed, most of what I suggested sounded good on paper, but it could never work in the real world. Even though I had practised daily what I preached in the real world for years.
Only after I read about the Forest and Desert metaphor by Beth Andres-Beck and Kent Beck from Tidy First? did I realise that I had been living in a lush green forest for so long that I had forgotten what it's like to survive in the harsh and arid Desert climate.
The people in the Desert had never had the pleasure and experience of working in the Forest. Some of these people were genuinely inspired by what I had written and spoken to them, which to me felt odd. How is it possible these things are new to them?
The problem with living in the Desert is that you're too busy to carry sandbags from one station to another, so you don't have time to pick binoculars and look for the Forest. The human mind is excellent at coping with poor conditions. In a sense, people living in the Forest may seem arrogant towards those living in the Desert. I cannot speak for others, but for me, living in the Desert is a distant memory of the past, which I painfully revisit from time to time. That is why I'd like to help you see the Forest.
Below, I've listed a few characteristics that describe the different realities people face while living in the Desert.
In the Desert…
Software engineers are generally stressed and underperforming while working because…
- From the management's point of view, they need to be constantly supervised and steered in the right direction.
- They cannot deliver software within the desired timeframe but must obey predefined release schedules.
- Their backlogs are filled with bug reports from stakeholders, and they struggle to find time to fix those.
- Automated tests are either neglected willingly, or no one finds time or skills to write them.
- They are often blocked by dependencies on people on their team or other teams. To mitigate this, they constantly take on new work without realising it helps only on the surface.
- They interact with their customers or end users rarely and only during high-tension meetings, where the lion's share of the feedback consists of complaints about why the team has not delivered as promised.
- Users are seen as outsiders or uncivilised men from the street. These wild people don't know the best practices and only have complaints to the team.
- Everyone is working in isolation from the rest of the team as management determines that dividing the planned work and working in parallel is the most effective way to solve problems.
- Experimenting and prototyping are discouraged since painstakingly planning the work is paramount to successful delivery.
- Demos between engineers are rarely organised as those take too much time off their busy schedules.
- Engineers rank high in their specialities but feel helpless when exiting their comfort zone.
- Individual engineers own parts of the codebase and protect others who mess around with those parts.
- Iterations are hardly about iterating the work but more about executing a roadmap following a strictly documented process in cycles of two or more weeks.
- Designs and architectural plans are prepared in secrecy by the team. Complete and unquestionable technical designs are handed down to engineers.
- Individual engineers follow their personal goals against which their performance is assessed.
- Learning has to happen outside working hours due to busy schedules.
- Weekly hours drift towards 50 or 60 due to pressure from management to deliver as promised. Weekends are for paying back sleep deprivation.
Feeling familiar? In that case, there's always time to start walking towards the Forest. Be mindful, citing GeePaw Hill, that getting there takes many more, much smaller steps. After you have reached the Forest, you may witness the characteristics described below.
In the Forest…
Software engineers are generally relaxed and effective while working because…
- They are autonomous, empowered and self-organising.
- They deliver working software daily.
- They practice a zero-bugs policy, meaning defects are fixed as soon as they're found.
- Automated tests are written simultaneously with the production code.
- Blocking issues are resolved as a first priority by gathering all the people with the required knowledge together.
- They interact with their customers and end users daily, refining the requirements and negotiating scope to hit the targets.
- Users are seen as invaluable contributors, and the team helps them to make more informed decisions.
- They work in tight-knit teams, mostly committing the work in pairs and groups.
- Experiments and prototypes are frequently built and thrown away to foster a continuous learning and improvement culture.
- They demo their work at the end of every iteration, gaining timely feedback and learning more about the following steps.
- Engineers are cross-disciplinary and comfortable working across the entire technology stack.
- The whole team collectively owns the codebase, so everyone can focus on working on the part that brings value.
- Iterations last a maximum of a week, and even during the mid-week, the team has the freedom and responsibility to adapt to the feedback and correct the course.
- Design and architecture evolve throughout the development lifecycle, starting from a primitive whole and improving in tiny, verifiable steps.
- The team shares a single goal: improving their customers' lives. Every other goal is secondary.
- Learning is an integral part of the daily work.
- Weekly hours stop at 40 — often even less. Weekends are for relaxation and self-development.
Reaching the Forest
While the Desert and Forest folks seemingly exist on the polar opposite sides of the spectrum, the vast majority of the engineering teams live on the edge of the Forest. These teams are already accustomed partially to life in the Forest. Still, they are ultimately held captive by the Desert against their will. It's unfortunate that several organisations and domains predominantly exist in the Desert. The correct direction forward, however, is obvious. If you empty a bag of sand into the Forest, it will mix into the ground. However, a tree will die if you attempt to plant it in the Desert.
Respectively, it's worth noting there are and always will be people who are happy to live in the Desert, like a bunch of Fremen who have chosen to stay behind. Who am I to judge them riding on their worms? Nonetheless, I and many others prefer to live and work with the Forest people. If you'd like to join us, I'm happy to help.
In closing, there are no secret techniques for reaching the Forest that work for everyone, but some actions I generally advise people willing to take while walking towards the Forest include working small, testing continuously, putting their ego aside, being kind to others, helping others, not hiding their work, and getting enough sleep.
Oh, and one more thing before you leave. Do watch the keynote talk by the Becks below for complete insight. I'm merely the messenger here.
Cover photo taken from Tidy First.