Depending on where you work, engineering is often one of the last teams to learn about an upcoming feature. A lot of the time it has already been discussed and debated by Product and Design teams, trying to hone in on exactly what it is they want to build, and then engineering gets handed the final result often present as: this is what we want to do, go do it.
Now I don't want to suggest if this is a good approach or a bad approach, because it really depends on your organisation and the individuals involved. But this often leads to really complex implementations by the engineers because they're trying to build something that might not make much sense from an engineering point of view.
This is especially true if you're working with contractors or junior engineers who feel like they can't push back on what they've been presented with and come to some kind of compromise. If you ask an engineer to build it, often they'll accept what they've been tasked with with excitement. This can sometimes be a good thing - we want engineers to be excited about what they're working on after all and eager to show what they're able to do - but sometimes we have to be pragmatic.
Without engineering involved in the process at the start, maybe there's a shortcut that they would have known about. This is all about compromise, and while Product and Design are compromising during the discussion phase at the beginning, Engineering doesn't get a chance to compromise.
If we consider the triangle of software development as Product, Design, Engineering, we have to be able to compromise on each of those, weighing up their pros and cons against each other for each individual piece of work we want to do. If Engineering is left out the loop, they just get the hard job of creating whatever it is that’s been decided.
If you involve them from the beginning, there might be a way we can Design a feature differently that makes the Engineering piece so much easier, giving us both short term and long term benefits. The same can be said for Product. Maybe we can drop a particular aspect of a feature because it adds too much complexity for the amount of value it provides.
This just has to be an ongoing discussion between all disciplines involved, and is something as engineers we need to do ourselves as well. Just because our job is programming doesn't mean we're limited to programming as the only way to solve a problem.
We can use design and product as ways to solve programming problems.
Now I don't want to suggest if this is a good approach or a bad approach, because it really depends on your organisation and the individuals involved. But this often leads to really complex implementations by the engineers because they're trying to build something that might not make much sense from an engineering point of view.
This is especially true if you're working with contractors or junior engineers who feel like they can't push back on what they've been presented with and come to some kind of compromise. If you ask an engineer to build it, often they'll accept what they've been tasked with with excitement. This can sometimes be a good thing - we want engineers to be excited about what they're working on after all and eager to show what they're able to do - but sometimes we have to be pragmatic.
Without engineering involved in the process at the start, maybe there's a shortcut that they would have known about. This is all about compromise, and while Product and Design are compromising during the discussion phase at the beginning, Engineering doesn't get a chance to compromise.
If we consider the triangle of software development as Product, Design, Engineering, we have to be able to compromise on each of those, weighing up their pros and cons against each other for each individual piece of work we want to do. If Engineering is left out the loop, they just get the hard job of creating whatever it is that’s been decided.
If you involve them from the beginning, there might be a way we can Design a feature differently that makes the Engineering piece so much easier, giving us both short term and long term benefits. The same can be said for Product. Maybe we can drop a particular aspect of a feature because it adds too much complexity for the amount of value it provides.
This just has to be an ongoing discussion between all disciplines involved, and is something as engineers we need to do ourselves as well. Just because our job is programming doesn't mean we're limited to programming as the only way to solve a problem.
We can use design and product as ways to solve programming problems.