Perception of Done – The Bigger Picture

Andrej Kaurin

Author at JSGuru

Every player has its own perception and vision of what is “Done” and for each is very easy to omit the other player’s perception, not because of irresponsibility but because of their own view of what is the most important part of the final thing.

Just recently a funny story happened. The CTO and developer spoke, and conversation looked something like this:

CTO: Hey, How’s going? What is the status of The App?

Developer (Proudly): Hey, great. It is done!

CTO: Really? Great! Let me download it from the App Store and try it myself.

Developer (Surprised): Wait…Wait! It is not yet on the App Store.

CTO: Ok…So we are waiting for the approval from their side?

Developer: Not really. We haven’t sent it for approval yet.

CTO (Also Surprised): Ahhh, I see…Can I download it from our build system?

Developer: Well, not quietly. I haven’t set up the build.

CTO: Don’t worry. Can you just quickly show it to me from your local?

Developer: Of course. Here it is. Let’s just wait for the build to be done…wait…wait…Damn! Tests are failing. Can I show it to you tomorrow, just to fix this?

Software development exists for decades, but this story is happening all over again and I am sure many can identify themselves (on either side). If you type “Definition of Done” in Google as a very first result you will find, of course, Google’s dictionary definition of the word “Done”. Next results will be a bunch of agile definitions and principles to follow on this subject. Majority of resources focused on the process of ensuring the desired output is met by stating clear and precise definitions.

While all those are correct (and very useful), I believe that we are missing the bigger picture here. All these definitions are based on the theory that every person in the process has a unique idea of the most important values of the product. Saying differently, all these definitions are based on the idea that we all agree on what are the pillars of the final outcome. Even I strongly agree with the statement that this should be the case, I am aware that we are living in the imperfect world where the things are rushed and the project initiators are keen to see (or show) something ASAP. In the perfect world, every project would start by closing all the participants and stakeholders in one single room and not letting them out until they agree on the outcome.

And what would then be the “definition of done” having the bigger picture in mind? We will come to that later, but let’s first examine how the definition of done is shaped in the mind of a person. I have my own idea about that. Here it is:

“Definition of done is based on the individual perception shaped by that person’s principles and the role they play in the system”

I am sure you have no idea what I just said so let me elaborate. Definition of done is simply, based on different perceptions from different individual players/roles in the entire process from production to customer and it is strictly shaped by their own opinion of what is the core value of the product and service.

And again, I believe that you are still confused. Let’s examine different roles and see their own views on the subject.

Database Engineers

These are data and relation oriented fellows. “The database is the single state of true of the entire project from now to eternity. You can lose your API, you can use your frontend, but if you lose the data you are doomed. You can optimize your UI and API as much as you can, but if the indexes are not set, your app will frustrate with the slowness.” I can almost see the database engineer climbing on the pedestal and yelling a few previous sentences. And we cannot agree more with the statement. The data is the core of most of the systems. Their job is done when the database is protected from dirty data, all indexes set, etc.

Backend/API Engineers

Backend engineer is turning toward database engineer and speaking: “Database is storage. What’s the use of data if I do not make an interface for all to consume it? We don’t need optimizations and indexes, we can use the in-memory caching system. And even more, we can replace this DB with another one with API intact”. These are very logic oriented fellows following the algorithms to process data and deliver it to the ether. Once API endpoints are secured and data is delivered their job is done.

Frontend/UI Engineers

Now, Frontend engineer is turning toward Backend engineer speaking: “I am the master of the interaction with a user. I am here to make a order in all this information and show it to the user the right way”.

Frontend guys see themselves as a face of the entire system. And I cannot disagree. They represent the interface for the ordinary humans to the part of the system representing the black box for the non-tech users. Once they convert JSON into UI form and button is responding on user click – they are done..

QA Engineers

By definition “A quality assurance engineer creates tests to find any problems with software before the product is launched. They identify and analyze any bugs found during testing and document them”. The more suitable definition would be “QA engineers saving the a**es of the previously mentioned roles and entire project/company”.

