My Dealings With a Pandemic

Beren Van Daele, Running Isle of IT

People who follow my journey somewhat may know that at the beginning of 2018 I decided to break with a great many things and journey onwards. Up until recently, the road (business-wise) has been mainly littered with proverbial candy. Now, in what seems to be a resurgence of the global pandemic, a first real threat to the business has been culminating and will likely continue to do so. This blogpost will give you insight in my thought process and feelings of the past couple of months and what we’ve been doing so far.

The months, even years, that happened before the lockdown now feel like they were preparations for today. The moneybuffer the business amased, the hires, the projects, all of it suddenly shifted from ‘business as usual’ to ‘how is this helping us to survive?’. Let me shed some lights on the cards we’re holding.

Some Dreadful Things

Just before the lockdown, I hired two new people. Joanna is a seasoned event organiser, Aline a junior front end developer. The third employee, Geert, has had a good contract at a customer in media for some time and continues to do so. So steady income from one, while three (including me) are currently costing. We can see a slow decline in our moneybuffer monthly.

You can imagine that events got cancelled overal and it’s extremely difficult to find projects for juniors in such a market. Finding a project for myself at a reasonable rate seems to be difficult too.

20200704_124115

Hiking the Ardennes

For four months, we’ve been trying to find projects for either me or Aline, the front end developer, with no avail. This has been frustrating and stressful to say the least. Please realise that this includes: Countless times of ‘not hearing back’, doing interviews with no feedback or answer, being disappointed on a daily basis. This is difficult for me, but also impacts the morale Aline, who may start feeling like a burden rather than an asset.

Another aspect we face is that ITMatters.pl events were planned, but uncertain. For some weeks we were hopeful to organise them in a safe way. However, now we decided to hold only one event online. These experiences are rollercoasters in a time that one wishes stability.

20200704_160145

Kayak with the team

Some Hopeful Things

Because we have a small organisation that values transparancy and communication I can truly feel everyone engaged to make the best out of this situation. They’re thinking, even to their own disadvantange, about ways to help the business forward. I can feel that they love being part of this. That they subscribe to this ideology. That they want this company to succeed.
This is probably the single proudest achievement for me.

We have a good buffer that will last us some time longer even though I can see that number declining slightly month after month.
I can see Geert taking his responsibility to continuously work and bring in the baseline which we need.
Joanna is using her strengths to enlist people to her cause. ITMatters.pl has had some major setbacks, yet she’s building a flame that is growing brighter day by day.

Aline and I? We’re building something I’m very hopeful for: RiskStormingOnline.com.
She’s shown incredible motivation and aptitude in digitalising this workshop which I feel can help so, so many software projects. We’ve been able to recruit the help of several more experienced people to help us get to something marketable quicker. Check out the beta version here: riskstorming.praxio.be

This Is Not a Cry For Help

This is a window into my head, do with that what you will. As an employer, you take the risk. You reap the profits when things go well and you carry the risks when they don’t. That’s the simple truth.

The complexity behind it, the feelings and many events contributing to your state of mind are much less obvious. There’s the great pressure of having people relying on the company for their income. It’s both a (self inflicted) blessing and burden.
Another challenge is the daily planning for an uncertain future and hoping you’re making the right choices. There’s a constant influx of trade-offs to be made.

Should I invest time to find Aline a project, or make sure she can focus on RiskStormingOnline.com?
Should I accept a less-paying job for myself, getting some extra money, but having less time for others, possibly burning myself out?
Should I put all my eggs in the RiskStorming-basket?
How much more time do we have in this ‘normal market’ until the pandemic hits again?
Do I ask people to go temporarily unemployed and save some money while leaving people in the cold?

These are a few of many considerations that I’ve had to deal with once, multiple times or even daily. All the while, checking in with people around me.
These same people, whom I respect and love, often second guess my decisions. They shake my convictions. They give me hope, but they don’t take it easy on me.

20200704_131206

A much needed weekend together in Belgium

