Is there a relation factor between meeting time and saving development time?

Question

I am working on a project and we have regular (usually weekly), informal meetings, where we discuss the status of the project and the GUI of it.

I'm the only developer there, the other 4-5 people have a non-IT background.

This meeting took much longer than usual, but at one point, one of my colleagues asked about some fields in the program and how they get filled. I answered and in the discussion I noticed, that I totally got the process wrong in my mind.

But since we talked about it and found the error beforehand, I can change it pretty quickly.

While thinking about this, I've asked myself, if there is a factor between meeting time when it comes to saving development time?

For example 1 minute of meeting time might save X minutes of development time.

If so, this would help is to define, how often and how long our meetings should be.

(Just to clarify: I dont want to make better meetings, even being able to determine roughly the length of the meetings is optional. I am mostly interested IF there is a relation between meeting time and development time! My reason to ask: curiosity!)

Answer 1

"As long as they need to be, and no longer."

The thing to realize here is that meeting time to saved development time is in no way linear. For your team, for your company, for this topic, then 1 hour of meetings might save 2 hours of dev work. If you have 10 hours of meetings, another hour of meetings might save 0 dev work. Hell, it may save you -2 hours of dev work due to interruptions or impact on morale.

In the end, the entire point of meetings is that the communication and collaboration helps you get things done. If meetings are not helping you get things done, then they should be killed.

Answer 2

Not exactly.

Understanding the customer/stakeholder can save development time. And conversations need to be long enough to facilitate understanding. But, discussing a feature you already presume to understand will not necessarily improve your understanding.

If no one in the room has any suspicions of misunderstanding or false assumptions, leave the room. Artificially prolonging a "discussion" in the hope that the shear time and pressure will push a conflict out and create harmony is hopeless and demoralizing.

And remember that communicating is a combination of skill and luck; discussion doesn't necessarily imply communication (mutual understanding). You'll all get better at exposing bad assumptions the longer you work in the field, and the longer you work together.

In the meantime, "Agility" can be helpful.

Keep meetings "short" and implement crude UI's or mockups as soon as possible after each meeting -- well before you even suspect to have a full understanding. Your UI's/mocks will serve as material for clarifying misunderstandings. The time between meetings will help everyone decompress and reflect on what was said. And if you implement your show-and-tell materials in code, you've also actually started on the development. (And your customer/colleagues will be thrilled to hear this!)

And the worst case scenario, when you've implemented a small chunk of visible code: You're totally off base and you throw it away. But, if you've only dedicated a small amount of time, the investment pays off big in clarifying gross misunderstanding.

And remember, the company doesn't care about development time; it just cares about person-time. (As a means of calculating total cost, mind you.) So, you need to be looking for the balance wherein person-time is minimized; not time spent writing code.

Answer 3

I don't believe there is any sort of correlation there that could be generally applied. It really depends on the meeting and the things you do there that relate to development.

In the situation you describe, in a few minutes you went from having a bad or poorly understood requirement to having a better one. We know that having good requirements has a direct impact on development time.

But what if your meeting was something like a company status meeting. You share good information so you know how the company is doing, are aware of other things going on, etc. But, for the most part, that won't have any effect on the development time on your project. All that time is "wasted" when looking at it from a development perspective.

Once you've had to go to enough meetings, you begin to realize that some are really productive (ex. take a small dev team and a good set of requirements and start whiteboarding an architecture. You can get a lot done if you stay focused.). You also find some that are not productive at all or even have negative productivity (once had a customer have a 15 minute debate between a few of them as to whether a login page should say "Log In" or "Log On". At the end of that, no one knew and it had to be tabled until later).

TL/DR: Depends on the meeting, the people and the objectives of the meeting.