You are mostly pointing on implementation details and i agree. I also agree that developers cant do everything. But I think that developer have to heavily understand bussiness rules to do a good job. Bugs was not correct twrm i used. I meant those error when client was expecting software to work very differently than its implemented. Most of the time it is lack of precise conversations. Conversations are managed by managers and manager is maybe neccesary.
But I think that developer have to heavily understand business rules to do a good job
that's right but you have to ask yourself, so if you have 20 devs, all of them should talk to the client?, that will not be a happy client, that's why there are positions to do that, talk to the client and summarize and transform all the messy requirements that the client have, and sometimes only think they have, and rely it to the devs, that's why abstraction are vital, to implement a low level part of your code shouldn't need to know the whole system, the devs who wrote the libraries you use have no idea in what you are working on.
Clients usually have a vague at best idea of what they want/need, and with a lot of "thingies" and "stuff", to get good requirements is an art on itself, of course it could be better to devs to talk to the users, but sometimes is not an option and sometimes it would muddy the waters. In fact in my experience you don't want to increase the communication with clients, you want to improve it, a thousand meetings will likely give you a thousand new and different sets of requirements. The perfect scenario would be 1 perfect meeting where all the requirements are plainly and well defined. Also we have to respect clients time, they have their own business to deal with, not waste their time is very important.
True indeed. Now I am realizing that blog post is so personal. I am developer with smaller project. I am working alone and i am covering every technical discipline on project. Then I have a manager which one analyse client requirements and sometimes we made a miscomunicstion mistake.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You are mostly pointing on implementation details and i agree. I also agree that developers cant do everything. But I think that developer have to heavily understand bussiness rules to do a good job. Bugs was not correct twrm i used. I meant those error when client was expecting software to work very differently than its implemented. Most of the time it is lack of precise conversations. Conversations are managed by managers and manager is maybe neccesary.
that's right but you have to ask yourself, so if you have 20 devs, all of them should talk to the client?, that will not be a happy client, that's why there are positions to do that, talk to the client and summarize and transform all the messy requirements that the client have, and sometimes only think they have, and rely it to the devs, that's why abstraction are vital, to implement a low level part of your code shouldn't need to know the whole system, the devs who wrote the libraries you use have no idea in what you are working on.
Clients usually have a vague at best idea of what they want/need, and with a lot of "thingies" and "stuff", to get good requirements is an art on itself, of course it could be better to devs to talk to the users, but sometimes is not an option and sometimes it would muddy the waters. In fact in my experience you don't want to increase the communication with clients, you want to improve it, a thousand meetings will likely give you a thousand new and different sets of requirements. The perfect scenario would be 1 perfect meeting where all the requirements are plainly and well defined. Also we have to respect clients time, they have their own business to deal with, not waste their time is very important.
True indeed. Now I am realizing that blog post is so personal. I am developer with smaller project. I am working alone and i am covering every technical discipline on project. Then I have a manager which one analyse client requirements and sometimes we made a miscomunicstion mistake.