In the future, I may regret some decisions I’ve taken these days. However, I’ve learned a great deal of what it means to run a business during ‘good times’ in preparation of ‘bad times’. I’ve learned to treat advice for what it is: Glorified experiences. Very little people have dealt with running a company like mine, with its values and ideology in a global pandemic situation.

Advice is a form of nostalgia, dispensing it is a way of fishing the past from the disposal, wiping it off, painting over the ugly parts and recycling it for more than it’s worth.
– Baz Luhrman, Everybody’s free

We’re doing well. We could use some more good news here and there, but all in all, our foundations are steady and we’re building towards the future.

IMG_20200717_183637

Daria & Joanna at their own Polish weekend

 

Dipping One’s Toes Into Testing

Aline Lanckneus, Experience Reports, Software Testing

How does one get into testing? From what I’ve heard, most testers don’t go to “testing school” but they simply fall into it. The same applies to me. 4 weeks ago I was attending a coding bootcamp where I found myself longing for any kind of feedback and mentorship. About 3 weeks ago I was offered a contract by Isle of IT as a junior test consultant. That’s how many weeks I have dedicated so far attempting to learn everything there is to learn about testing. 

Before all of this I was realising a lifelong dream, becoming a veterinarian. Obviously, if you’ve read the paragraph above, you’ll know this particular dream didn’t work out in the end. Instead of talking about why I decided to end my veterinarian career, a question I have had to answer too many times in the last couple of months, I’ll briefly talk about the skills I believe and hope are transferable to testing. 

Aline and Geert in Ardennes

Aline and Geert in Ardennes

Testing Powers and Veterinarians

Asking questions for example. When diagnosing an animal, we learn to ask questions. In general, you aim to ask just the right amount of questions. Ask too many, you might annoy the owners, ask too few, you might miss crucial information necessary to achieve a correct diagnosis for your patient. 

Communicating, unfortunately as a veterinarian sometimes you need to deliver really, really bad news to people. Delivering this news in a thoughtful and compassionate way is of the utmost importance. Obviously, communicating skills are useful when dealing with people in general. I remember one of my professors once saying, imagine a brilliant and greatly skilled veterinarian who doesn’t have the best social skills. Most owners would eventually stop seeing this veterinarian, despite his/her geniousness. Now imagine a veterinarian who cuts corners, delivers mediocre work and is mostly interested in ways to earn as much money as possible, with the least amount of effort. (I’d like to think this particular kind of veterinarian is rare) This incredibly charismatic veterinarian could sell his/her customers anything. You better believe customers will keep coming back, despite not necessarily getting the best possible treatment for their beloved pets. Now I don’t believe I fit into either of these categories, I imagine myself sitting somewhere in the middle. I do feel like I learned some very valuable communication skills during my training and while I was working. And I believe those skills transfer to testing.

The ability to observe, as a veterinarian a trained eye and attention to details comes in handy. Diagnosing orthopaedic conditions for example includes observing an animal from every angle, in motion but also when standing still or sitting. The slightest abnormality in stance or gait could be caused by an orthopaedic problem.When imaging techniques are not possible for whatever reason, a veterinarian depends solely on his/her capability to observe.

Lastly, my favourite subject in university was pathology, you might think that’s quite a morbid statement. What kind of veterinarian prefers to work with animals who are already deceased? Well, what I personally loved about it was the detective work. I thoroughly enjoyed searching for clues, every clue being a piece of the puzzle. I assume testing resembles detective work in a way and that you end up searching for clues in order to understand the bigger picture.

An Island with Herons nesting, Belgium

An Island with Herons nesting, Belgium

Start with Why

Back to testing. At the very beginning, the amount of information was overwhelming. Where does one start learning? I had the books, memberships on all kinds of online learning platforms, about a million online resources bookmarked and the entire internet to my disposal. I was all set, I’d spend 8 to 10 hours per day studying, weekends included. I couldn’t tear myself away from my desk. It almost became an obsession to me. I had a lot to prove, to my new co-workers, to my parents and most of all, to myself.