Those are guys enjoying finding bugs and reporting it. Occasionally they are frustrated with how obvious was a bug they found and how others couldn’t find it. Repeated bugs – big crime.

I hear them speaking loudly: “You shall not pass!!!” (You are imagining Gandalf from the LotR?). At the moment they raise the issue and send the 2 pages long bug report to the project manager their job is done.

Project Managers

If you can imagine unexperienced kindergarten teacher trying to handle 20 children than you can have a little bit of the picture of PM’s work. They tend to know everything giving trouble to the tech guys trying to understand things they really cannot. “Can you explain this to me speaking human words?. The burden of the project success or failure is on their shoulders and they wear it proudly. Project managers are the bridge, the translators between tech and non-tech user”. Their job is done once the client confirms the feature works the way they always dreamed about (even they had 3 or 4 different dreams on the same feature during the time).

The Client

Here we come to the “big boss”, the one who took the mortgage to finance the project, the one who does not sleep at night thinking of all possible scenarios if the project fails. Even this one is the most important stakeholder, it is also the most simplistic in his reviews. Things for him are either working or not. You will mostly get inputs in one of the following formats. “This is broken!”, “This does not work”. “If you need me to explain the issue in more details than I could do it by myself”.

To best describe The Client’s perception I have another true story.

The client is calling the project manager.

Client: All my data is lost!!! I will sue you.

PM: Please come down. I will check right now.

PM is now calling the lead engineer

PM: All client data is lost. He is going to sue us. Check now!

Lead Engineer: Ok, stay on the line. I am checking.

(10 seconds later)

Lead Engineer: All data is here. I just looked into the database.

PM is calling the Client.

PM: All data is there. We just checked.

Client: Are you messing with me? I am looking at it and all data is gone.

PM: Can you please share me the screen?

(2 minutes to figure out how to share)

Client: Here it is!. Look. All is gone (Showing browser with the empty page).

PM: Ahh, I see, you are actually looking at the application. Let me call you back in a couple of minutes.

PM is calling the lead engineer

PM: Hey, he is actually looking at the application itself. It shows a blank page.

Lead Engineer: Let me look. Ahh, I see … certificate we are using is somehow expired. Let me fix it (10 seconds later). Here it is. It works again.

PM is calling the Client.

PM: You data is back again.

Client: Thanks, you are the best.

Point of this story is that for the client, done means that he can actually use the application. He does not recognize all these layers building the application and he does not care at all. If he does not see his data – the data is gone.

Conclusion

We saw different perceptions of the different roles and mindsets involved in the process of building software solutions. I was sarcastic with the intention to give an overview of dysfunctional systems where each party is looking only inside their own barriers and comfort zone. Sadly, these models are not that rare in our world.

To stop being pessimistic I will try to give a couple of pieces of advice on what should be considered as a good practice to achieve the real “Done”.

Communicate and get out of the comfort zone

Each party involved should try to be informed about other party work and issues. It is difficult sometimes, but talking to each other we can gain the perception we are not aware, so be a good listener.

Put yourself in the client’s shoes

The goal is to put yourself into the client’s shoes and try to feel all the challenges the client might have with software devs and entrepreneurship in general. This might change the mindset of devs when developing somebodies dream. They can’t understand all the tech terms, but they will appreciate good advice and ideas.

Never hold the client in the dark

If the client does not know what is happening he can’t help. Moreover, they are becoming nervous and you are losing their trust that you can actually do the job. Once you establish the trust – the sky is the limit. Everybody wants to work with people they trust.

Do early trashing

Present your work to the client as much as possible. Ask for an opinion. Do the prototyping, not with ‘uerwqtryutqeyw’ data (garbage) but with data similar to the real ones as only this way will give you valid review.

Think about UX

User experience is the final validation of your work. First of all, use best practices and recommendations. Then, find a focus group and test the different scenarios. Validate your assumptions.

Make a solution that you are proud of

Be honest to yourself. If this is the app you would use itself and be proud of, then you made a really excellent job. If you are even afraid to use it or its usage is making you frustrated, then stop and go back. See what could be done to fix the frustration.