Software development is hard. You don’t see everything behind the scenes, so let me give you a few guidelines that I hope we can agree on.
Estimates are called that for a reason. We do our best to figure out how long things will take, we will break tasks into something small enough that we can have some confidence in the number, but we’ve not built this feature in this software before. The only way to know how long something will take is to do it. And then compare the new features we’re working on to that. Given that estimates take effort, and need a lot of detail, estimating an entire system based on an elevator pitch will be about as accurate as guessing the weight of all the grey animals you can see on the horizon. At the moment, I can give you a lower bound if they’re mice, and there’s none hidden, and an upper bound if they’re elephants. If you want more accurate estimates, be prepared to give us more time and detail.
Users don’t understand requirements. You may understand what you do now, and you might have an idea about what you’d like to do, and you will understand whether completed software fits what you need, but written descriptions, visual walkthroughs, and any other design artefacts can only go so far in helping you understand how the software will actually work when you get it. You have ideas about what you want, some more concrete than others, and only some of them actually make sense to build. We’ll help you through the process, but if you can’t answer a question about how something works, it might be because what you’re asking for isn’t clear.
Developers don’t understand requirements either. We need to understand why you’re doing something before we can understand what you want. Your high level requirements that tell us to delete everything on Tuesdays when it’s raining, or that Pogmotians must be able to Fidoodle the Strittles don’t tell us why that’s important, so we will ask questions that you may have to think about hard. We want to build the software that helps you achieve your goals, so help us to understand those, not just the process of what you do.
Sometimes what looks easy is actually hard. But sometimes what looks hard is actually easy. I know it looks like “just” a change to add Google-style “did you mean” to our searches. But Google spent a lot of time and resources to figure out what you mean, and then a lot of effort to make it look easy. Making things look easy can be one of the hardest problems we have to solve.
You are the experts in what you do. If you want software that understands what you do, you need developers you understand what you do. We will work hard to build a relationship, so that we understand your business, because that’s how we write the right software for you. But like any relationship, it will take time. And sometimes we’ll fight, and sometimes we’ll be in sync.
We understand that sometimes you don’t understand. If you can be patient with us with the above, we can be patient with you when you want more detail on what we’re doing and why.
Respect us, we’ll respect you.