After two weeks of studying I was fortunate enough to get a one on one training with Mark Winteringham (DojoBoss at Ministry of Testing, Automation in Testing advocate, co-founder at Software Testing Clinic, …). I’ll admit I was a bit nervous beforehand, scared I would end up asking stupid questions. I was relieved to hear stupid questions are rare in testing. Luckily Mark did a great job making me feel at ease. 

But then came the question that would give me my first aha moment: 

Why do we test

Weirdly enough, despite my best studying efforts and countless hours spent in front of my computer, I wasn’t prepared for that question. How silly is that? I guess studying for 8 years at university, mostly learning how to jam as much information as possible into my brain, didn’t help me during my current quest.

In the end, I was able to give a decent answer. But only thanks to Mark leading me in the right direction and asking me lots of other questions. 

What is testing? What is quality? What happens when we test? What could happen if we don’t test

The remaining hours we talked a lot about the thought process behind testing. How testing should be about understanding the product and supporting the entire team in understanding it. Testing should be a team effort and as a tester you play an important role in that process. I assume everyone has a different understanding of what testing is, but what Mark was talking about made a lot of sense to me. He also talked about testing strategies and the importance of risks. 

We chose a simple todo-list app and brainstormed about the possible risks. After choosing one risk in particular, Mark asked me to think about how I could test it and on which level of the application we should test. He shared his mnemonic “Say Tatta to your Tuttu’s” that would ignite a certain thinking process which I found immensely interesting. 

He also talked about how visualising the application you are testing can help you in deciding where to test for a certain risk. I was relieved to find out a simple pen and paper can suffice to assist you in your thinking process and in seeing the bigger picture.

I was happy to hear Mark’s view on the role of automation in testing because from what I’ve read and heard so far, this subject in particular is controversial to say the least. We touched on some other subjects like what programming language you should learn when you’re starting out in testing, the asynchronous nature of JavaScript, the importance of distinguishing models from heuristics and so on. 

We were now nearing the end of our online training session. He gave me some final advice on how to structure my learning process, what I should be focusing on first en he provided me with a list of interesting resources. 

Every Learning Journey is Different

This training made me realise I had spent a disproportionate amount of my time learning about automation tools. It was easier to measure my progress this way. Completing tutorials gave me a false sense of progress. But I was fooling myself. I’m very thankful to Mark for helping me reach this conclusion. Now I can continue my learning journey in a way that will benefit me in the end. Focusing on understanding the problem and risks involved first and only at the very end start thinking about which tools to use.

Everything I’ve written down here is my interpretation and I am aware I may have misinterpreted or misunderstood certain things. Maybe I’ll read this blogpost again 5 years from now and have a good laugh. If somehow this blog post would be published publicly and people would actually read it, I am more than happy to hear anyone’s thoughts, questions or comments.

Beren on Nosal, Tatra Mountains

Beren on Nosal, Tatra Mountains

If you made it to the end of this blogpost, bravo! Considering I felt slightly reluctant to write it in the first place it turned out to be way more lengthy than I expected. But it did help me to digest all of the information I have been absorbing these last couple of weeks. Therefore I thank the person who asked me to do this in the first place. I want to thank him as well for introducing me to this fascinating world of testing and for continuously believing in me. Despite the current economic situation we find ourselves in, I feel motivated and hopeful that there is an opportunity out there for me. And I’m excited to represent Isle of IT in the best way I can.

The Relevance of a TestSphere Expansion

Beren Van Daele, Software Testing, TestSphere

The word is out! A new TestSphere expansion is available on the Ministry of Testing Store. I’ll give you the ‘short sell’ first, before going into my personal story of why this deck is a worthy addition.

  1. It’s got an amazing box. No longer will your feeble cardboard box break or tear as it tries to contain your TestSphere cards. The new box is stronger, big enough to hold both the orginal as the expansion.
  2. There are two new categories. The orignial cards focused much on known test techniques, patterns and heuristics which most testers already knew by name or by concept already. The two new categories venture into Operations and Architecture. Why those two? Because I personally feel they are/will become more relevant than anything else for testers across the globe.
  3. 7 Blank bonus cards. For every colour a blank card is added. This means you can customise a bit. We’ll make these empty cards available as a free to print template.
  4. 5 New cards for each colour. Each of the 5 existing colours got 5 new cards that further diversifies and deepens the dimension.

