MDD: Monkey Driven Development

When studying at the university, I believed it was a myth or something from the early stages of computer science. But having seen this management style with my own eyes made me realize that no matter how deep you're drowning, you can always drown deeper.

A story already heard... with a twist

I was working for a customer helping their team maintain and code new features on the front end of a big cloud native app. It was easy to spot the pain points baked in their architecture and development process: no code reviews or pair programming, flaky tests, no code conventions, modules with multiple responsibilities... I think you can relate.

Want to reuse a function or maybe want to rely upon the network/api layer? Sure! Only remember to import the user notification engine and of course state management with a couple of random libraries. 😭

Ok, we had a lot of problems to deal with. But that's not an issue, it is our job (🏋️) to find problems, shape and discuss possible solutions with other mates and leadership or management and eventually we get the software out of that mess. It's not a big bang, it is an iterative process where things are solved one by one in a particular order to minimize the impact on customers and final users. It's like taking a walk on a long road, not even paved but on the rough, and the rocks and walls and tree roots have been detected and mapped so that we know where to step our feet.

So we detailed the problem, discussed some possible solutions, put up a plan and talked to upper management. They listened carefully and... yay! Approved! Once this new feature is over, we will start addressing the technical debt!

Can you imagine how it ended? Perhaps our plan was tossed in a bin? Nope, not even that. Once the feature was over, management just ignored our request. From then onward it was like talking to the wind.

This picture was created out of real life experience for a reason.

Once you cross the touching point and invert the trend, it starts to be very hard to step back. The value delivered drastically crashes, and because new features have to be shipped as soon as possible (that is: yesterday) the technical debt keeps on growing larger.

This is an already-seen-thousands-of-times story, but here comes the plot twist. I was working with amazing people and we managed to deliver new features with delays that were manageable by our sales/management. Quality was of course not over the top, we were forced to skip the neverending test runs and there was no way to add new meaningful ones. Bugs and regressions were an ordinary thing and we were also blamed for some of those, but still, our voice wasn't heard. The process was simply this: code and deliver. Any late? Be faster! Any bug? Pay attention! Is everything ok? Not even a single chat message. A huge mess? A chat message every few hours: how's going? are you on time?

Micromanagement? Sort of, probably, not sure how to define it. Surely, not a healthy software development process whatsoever.

Some time passed by since I joined them, and my mates and I started arguing about how was possible that management did not care about quality that much. The bugs and regressions were there, tracked and documented, containing recordings and screenshots. Quality was crumbling down, not to talk about performance, how was possible that only the development team, not even customer technical leaders, was aware of the issue? The answer was lying right under our eyes.

The overall quality was sufficing for them.

Management and sales were able to manage issues and delivery delays quite easily. Payments were run regularly, software was used by our end users all over the world. From their perspective, it was a success. A huge success. In the end, code quality and processes were just a mere obsession of those nerdy guys who are the less paid in the chain.

We were just the monkeys stroking our keyboards, making somehow the magic happen, it was none of their business. The car had squared wheels, but the race result was ok nonetheless. Who cared if the developers were pushing the car hard? Want to put rounded wheels on? Just add this new feature and push harder, who cares?

No need to fuel, just push guys!

Consequently, we were the only ones to foresee what would have happened, sooner or later: the tech debt will eventually swallow their optimism and will transform the company into a battlefield of managers against developers, blaming each other.

It was a shocking, astonishing moment for me. I always intended, and still intend, my job as a creative job. We are given problems, we try to solve them the best we can and oftentimes we go beyond our limits. Not many jobs out there have this peculiarity and I am proud of being a developer. But at that moment I even thought they were stealing money from us. We were doing a lot of unrecognized, undervalued and unrewarded work.

Software development is hard and obeys certain rules. By creating technical debt, we are playing out of those rules and this makes development harder. Up to a certain point, this is fine and is called deliberate debt, but we have to pay it back, better sooner than later, both for developers and the product itself.

I realized this is not something that all managers or leaders can understand. Without a technical background, or even with a very poor one, what managers will see is just numbers going up or down on a spreadsheet. That's all. The rest is business for the development monkeys, regardless of them being one of the most important cogs in the engine. This is Monkey Driven Development.

The tech debt would have soon knocked on their door and I didn't want to be at the office then.

Conclusions

I could have stayed there, keeping up a certain pace to carry a salary home, and would have faced the managers vs development battlefield in one way or another. Some people do, and I think it can be fine if everyone is happy.

But I couldn't. So I quit.

But how do people reach a management or leadership role without a deep knowledge of how the IT world works? How's possible that such people heard about technical debt and still don't care when its indicators rise? Well, that is a story for another bite.

References

• Thoughtworks on technical debt