6 ms·

The post really rubs me the wrong way. > If the biz says, “Jump,” many devs ask “how high?” or just do it. It is the same with requirements or workloads. Ther

The post really rubs me the wrong way. > If the biz says, “Jump,” many devs ask “how high?” or just do it. It is the same with requirements or workloads. There is only so much push back senior, let alone junior, developers can give. Having "soft skills" helps a lot with this, especially when alternative solutions can be proposed or your force the people with real power to assign _actual_ priorities to work. (i.e. "I'm sorry I've not done anything for your project, the VP told me to work on this other project. Please consult with them if you believe yours is more urgent.") > A recent example makes that more clearly. Take a dev team, who build a new app from scratch - greenfield. They chose a document store but modeled their domain objects in a relational way. Now X features and iterations later, the performance went downhill… Yet, no one admits the wrong architectural decision. But anybody complains about it - even the devs. Bad monolith. There are also real consequences to making large changes to something like a datastore. The amount of time and risk is hard to calculate, and for a non-tech business hard to justify when there are other issues requiring developer attention. I think what I dislike most about this post is that it continues to perpetuate the feeling that the developers and the business are on separate "sides" or otherwise the post ignores concerns from the rest of the business. It's really about trust. If you, as the developer go "this is going to take 3 weeks" and the asker goes "but I really, really want it in 1", the two sides need to trust each other enough to honestly discuss the discrepancy. Could some MVP be rushed out, but the follow up 2 (or 3) weeks _be scheduled now_ to clean up the rough edges, ensure formatting and full coverage test suites are finished, &c. If the developer doesn't trust the asker to be reasonable, and the asker doesn't trust that the developer honestly needs some additional time, negotiations cease and someone winds up unhappy and the business as a whole suffers from either a later product or additional tech debt. I think most people, not just developers, have a hard time understanding that if you can or simply how to frame "non-productive" time in terms of the business' bottom-line or risk, you'll have much more luck (but no guarantees, some people just don't care about your opinions as their underling unfortunately, but I would say most do). For instance, maintenance of a mechanical system leads to downtime and increased operational costs. However, that maintenance increases the reliably and operating life of the mechanical system. For code, just building in a little time for each issues' estimate for cleaning, testing, review. Why is this important? Reviews help familarize other team members with the implementation of new features, minimizing the single point of failure. Tests help to spot coding errors or conflicting business priorities at a later date when the details of this specific product may not be fresh in everyone's mind. Cleaning up/formatting code enables more of the team to jump in and fix issues, again reducing the single point of failure. All of these together help ensure that the code is less likely to randomly "break"/not handle certain cases correctly as well as enable anyone on the team to take up a bug with a reasonable expectation that it won't balloon because no-one knows how the feature works. Anyway, the issue has nothing to do with monoliths vs microservices and everything to do with the trust and communications between different parts of the business.

Jtsummers 8y ago
> I think what I dislike most about this post is that it continues to perpetuate the feeling that the developers and the business are on separate "sides" or otherwise the post ignores concerns from the rest of the business. Thanks for pointing this out. This is critical. If each group feels they have a separate objective/goal that doesn't match the others (and the business as a whole) you'll get lots of problems. Communication breakdowns, months or years spent building the wrong things, etc. An organization needs to establish its objective/goal and direct its internal entitities towards achieving that goal. A misalignment of goals will create divisions within the organization that means it will, overall, fail to achieve its objective (or only achieve some unsatisfactory result, like being late to market or of poor quality).
azarai 8y ago
Trust is essential and I wrote about it before but left it out in this post. If the involved parties trust each other, they can accomplish great goals together. However, if you want to change a system or even build up trust, one can only start working at oneself. And that was my intention for the post, raising awareness that devs must change themselves and stop blaming other humans or even patterns for shit they (partly) created themselves. We can not change another person, we can only change us and maybe inspire others to join. Same is with trust. People do only trust you if there is a good reason for it. And you have to build that reason up over time. For example, if I can't hold my ground with given estimates, how can I expect that the other person trusts me (in that point)? Those sum up. In the end, often biz does not trust devs and vice versa. But I can't change biz nor the other devs, only myself.

Jtsummers 8y ago

> I think what I dislike most about this post is that it continues to perpetuate the feeling that the developers and the business are on separate "sides" or otherwise the post ignores concerns from the rest of the business. Thanks for pointing this out. This is critical. If each group feels they have a separate objective/goal that doesn't match the others (and the business as a whole) you'll get lots of problems. Communication breakdowns, months or years spent building the wrong things, etc. An organization needs to establish its objective/goal and direct its internal entitities towards achieving that goal. A misalignment of goals will create divisions within the organization that means it will, overall, fail to achieve its objective (or only achieve some unsatisfactory result, like being late to market or of poor quality).

azarai 8y ago

Trust is essential and I wrote about it before but left it out in this post. If the involved parties trust each other, they can accomplish great goals together. However, if you want to change a system or even build up trust, one can only start working at oneself. And that was my intention for the post, raising awareness that devs must change themselves and stop blaming other humans or even patterns for shit they (partly) created themselves. We can not change another person, we can only change us and maybe inspire others to join. Same is with trust. People do only trust you if there is a good reason for it. And you have to build that reason up over time. For example, if I can't hold my ground with given estimates, how can I expect that the other person trusts me (in that point)? Those sum up. In the end, often biz does not trust devs and vice versa. But I can't change biz nor the other devs, only myself.