Image from iOS (1)

This is a pretty cool addition that will take your sphere of knowledge into quite different directions. You’ll be exposed to architectural concepts, observability strategies, increased availability measures and processes that will make your application more resilient.

Remember picking “stability”, “performance”, “operations” or… as a primary Quality Aspect during RiskStorming? Well, you now will have a more diverse set of techniques to tackle its possible risks. More improtantly though, the discussions you will have concerning quality will draw more diverse people in and will go wider, much wider than testing. This brings me to my personal insights…

A Bubbling Cauldron

Three years ago, I was a tester with some experience, launching a TestSphere deck that was largely a culmination of what I learned from others. Someone once said I threw some books and blogposts together into a card deck and resold that. I’d debate that, but then again, what’s the point?
This month, again with Ministry of Testing and the test community’s aid, we launch a very different addition to this deck. One that, in my opinion, is extremely relevant now and for the years to come.
Imagine me carrying around a big cauldron for the past 3 years. Consider all the possible ingredients I put in and where I picked them up:

  • Around 50 RiskStorming workshops on various projects all around Europe and one in Africa. 50 workshops, 15+ countries, about 1000 different testers/non-testers. That’s a lot of introspection and feedback.
  • Worked as a Product Owner and Quality Coach on top of growing my own business, employing people in my own special vision.
  • Supporting and advising the launch of a Europe-wide conference on Diversity & Inclusion and the human aspects in IT.
  • Attending numerous Testing Conferences, Development Conferences,…

It’s a lot to digest. Furthermore, because the cauldron has been bubbling so wildly and for so long, the dish wasn’t quite ready up until now.

Some digestible bites

The following are bits and pieces of my thought process, hopefully making clear to you, the reader, why this expansion is relevant.

  • ‘Testing’, be it manual, automated, exploratory, mobbed, isolated, executed, performed,… is a word very few people are concerned about. Many people feel burdened that they ‘should’ be concerned about it, but most people don’t want to be. Compare it to having to clean up your room. Some people really like doing it. Some people really like putting in hours automating some tasks, optimising and tweaking them. But most people just want a clean room and don’t need details on how it got there. I’d be the first person to say that this is irresponsible behaviour, degrading and probably a ticking timebomb. Yet after at least to deckades of trying to convince people of the importance, the industry as a whole becomes more and more hostile.
  • I was hired on a project as a ‘Quality Coach’ where they were vehemently against hiring testing. They had all the fancy stuff: Kubernetes, all the dockers, Kafka, Grafana, some scaling scrum thingy, communities of practice, SUPER COOL STUFF YO. The project had been running for more than a year when I joined. During the two months I was there the project release vision had yet to take shape. When it did, it changed several times and was eventually communicated to the teamleads. Then everyone assumed it would trickle down and the whole team would know ‘the plan’. Three months later, just before the massively important deadline, everyone is working overtime.

20191201_150724-effects

  • Test Automation on the UI and sometimes API level, as in the checking off things we already know, is largely a waste of time and in many, many cases a bad trade-off. A great number of projects could save lots of money by delivering with a bit of a delay and having one person check some flows or printscreens or whatever. The time invested in ‘pushing everything all the time and checking all the things all the time’ is exceptionally expensive. Some projects pull this off, most can’t (efficiently).
  • A very large portion of software projects are driven by personal wants, such as having the new state-of-the-art fancy thingy on one’s CV. Maybe someone wants to show a new shiny on the next demo. What happens even more often is someone saying at the start of the year: “This year we’ll grow by 10%.” with no plan, no risk assessment, only a feeling. I don’t see too much of that sustainable pace or good, honest communication between individuals from all ‘levels.

