Skip to content

Instantly share code, notes, and snippets.

@gernotpokorny
Last active December 30, 2023 16:26
Show Gist options
  • Save gernotpokorny/0bf08c598a7f410bc1fcf359ef3882ff to your computer and use it in GitHub Desktop.
Save gernotpokorny/0bf08c598a7f410bc1fcf359ef3882ff to your computer and use it in GitHub Desktop.
Agility

Agility

You are not working agile if you do not test your software

Agile working is about bringing people, processes, connectivity and technology, time and place together to find the most appropriate and effective way of working to carry out a particular task

For most companies "agile" is just a buzzword for marketing purposes, they are not really working agile. I claim that testing is the most effective form of collaboration in software development, there is nothing that comes even close to it. This is very important — testing is COLLABORATION. I claim that when you do not test your software you cannot claim to be an agile working software company, especially at scale.

This becomes very clear at scale at big software projects. There is simply no way to claim that you work agile when you do not test your code, just because you hire a Scrum Master or a Product Owner or whatever and/or introduce another daily/meeting.

Just to give you an example. Lets say one of your Devs writes a new feature and introduces a bug in a SQL statement. The SQL statement seems to work fine for the data he is working with. The SQL statement just works by accident, because SQL has undefined order behaviour and for other data sets it does not work. So he introduced a bug, he was not smart enough, basically a donkey. This is just a joke of course, this happens. He just fixes it, writes no test, no comments, thinks it's enough to tell others about it in the daily/weekly or whatever — maybe even 15 minutes or half an hour plus — and moves on with his life. The next Dev who works on that piece of code in the future might not even be at the daily/weekly or whatever at this point — for whatever reason — or even at the company. He might not even be at the company when the next Dev works on that code in the future or he completely forgot about that piece of code in a few months. This are just examples, there are of course even more scenarios. That is what makes meetings so ineffective. Write code instead, bake it into the tests instead of just telling others. Writing tests is so much more effective. We could even go as far as saying if you not write a test you are not collaborating, which is probably the case and something to think about.

A few months pass and another Dev sees that code and thinks. Why is that second ordering there in the SQL statement, this is not necessary, it should work without that, basically he is the same donkey as the first Dev at this point (joking of course). He removes it and celebrates his achievement of making the code more concise and more readable by removing some unnecessary code. At the daily where he celebrated that achievement — the first dev was not there, maybe he was sick, had to be somewhere else due to his/her child, maybe was not at the company anymore or maybe he even was at the meeting and did not pay attention or just did not remember that problem anymore, the list goes on. A few weeks pass and a ticket comes in to the huge support team (support team has to be bigger when you do not test), where a customer claims that something does not work which already worked. An issue gets formed for the Dev and he just basically reverts his commit and tries to sweep under the carpet.

And the cycle repeats.

Does this sound familiar?

This is by the way how most software development companies work.

Some old companies are not to blame (because there were times, even just 10 years ago, were all tooling for colloboration was not existing or are in their infancy stages), but newer ones are.

This is no form of agile collaboration. If your company works like that you are not working "agile".

The best thing to do would have been write tests for the various different cases and also document a few lines in the test case what this test case is all about especially when you think that others also might not know what you did not know in the first place.

Big software projects become very hard to maintain without tests and most likely when the company does not write tests, it is almost a certaintiy that the codebase is also a whole mess. They then hire another PM to harass Devs and increase the meeting frequency and think that makes them agile. They are wrong, this decreases your efficiency, because you have such big problems and take time away from Devs — who are the ONLY ones who can solve them — to solve them.

Frameworks, devops and testing are a prerequisite for agility.

And of course you cannot effectively test and collaborate without having a DevOps Platform for effective collaboration and frequent integration of code into the main branch.

Using state of the art tools like modern development frameworks is also a prerequisite for agility, because they replaced the old tools for good reasons. One of them being efficiency. If you work with legacy tools you cannot claim to have an agile workflow.

Also chatgpt has me covered.

User:

Would you claim you can work agile without testing your code?

Chatgpt:

No, effective testing is an integral part of the agile software development process...

User:

I would say it is a prerequisite for agility you cannot be agile without testing

Chatgpt:

I agree with your assertion. Testing is indeed a prerequisite for agility in software development...

User:

It's not just about meeting requirements and quick feedback and so on. Testing is a form of collaboration. In fact is is the most effective form of collaboration. If you fix a bug and don't write a test and just tell others in a meeting this is not effective.

Chatgpt:

Absolutely, you make an excellent point. Testing indeed goes beyond ensuring requirements are met and obtaining quick feedback; it is a form of collaboration in itself. Writing tests, particularly automated tests, not only validates the correctness of the code but also serves as documentation and a form of communication among team members...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment