IF IT WORKS, BREAK IT!

IF IT WORKS DON’T FIX IT BREAK IT!

Software isn’t just the code engineers write, neither that pretty UI users enjoy.

Software is a living organism and a manifestation of a collective cohesive minds that try to create something bigger than themselves to achieve bigger goals.

When we talk about developing software, we need to consider the human aspect of it, the team that invests their time and effort in it and how to keep the business, the engineers and the engineering process all in sync.

Experimentation is a fundamental part of the software development process, it’s simply the continuous process of taking an existing business aspect of the software and going out to explore how to could be done better with more relevant technologies and newer mindset.

Experimentation is simply our way of being proactively seeking a better way of doing things which will eventually protect us from disastrous unexpected issues with our system instead of being reactively trying to remedy rottenness that comes from rarely visited nearly abandoned archaic code that plays a fundamental important part of an existing system.

Take security for instance, would you rather keep up to date with what can possibly cause a security breach (Murphy’s Law) or would you rather wait until your system is completely compromised and losing your user base?

Let’s take an example of us as humans, when we go through a bad experience in life, we don’t go die and bring a new version of ourselves.

We reinvent ourselves, we don’t give up, we reflect, and we rise again, we evolve! It’s what makes us great!

Software should follow the same pattern, in fact, the continuous process of experimentation and merge into production is a lot cheaper than a system rewrite.

Rewriting systems is a very old-school mindset, it’s almost a waterfall-y even if it disguised itself in an agile process.

It’s waterfall-y because it means we had to wait until the system is completely useless before we had to start from scratch, instead of trying to continuously replace parts of the system with newer more relevant, efficient code.

It’s one of the advantages of software, it can be modular, componentized and flexible.

Sometimes people say, we have a legacy system that we are planning to sunset in the next year or two, we don’t want to invest anymore or experiment with new technologies in that system.

That’s the wrong way to go, simply because it means you’re telling your team that everything they are currently working on is going to be thrown away which brings the team morale down under.

It means that you’ve failed to keep the system relevant and up to date therefore you’re going to throw it all away and start over, and over instead of replacing the older parts with newer parts which keeps the business domain intact instead of having to reinvent the wheel by rethinking everything over again.

It also means that you’re telling your team that by rewriting the system with the newest technologies you simply don’t need their skillsets anymore, you need new people with new skillsets, the skillsets that you should have taught your existing team through experimentation so you can leverage their existing domain knowledge instead of having to start over again with a completely new team.

This is what makes new architecture patterns such as Microservices and Serverless so appealing and attractive, because it allows that gradual reinvention of the system in a low-risk safe and productive manner.

There will always be a bit of pain trying to keep a new service relevant and compatible with an older legacy service, but if that legacy service is only a year or so old, it wouldn’t be as painful as a four- or five-years old legacy service.

Legacy mindsets will produce legacy people that’ll be eventually disposed and kicked to the curb turning them into only bug and data fixers maintaining archaic systems with their lives, instead of being exploratory researchers, story-tellers that know how to stay relevant and carry their weight in a forever-changing industry to keep up with the competition.

Here’s some of the advantages of experimentation or R&D:

Experimentation for the business:

- Keeping the business relevant and up for competition, easy to push new features and sunset older ones and fix issues.

- Makes the business appealing to the best talented engineers to come and contribute to it, very high engineers retention rates.

Experimentation for the engineers:

- Growth of skillsets, more stories to tell about various technologies.

- Willingness to stay around longer, to learn more and contribute more and being more proactive about technology.

How some legacy systems end up in that bad state?

- Legacy mindsets will produce legacy systems, when people don’t try to stay relevant their software will be nothing but a reflection of their mindsets.

- Incompetence: I have come across people that don’t really want to learn something new, they don’t want to spend the effort in staying relevant, therefore they are happy with doing the same thing on the same system for the next twenty years.

- Blind spots: when the business is in control of how (not what) engineers develop the software, it becomes harder to explain why destroying something and rewriting it to produce the same exact existing results is a very important part of maintaining the business. I always say the further you are from touching the code base the less say you should have in how to write it.

How to practice experimentation in a software development process?

There are many ways of practicing experimentation in an agile environment, I’m going to draw a framework here and some examples of how to execute but for each team the ultimate freedom of how to implement this.

Here’s some ground rules:

1. In every sprint there should be allocated time and effort to experiment with a new technology, method or architecture or even something as little as a new software pattern to think about doing an existing feature or add a new one in a better more innovative way. The industry never lacks new methods, technologies and ideas.

2. Only few members of the team should be working on the experimentation, so the rest of the team is able to continue working on the current features, defects for the existing software.

3. At the end of every sprint experimentation team should demo their work to the rest of the team and get feedback and improve on their next iteration of experimentation.

4. In next sprint, engineers who did the experimentation should switch to working on the production line, so the others could do their fair share of experimentation as well. This way the entire team gets to try different technologies, ideas, cultivate knowledge and leverage the skillsets of each other and improve the system and make it more appealing and competitive than ever.

Here’s a little illustration of the framework:

Zuckerberg once said: “Move fast and break things. Unless you are breaking stuff, you are not moving fast enough.”

This industry is an innovation-based industry, ignited and maintained by innovative minds within innovative cultures that encourages experimentation and research.

In this industry there’s no place for snoozing, incompetence other than cleaning up after even more incompetent individuals who probably don’t even work in the industry anymore, do you want to be that guy? No? then experiment, make mistakes, fail fast and fail cheap, take risks and keep learning!

If you’re environment doesn’t nurture experimentation and innovation then push for it, change the world for the good! Nadella says: “You need new ideas and you need new capabilities, but the only way you’re going to get those new ideas and new capabilities is if you have a culture that allows you to grow those”

So if this culture doesn’t exist wherever you are, bring it to your place, don’t be a quitter, don’t give up too easy, take risks and engage in changing your workplace, you get a lot more experience and credits for evolving a non-innovative environment into one that nurture it, rather than joining one that’s already there!

--

--

I’ve mastered technology to improve people’s lives one line of code at a time, more about me on hassanhabib.com (opinions are my own)

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Hassan Habib

I’ve mastered technology to improve people’s lives one line of code at a time, more about me on hassanhabib.com (opinions are my own)