This works for the most of us. We can do cool things, earn a decent wage and most of us are bathing in luxuary nobody in the course of history could have ever imagined, anyway. So what’s the problem? … we’ll get to that.
I can only conclude that sweeping the dirt under the rug, or stashing all the garbage in the cellar is a good tactic to sell more, as long as the outside is shiny. This saddens, angers even, the idealist in me.

  • People with good testing knowledge, who can also transfer this knowledge to especially managers, leaders, anyone calling shots are worth their weight in gold. Your projects are an endless series of trade-offs. Investing in one thing means neglecting or breaking another. People with a testing mindset, who also know architecture systems or running an application in production, are in a unique position to point out these tradeoffs and can actually point out what is at risk.
  • Marcel Gehlen, a tester/developer/architect/.. turned manager says that Testing is a skill that is very difficult to sell. It is, however, a skill that will help people be loved. His advice is: get a skill, any skill, that gets you through the door. Then do testing.
    Following  the above clean-your-room analogy; customers buy roombas by the dozens. They pay good money for them. When the roomba starts cleaning up a lot more than just dust from the floor, there’s no way they want anything else.
  • Architects & Operations people are the closest people to us who are also focused and reliant on risks. We need to work together, not only mitigate risk, but also accept, tranfer and sometimes ignore risk.
    Only by discussing quality, risks and measures to improve our chances of success, can we do our jobs most effectively. Everything else is a waste of time and money.
  • Testing is an amazing skill. Testing is an amazing mindset. Testing itself isn’t that hard, but being a tester often is. (This is true for many roles in software development)

20191201_151555

My Advice

Expand your knowledge and your vocabulary. No, I’m not telling you you need to code or learn some whatever UI automation tool that’s just a shell on top of Selenium.
I AM telling you to play to your tester strengths:

  • Understand, explain, advocate for- and find holes in systems. Architectural systems, systems that Operations people use to ensure the application runs carefree. You’ll be surprised about the posibilities.
  • Find Allies. You are not the only one concerned about risks. Most people just lack the vocabulary and skills to advocate for measures to be taken. Find people who have those skills and learn how to advance conversations into plans.
  • Have a project-wide conversation on Quality. I’m super biased when it comes to RiskStorming, but in all honesty: I don’t are if you use TestSphere or any other tool. Just please, please, for the love of all the deities: have a conversation and prioritisation on quality aspects, risks to these quality aspects and come up with a plan that manages these risks and measures. It’s not easy, but it’s your job!

And that’s why this expansion is so relevant.

A Heartfelt Thank You to:

The Ministry of Testing, Abigail Bangser, Benny Hofman, Benjamin Fellows, Marcel Gehlen, Melissa Eaden and Thomas Harvey


Still not convinced? Here are a few examples:

Examples

Impartiality
This card is a result from a RiskStoming workshop. Questions started arising such as:
What if the person sat in a wheelchair?
What about facial types?
What about people of colour, different genders…

With the new rage of ‘Artificial Intelligence’ that is being taught by ‘data on the internet’, or whatever subset we feed it, this ‘new’ Quality Aspect is growing ever important.

Will your product amplify our biases & prejudices, or will it enable us to do something about it?

Dark Launch

 

 

“Releasing a project shouldn’t be a big deal anymore, certainly not a reason to party.”

Using Dark Launch, you can minimise risks in releasing by greatly lowering the target sample. Combined with several monitoring techniques, this can be a very cost-effective way to mitigate risk.

 

Distributed Systems

 

 

 

 

 

I guess this would qualify as a ‘new shiny’. Microservices have been on the rise for some time now and they certainly have their use in a great many products. Not all of them, mind you, but many.

They add a layer of complexity that rises exponentially with each added system. They come with their own risks. Risks you better know about when testing these systems as a whole.

In my experience, very little people are actually testing ‘the whole, connected system’, but are content to make suretheir own small microservice does what it should.

 

Feature toggles

 

Another staple in ‘new ways of releasing’. Feature toggles lets you (theoretically) test safely in production. They allow for very, very cool tactics in releasing software.
Just make sure you don’t overdo it.

There’s usually not a good case to keep feature toggles for a long time. If they have fulfilled their use, remove them.

Exploring Company Ideology

Beren Van Daele, Running Isle of IT

