How to build the right software in one go

These days, when we talk about 'a Babylonian confusion', we mean that there is misunderstanding between people. We don't understand what the other person is talking about. Unfortunately, I still see that around me a lot in software projects. In this post, I'll tell you where the problem comes from and how to fix it.

Promises and Assumptions

Between customer and developer, the confusion of speech usually starts with assumptions. It looks something like this:

Customer: This is my wish. Build this

Developer: OK! 🏠

A short story, but even here, the assumptions can be gigantic. The customer, who, by the way, is not business user need to be, it can also be a product owner go, a tester or another stakeholder, may think they know what it takes to make the product better. And therefore assumes that the said wish is a solution to the problem.

In addition, the developer can also make quite a few assumptions. I see the response that the developer gives above around me every day. You want this? Fine! I assume that you have thought about it carefully and will write nice code that will get this done. In this case, the confusion lies in the fact that the customer thinks that his problem will be solved once the developer has built his wish. The customer says “build this” but means “fix the underlying problem”.

The developer sees the assignment and exactly this command is executed.

I think it's important to add that in this situation, no one consciously disrupts the process. On the contrary: everyone involved wants to tackle the problem as quickly and effectively as possible. The problem lies in how we are used to communicating with each other.

If it doesn't go the way it should, then it should go the way it goes

So it's important to ask questions. Because by asking questions, you get to the underlying problem that needs to be solved. But it's also important when you ask those questions. Take a look at this scenario:

Customer: This is my wish. Build this

Developer: OK... 🧱... 🧱... ⏱️... 🧱 ... ⏱️ ... 🏚️

What happens here, and what I often see happening in practice, is that we get to work too quickly with the instructions we've received. The questions then come afterwards. From me, for instance, as a tester. Some of those questions can send the entire project back to the drawing board.

We used to try to solve this by working in a 'waterfall'. Before we started programming, we wrote out ALL the requirements in full and created functional and technical documentation. And what turned out? After all that extensive preliminary work, we still ran into new questions when building the software.

And answering them, plus processing the answers, took a lot of time.

It agile era has caused us to write down less in the corner of software development that I'm in. The second commandment of the Agile Manifesto therefore says: “Working software over comprehensive documentation”. And yes, working software is also the most important thing. But how do you determine that you are dealing with “working software”?

In agile projects, the time pressure is great and therefore the temptation to deliver something that doesn't really make anyone happy. And hope you get the chance to improve it in the next iteration. For example, “agile” becomes a synonym for “just not” or “tried it out”. To go back to our cottage: we imagine a nice new home, but we end up without windows, with the wrong color and with cracks in the walls.

I don't know any developer who is proud of this way of working, and sometimes it seems like there is no way out. But there is one.

proprietorship

What if, before we start with the project or feature, we have a more extensive conversation:

Customer: This is my wish. Build this

Developer: What's your problem?  

Customer: 🗣️

Developer: What if I fix it like this?

Customer: 👍

Developer: OK 🏡

I have something to confess

I often look to others when it comes to requirements. As a tester, I don't feel like I'm making up what to do. I'm just seeing if it works as specified. So actually, I'm often the one who shrugs and thinks “if this is what they want, it will be good”.

Not a good attitude, in my opinion. Because it often happens that later in the process problems arise that prevent an application from going live correctly. And wasn't it my job as a tester to prevent that? So you may not be the one in the team who creates the functional design or writes the user stories. And you may not be directly responsible for resolving the language confusion, such as the scrum master or product owner. But that doesn't mean you can't show ownership and take responsibility. Because even though everyone has their own function within a development team, all stakeholders have the responsibility to ask questions when things are unclear.

So whatever your role, KEEP ASKING if something is being discussed that you don't understand. Because it's probably not just you, but you either need more information to do your job, or you're on to a problem that, thanks to your question, can be solved at an early stage. So don't shrug your shoulders, but make sure you understand the 'question behind the question'.

A customer is not satisfied with the search function in an application and asks: “Can't you build in “google search”?” The development team does not think that is a good idea, but comes up with the suggestion to enable “fuzzy search” in the search fields and quickly roll it out to the customer.

Problem solved? Probably not

Because has the team investigated why the customer is dissatisfied with the search function? Do we fully understand what the customer means by “Google search” and how good is our translation to “fuzzy search”? Perhaps better filters are much more useful for the customer.

So the answer here would be to look at the search function with the customer, find out in which cases the results are disappointing and only then look for a technical solution. And, of course, asking the customer what exactly they mean by “Google search”.

Be patient with each other's questions

We often don't ask because we don't want to bother someone else. And we often respond impatiently to questions about — for us — the “familiar way”. We have to stop doing that.

Be patient with each other's questions. Do your best to really understand the other person. And realize that it may seem like you all speak the same language, but that the differences in “dialects” of developers, testers, product owners and business users are sometimes so great that it looks like you're building a new tower of Babel.

So first, look for common terms so that you understand each other. Make a genuine effort to learn each other's language and keep asking if you don't understand something. Only choose a solution together if you are sure that the intention is clear to you. In the beginning, this can feel like “making it difficult” or even “opposing”. Does that cause irritation? Then take the trouble to explain why you're doing so difficult and what the consequences of not asking questions might be. In my experience, these kinds of conversations actually build better relationships, and that always leads to better software in the end.

Go for 🏠 instead of 🏚️ and maybe you'll end up with 🏡!

‍