To my dismay, there are still a lot of teams that keep aside capacity in their teams to “do QA” after a story is marked development complete.

By that it usually means that there are some people in the team whose sole responsibility is to manually test every story post code-changes.

This is terribly inefficient, and must be changed. This is the premise of this post.

Why is it bad?

In most cases, the testing methodology being manual means that it is

  1. Expensive, because it takes time. It is also repetitive.
  2. Prone to error, because humans make mistakes.

These are fairly solid reasons to…


I often found teams convincing themselves that they don’t do flow control using exceptions, because they don’t do constructs like a ResultException as described in Ward Cunningham’s wiki.

Things may not be that bad in most of these teams.

But I’ve seem exceptions being used in ways that are very close to flow-control, especially when the presence of said exceptions is used to trigger complex business scenarios.

You might have also seen that this indeed an oft-used method, so what is so bad about doing using exceptions this way?

1. Exceptions can increase cognitive-complexity

Rampant use of exceptions in your code-base can make it difficult…


From my earlier posts, it might become evident that I am a fan of trunk-based development within small teams, if circumstances were to allow for it.

However, as many of you might have seen through your careers, those circumstances aren’t always available. A well known, common and (dare I say) battle tested alternative is the pull-request model.

Image for post
Image for post
Work together to get better results [Photo by Baihaki Hine from Pexels]

The Problem with Pull-Requests

The pull-request model gets a lot of hate in certain communities, and it is not without merit, I might add. Some of the frequently leveled accusations against the working model are

  • I can’t get my code reviewed on time!
  • I have so many…

Image for post
Image for post

I had a couple of stints at teams that did not do estimations, and I then began to realize how much of our time we waste under the guise of “estimation sessions”

The management or your client absolutely requires to know the delivery date of a piece of software, which is a very fair ask, I might add.

For this, team usually does the story-point estimation game. They come up with a point-based estimate that corresponds to the complexity of a task. The client/business has a total number of such points that the team are known to do within a…


This post will reference only the -original- 1993 movie. The sequels were unnecessary cash-grabs, and I will pretend they do not exist.

Image for post
Image for post
https://commons.wikimedia.org/wiki/User:Malpass93

And don’t even get me started on the current trilogy.

Now that we got that rant out of the way, Jurassic Park having lessons for software development (or technology, rather) is pretty unsurprising, considering the movie was based off a novel by Micheal Crichton, who frequently used plots around technological advancements going wrong.

These are 5 things I personally picked up from the movie I believe applies to our careers as software engineers.

1. Just because you can, doesn’t mean you should

Ian Malcolm, a character in…


Image for post
Image for post

In this article, we are going to talk about PACT tests, which is a form of Consumer-Contract-Driven-Testing. For more information on what PACT is, please visit this link

Scope of a Provider Verification Test

A frequent question that came up in a couple of client engagements where we had used PACT testing was regarding the scope of the Provider verification test: just how much of the application gets tested as a part of such a test?

If you were to follow the official documentation and suggestions provided there, I’d say the options are really wide open for you and your team to choose:

  1. Stub all classes…

I happened to see this type being returned from long function call today, that set me down a rabbit hole

Try<CustomerInquiryResponse?>? 

But first, what is a Try?

It is a construct from the Arrow library, which is used to wrap the result of an operation to be either a value (if the operation was successful) or an Exception, if the operation raised an exception. Have a look at the documentation here for more information.

All good, but what caught my eyes was the fact that the Try was wrapping a nullable, and the Try object was itself nullable.

Let’s have…


It is fairly easy to convert callback based code into Kotlin coroutine based code, bringing with it advantages of having asynchronous code that looks very much like synchronous code, promising easier readability.

Here is some code where we make a call to an API using the OkHttp library, with a callback to handle the response:

To test if this method works, we write a test method that look like the snippet below. Considering that there is a callback, I have had to use the awaitly library.

Image for post
Image for post
Yuck!

Coroutines can make this look better, I promise. Let’s get started.

For…


Quite recently, when we changed some of our code to use CouroutineScope.async() instead of GlobalScope.async()

When doing this, we came across an interesting exception that was thrown.

Image for post
Image for post
Screenshot

This was the offending code, simplified for the sake of demonstration:

thatCallsTheLastFunction() throws the exception above.

Weird.

If you were to have a cursory look at the stack-trace in the exception, you might guess logback might be the culprit.

And it indeed is: https://jira.qos.ch/browse/LOGBACK-102 7.

What is happening is that logback will not be able to print out an exception, if it were to have a suppressedException that is a circular reference…


Our team uses Jetbrains/Exposed for all database interactions in our Vert-X based Kotlin project. Over time, we wanted to migrate away from an ORM and use vietj/reactive-postgres-client instead.

Image for post
Image for post
These vines would one day completely cover the wall, but it does so slowly, and step by step.

All database related code in our project was encapsulated within repository classes. As such, we merely need to swap them out with new versions of repository classes that used the reactive-pg-client driver, push changes to production, and end the day with a pint.

Pretty simple. A win for layered architecture and SRP, I might add.

However, such a simple switch over, I think, could come with some issues:

  1. Switching over all the…

Vineeth Venudasan

Learning to be a better developer everyday.

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