The world is undergoing an interesting transition. People being isolated. Negative economic impact. Personal stress, anxiety and financial harships. This is a time that will shape our future in ways we can’t quite imagine. On the other hand there are many positive initiatives rising up on social media. People offering help to the weaker. Companies taking up their social responsibilities and large scale empathy.

Challenging, interesting, worrying.

“Worry, but know that worrying is as effective as trying to solve an algebra equation by chewing Bubble gum”
– Baz Luhrmann

 

Over the past two years my company grew from a one-man-show to a micro-organisation of four. This corona virus situation is also the first real threat to our business since its conception. It’s the first time our company, our values and people are under fire. This post explores several experiences I’ve had in the past days and dealt with in my personal way.

No Secrets, Fairness

The spread of the virus is fast. Very fast. Yet in human time, a couple of weeks, days even seem long when you’re right in the middle of them. We had just hired our fourth team-member and were looking forward to Test Bash Brighton, an event that which would be a milestone for us. As the days unfurled, the certainty it would be cancelled and the questions of personal safety & planning grew unbearably.

When the event was finally cancelled, it was a trigger, at least for me.
I shared to the team an explanation of our financial situation. That it is stable enough for none of them to worry about their jobs at least for several months. The priority is each of our health, both physically and mentally. Daily, we check up on each other.

Because we are a fully transparent company, they know exactly what kind of money we have on the bank, what’s coming in and going out. I gave it to them straight, as I always have. I enjoy the conversations, the ideas and discussions we have and the mutual understanding it brings.

Joanna kicking off ITMatters meetup in Wroclaw.

Joanna kicking off ITMatters meetup in Wroclaw.

Stability & People over Greed

People approached me with suggestions to cut their personal wages by a third or even half. They felt they could make do with less and help the company survive longer with these sacrifices.
I refused.
When we started working together we signed a contract. But much more than that contract, I made a pledge to them, that as long as they are comitted to the survival of the company, the company will support them back. If I can not pay them what they were promised in times of trouble I will have failed them miserably.

Maybe I’m too idealistic and/or I’m unaware of my privilege, but when I read that big companies are cutting down wages or forcing unpaid leave I get very angry. Paying people what they are promised is the absolute bare minimum an employer is obligated to do. It may be easy for a small company to point fingers, but in my opinion these things scale. If you’re in trouble within weeks of a crisis, you’ve been consistently taking too many risks, no matter how big or small you are.

Move Forward

Several things aren’t great for the company. We have just hired a new junior, who’s awesome by the way, but who would now need to find a project in a more challenging market. I’ve not been on a project for three months and one of the teammembers told me to get a project to help out with the financial situation. I love the fact that he felt empowered enough to tell his employer to step up his game. I applaud him for it. (If you have need for an experienced remote working Quality Coach/Product Owner or a junior Tester/Front-end Developer, get in touch!)
On top of this, we’re organising three events for ITMatters.pl this year which face uncertainty whether they’ll happen in the first place. Sponsorship is harder to come by, speakers are more anxious to sign up for new gigs, not to mention finding participants. Finding business is harder, but let’s not let that stop us.

After explaining the team our financially stable situation, that they will keep getting their montly wages and their focus now is on their physical and mental health, the last message to them is to be brave. Adapt if necessary, but keep your projects going forward.

Aline & Geert trudging muddled waters.

Aline & Geert trudging muddled waters.

My Learnings

Deliberate exploring leads to new insights. I see this whole new situation as a chance to understand myself a bit better, what I want to stand for and what I want my company to be. I’m looking for vocabulary to put under words the ideology that is behind Isle of IT, but I haven’t found anything academic or helpful yet.

So in my own words:
I imagine a company of 6 people in total, not more. People who’s responsibility is the sustainability of the company and their own selffulfillment. A place that is fully transparent, fair, open-minded and progressive. Where people listen to each other, more than they speak. Where everyone’s peculiarities, skills, quirks and special powers are valued and openly appreciated. If you still think this is too fluffy and not competitive business-wise, I’m happy to have a chat with you.

I personally think this is the future. That more people will become fed up with the powerlust, greed and fear that governs many big companies and that they’ll build their own micro-businesses that feel more like a family than a machine.

It certainly is a future I’m building for my own and those who want to be part of my family.

Things don't always go as planned.

Things don’t always go as planned.

Releasing? No big deal.

Experience Reports

I’m jogging around in the park when my music suddenly stops and my phone vibrates.

– “Hi, I’m a bit… out of breath, how… can I help?”.

— “We have an issue in production. Our new release is eating away all the server   resources of the server, interfering with another product.”.

– “Ok. What can we do about that?”

— “We need to shut it down.”

– “Fine, shut it down.”

20190804_134955

Biking around the Mt. Blanc

There was a bit more to this conversation, as I wanted to know whether anyone had noticed our product’s malfunction and whether they’d notice if we would shut it down. Plus I wanted to know what would happen with the sending part of the system once we shut down the receiving part. It was a very short conversation though, where I made a quick and straightforward decision.

If this isn’t DevOps…

Why was this so easy? Why wasn’t I concerned/mad/fearful/…?
I was fine, because I understood the situation. 

I continued my run and after some time sent an email to the stakeholders explaining the situation. I started with an apology for the inconvenience, a congratulation for the great teamwork and communication and ended with the sentence
‘if this isn’t DevOps, I don’t know what is.’

The team had told me that the architecture had some possible malfunctions, that it might not scale well. But we had to learn exactly how badly it would be.
We decided to test this in Production. 

20190706_163416

Cat is not impressed.

Some context

We’re using the strangling pattern on already existing functionality. This means that we’re making a quasi-duplication of already existing systems, have them run in parallel and monitor the outcomes. When the outcomes are the same, or better, over a period of time, we know we have successfully replaced the old code. Then we can shut down the old legacy system and have our new one running as a cheaper, faster, better, more maintainable and future-proof system.

The first several releases are all about learning. ‘How do people react to a new, albeit badly, UI?’, ‘How much load does a production-like environment produce?’, ‘Can we integrate with the security partner’s software?’, ‘Can we display our new UI within the old UI without issues?’,…

Minimal Viable Experiments

We’ve learned a ton by experimenting with adding minimal changes and small valuable updates. We engineered the situation where this is possible. We have a management structure that supports this, yet is currently still a bit suspicious. We have the people who can make this happen.

We have the conversations, the vision, the strategy and the shared understanding.
I draw ugly pictures like this:

DWSB.png

What our next release strategy looks like. Simplified.

These ugly drawings don’t make sense when you look at them, but if you were part of the conversation, this is like a vacation picture where you fondly remember the moment and the outcome.

We don’t just talk about finishing User Stories. We talk about making an impact. Saving costs, making money, learning something new that will enable us to make the next move.

During our Blameless Post-Mortem we figured out that the architecture needs a drastic change. This change has been done now, which raises the question: ‘How shall we test this?’.
Remember the ‘sending part of our system’, that didn’t have a receiving end anymore? It amassed a big set of data over this past time and… well,… we could just point that to our new system and see what happens.

This is one of the parts of my job I really love. Strategising, discussing and thinking outside of the box to do a good job, doing it stress-free and doing it with people you enjoy working with.

20190602_173228

Complex structures: Monorail in Wuppertal

We have principles such as:
Bulkhead: Where you have different systems run on separate resources, so that they don’t interfere with each other. The only other impacted product was also an experimenting one.
Feature toggles: Virtually, this is a switch you flip to turn a system, or piece of a system on and off, much like a light switch. *click*, now you see it. *click*, now you don’t.
Dark Launches: We use pilot users, whom we can monitor, talk to, gather feedback from and learn, before we launch to the rest of Production.
Strangler Pattern: Explained above, this helps mitigate much of the risks of developing something new into the old.
Shadowing: Running our new software in Production, but completely invisible for our users. It helps us analyse load, investigate the outputs and evaluating its value.

But also: Eventual consistency, Distributed systems, Logging, Monitoring, Alerting,…

Releasing doesn’t have to be a big deal,…

  1. If you carry them as a team.
  2. If you’re smart about them.
  3. If you create a shared understanding.