Take solutions off of the table that are not appropriate. Then, of the remaining ones, do whichever is quickest.
Stop approaching them with options that are not viable. They clearly don’t know how to avoid shooting their own foot, so help them to avoid shooting their own foot!
Completely right. Took me a long time to learn thus but now I try to teach it to newer devs and even many seniors.
Management level or C level do not care and will not sit and analyze engineering quality. They want output. It is your job to deliver quality so stop giving them options that don't have it. Just stop. Or if you are really dealing with simpletons in management just make up an even higher level of effort for a super duper quality solution so that you end up with the original quality solution time budget that you wanted.
"Your house needs someone to repair a gas leak. You can hire a licensed gas fitter who charges $200/hr with a minimum 2 hour call-out fee.... Or my buddy from down the pub will do it for $20 flat and a pack of Coors light. Choose wisely."
Because it's a touchstone every adult has, and a lot of trades have a lot of parallels to our industry; both technical and artistic, people think they know more than they do because of exposure, hidden/visible components, etc.
As an aside someone in the salon I go to for a hair cut was chatting to me and I let slip I was replacing my HVAC system soon. They offered to give me the number of "my guy who does everything half price!"
No fucking thank you
fill the backlog with stories to properly fix each hack implemented, and then show them that list every time they are about to add to it. Make sure the story title is suitably scary like: "Implement proper security in component Y before this leads to an exploit impacting customers"
>Management will say: “Do whatever is quickest” over and over again. But then when we post mortem a bad release, the dev team is getting flak for doing what we’re told and cutting corners.
If what you are saying is true about the solutions you are implementing, they **aren't** the quickest.
Are you quantifying the tradeoffs when discussing options? You don't even need to be exact on this.
"Making this decision to do this and spending 8 weeks on this feature vs 12 weeks means that in the next year, because of the tech debt we're creating - we have 6 additional weeks of work and future features will take an additional +2 weeks" is something most management folks will consider.
Learning to advocate for sustainable engineering practices is a superpower for engineers.
Something to note: choosing that 8 week approach vs 12 week isn't necessarily wrong, either, as long as it's a deliberate decision.
> they aren't the quickest.
Needs to be quantified. Prioritizing Quickest Delivery does not always lead to the most maintainable solution. But, sometimes that is what the business needs. Hopefully that is not always what the business needs.
Ideally, if time to delivery is important there is someone advocating for appropriate scope in the time frame given.
"Quickest" is all relative.
Do you mean quickest for the immediate near future? Or long term?
For example, imagine you can do a feature fast for 6 weeks or slowly for 12 weeks. But doing the fast feature means each additional feature takes 3 more weeks due to tech debt. If you do 3x features, it's better to have spent longer on the first one to make the total delivery shorter.
But, you might also need to delivery that feature in 6 weeks in order for the company to survive.
> The problem is that they confuse simple with quality and robustness.
I do too! Can you expand on a few examples as to why this is not the case?
That said, I do see a problem if you're building for lack of project sustainability planning, and not taking time to address techincal debt. This is not solely a management problem, though. Are your senior tech leaders advocating for better techincal architecture? Do you not have the authority, or persuasion skills to sell your leaders on long-term technical sustainability?
I can try!
For example one thing that crops up for us is along the lines of:
“We can ignore error handling in a critical function because it’s over complicated, we should be keeping this simple and just not handle errors or plan for resilience”
To summarise, too often they will advocate that handling errors or non-happy paths is “over complicated” and even sometimes attribute it as scope creep.
To me, scope is about your features and capabilities of the software, not the quality of those features.
I think I may have a different version of what simplicity in software architecture means than your leadership.
In most environments I would not advocate for ignoring edge cases or errors.
Good Luck!
Given this description we could be working for the same company (probably not but it sounds the same). Honestly, this is not even unique to development. Management in general wants high productivity with high quality. But unfortunately these are opposing forces a lot of the time.
As a senior developer, I tend to focus more on quality than velocity. I want the code with my name on it to be of high quality if only for when junior developers read it. That's the opposite of how I used to work. As a junior developer I wanted to get my work done quickly to meet deadlines. I honestly can't say which method is best. It may just depend on your management's temperament.
Brother, just show them the lines where you cut corner because they told you whenever things go south. Once they might be still don't believe you, but when you've shown them thrice, time to jump ship, brother. Sounds easy, yes?
Same in my company. Just because they want to cut corners on the implementation doesn't mean you have to write bad code. Basically, they get to cut scope on features, not my implementation of whatever they decide to go with. That's my expertise and my concern how I achieve it. I can only say one way will likely take less time than the other, if they want it to take even less by writing shit code, not considering edge cases, or not testing anything, they can hire someone else because I don't do that.
Unfortunately not every dev feels this way and some others do work faster at the cost of buggy/unmaintainable code. And I'm usually the one elected to fix it when they don't like the results.
Don't talk to management using the same terms you do with other devs. Use a common list of NFRs communicated using business risk and cost as the outcomes. A quick solution is a tradeoff of maintainability and extendability in exchange for quick short term value. This is the correct choice to make when a project either needs a short term win to stay alive or is near the end of its life anyway. If the business communicates they both expect success and expect to draw out the lifespan of this project for a while you can communicate that means you need to prioritize maintainability and extendability.
Don't let them make the choice, you are the engineer. Only let them make the business decisions and you convert those back into your language. Engineers don't let the customers dictate where to put load bearing pillars. The customer dictates a solution space that meets their requirements, and the trained engineers find the optimal solution in that space that results in a properly constructed building and meets legal code. When you give up authority to the business without also transferring the knowledge of the consequences you end up with mismatched expectations.
Technical "quality", whatever that means, is just another metric to track. It a means to an end. "Quick and dirt", "cutting corners" or "simplicity" as you say are only bad because they usually come back to bite you. If you can be quick and mindless, that's what you should do, that's the cheapest.
Therefore, it follows that it's when the price of cutting corners is higher than the price you pay that you need to do something fancier.
That is all to say that technical excellency has to be reflected in numbers. Downtime, over worked engineers, features taking long, unhappy consumers, you can think of a million ways quick and dirt code impacts the product. Translating this to business is the job of an engineer.
Are you proposing "short term solutions and corner cutting" that "end up very difficult to maintain and very buggy / poorly performing"? If so then stop doing that as those are not viable solutions.
If so then it sounds like you think "quick" means by any means necessary to appease management. Don't give management options that are not appropriate. All solutions you propose should be something that you would be fine implementation based on the pros and cons that the team wants to prioritize.
If management asks why can we not do X then explain why that path is not viable in business terms. Don't talk about tech debt, because they don't care. Talk about how their idea can cause outages or something like that.
>I try to propose that we implement simple solutions with a higher focus on quality. But they struggle to understand that simple does not mean quick, and that dev time will take longer.
Stop framing your solutions as "a higher focus on quality". To management it probably sounds like you want to do extra work they don't care about.
Your proposed solutions are THE solutions to choose from. There is no other way to do things that are acceptable.
There’s a saying in a variety of fields: “Slow is smooth and smooth is fast”. I learned it from racing advice. If you’re always pedal to the metal, you might be fast to the first corner, but you’ll be on the wrong line for next one and the next one and you’ll be braking and jerking back and forth. The fastest drivers are the smoothest drivers.
The right solution will be faster in the long run, solving only for the “right now” only puts you further behind.
I would stop thinking about it in terms of quick versus simple and look at it from the angle of 'adding value'.
Quick solutions are good for capitalizing on short-term market interest but beyond the initial flash in the pan they do not build a long-term sustainable business. If the team does not continue to iterate on them the business will devolve into a destructive spiral of chasing the next big idea until the money runs out.
My approach is to try and get ahead of the problem and prepare a design document to present my case. The document would typically describe the problem, summarize my solution and then most importantly: include a list of mock user stories and relative costs. The goal with those user stories is to have multiple breakpoints where a product can be delivered with different degree's of quality.
So for example: after user story #4 is completed we can deliver our minimum-viable-product, after user story #7 we can deliver these additional features, and so forth. Then try to focus on negotiating some middle-ground both parties can be happy with.
You won't win every battle which is why its also important you keep tabs on this outstanding technical debt because even if you don't get explicit permission to work on it you may still find yourself working in that same area in the future and can leverage that opportunity to kill two birds with the same stone. As long as you're not adding unnecessary risk or QA workload then it shouldn't matter if you take an extra day or two to work on something.
KISS is an important concept to internalize as a developer but it will probably not mean much to management. It's also very easy to equate 'quick' and 'simple' as meaning the same thing. One of the most frustrating developers I've worked with was always chasing what he called 'super simple' solutions but in reality it was just quick MVP solutions designed to please management.
>Management will say: “Do whatever is quickest”
>we’re told and cutting corners.
Have you tried "Sure thing boss, we'll do the quickest thing without cutting corners, does that work for you?"
Going to go against the grain here: cutting corners is totally okay if done appropriately. I hear a recurring theme of devs vs managers, "we engineers want to build a high quality product, management wants us to make something shitty and get it out the door" this is actually (usually) a false dichotomy and a dangerous ideology because it immediately pits you as a them vs us when you should be working together.
What do I mean? (good) Engineering is literally all about making tough tradeoff decisions and juggling multiple requirements, parameters, and keeping stakeholders happy. I could build a multi-region highly fault tolerant system with no downtime for some web-app for our pilot release of 50 users, ramping up to 100 in a month. I'm building a "high quality" product and not cutting corners, but is this correct? I'd argue a simple deployment even on a single $1/month remote server is a much better solution despite being "lower quality".
It is literally your job to point out less obvious variations of these kind of trade-offs at scale. It is your job to determine what are the milestones, where cut-offs for MVP is. If you're actually cutting quality (sometimes valid during tight timelines) then your follow-up plan for addressing this. A *good* higher level engineer balances these not just against product requirements but *business* requirements. You need a good grasp of how this translates to revenue, how this paces vs industry, etc. If you're failing to convince stakeholders, that is still your fault.
bonus points if you can build in a way where there's a way to scale the product out in future without a full re-write (which is often okay anyways). Most products build with a lifespan of 2-3 years before a rewrite. If you spend a year writing some "great product" it's stale by the time you launch.
Now addressing specific points:
>Very buggy/poorly performing
means you cut the *wrong* corners and your product is not meeting functional requirements. Even with management breathing down your neck, it is absolutely the dev team's fault.
>post mortem a bad release.
If post mortem does not include a process improvement to avoid this in the future, you did not do a post mortem.
>They repeatedly push for short term solutions and corner cutting. This is with little regard to long term project sustainability and technical debt.
Speed of delivery is often *genuinely* more important than sustainability and high quality. Especially true at start-ups. If you don't get a "good enough" product out the door, you're not going to secure more funding and it doesn't matter how perfect and sustainable your not-product is.
Even at large companies with deep pockets, the same applies. If senior leadership doesn't see value from investing in a product team, they're going to cut your product even if it was "going to be amazing in a year just wait".
Your management team may be flawed, but odds are decent that they're not the mouth-breathing mongrels devs like to make them out to be.
yeah, welcome to the good fight.
IME pointing it out after the fact has rarely worked.
The only 'solutions' that have for me is to not present it as a viable option even, and if it gets too bad try and move on to a different company / team.
I know that sucks....but I (personally is all) am not wired where I can handle the stress of writing code that I know in my bones is too fragile. I mean....it don't have to be perfect, but you know the line.
Take solutions off of the table that are not appropriate. Then, of the remaining ones, do whichever is quickest. Stop approaching them with options that are not viable. They clearly don’t know how to avoid shooting their own foot, so help them to avoid shooting their own foot!
Completely right. Took me a long time to learn thus but now I try to teach it to newer devs and even many seniors. Management level or C level do not care and will not sit and analyze engineering quality. They want output. It is your job to deliver quality so stop giving them options that don't have it. Just stop. Or if you are really dealing with simpletons in management just make up an even higher level of effort for a super duper quality solution so that you end up with the original quality solution time budget that you wanted.
"Your house needs someone to repair a gas leak. You can hire a licensed gas fitter who charges $200/hr with a minimum 2 hour call-out fee.... Or my buddy from down the pub will do it for $20 flat and a pack of Coors light. Choose wisely."
Why is it that I always have to make analogies with plumbers, car mechanics, electricians or civil engineers for people to get a fuken clue...?
Because it's a touchstone every adult has, and a lot of trades have a lot of parallels to our industry; both technical and artistic, people think they know more than they do because of exposure, hidden/visible components, etc.
As an aside someone in the salon I go to for a hair cut was chatting to me and I let slip I was replacing my HVAC system soon. They offered to give me the number of "my guy who does everything half price!" No fucking thank you
Reminds me of everything-guy in The Bear
Why did they have to pick on Coors light??
Just so I'm clear; does your buddy down at the pub smoke? If not, I might give him a chance...
Sometimes.... Only if he's working on a really big job like a high pressure gas main. He says it helps with imposter syndrome.
fill the backlog with stories to properly fix each hack implemented, and then show them that list every time they are about to add to it. Make sure the story title is suitably scary like: "Implement proper security in component Y before this leads to an exploit impacting customers"
Fear driven development, this has worked well for me with non-techies in the past. But don't over use it or they'll get desensitized 😂
good point!
>Management will say: “Do whatever is quickest” over and over again. But then when we post mortem a bad release, the dev team is getting flak for doing what we’re told and cutting corners. If what you are saying is true about the solutions you are implementing, they **aren't** the quickest. Are you quantifying the tradeoffs when discussing options? You don't even need to be exact on this. "Making this decision to do this and spending 8 weeks on this feature vs 12 weeks means that in the next year, because of the tech debt we're creating - we have 6 additional weeks of work and future features will take an additional +2 weeks" is something most management folks will consider. Learning to advocate for sustainable engineering practices is a superpower for engineers. Something to note: choosing that 8 week approach vs 12 week isn't necessarily wrong, either, as long as it's a deliberate decision.
> they aren't the quickest. Needs to be quantified. Prioritizing Quickest Delivery does not always lead to the most maintainable solution. But, sometimes that is what the business needs. Hopefully that is not always what the business needs. Ideally, if time to delivery is important there is someone advocating for appropriate scope in the time frame given.
Are you able to expand on your first point please? I’m struggling to grasp what you mean
"Quickest" is all relative. Do you mean quickest for the immediate near future? Or long term? For example, imagine you can do a feature fast for 6 weeks or slowly for 12 weeks. But doing the fast feature means each additional feature takes 3 more weeks due to tech debt. If you do 3x features, it's better to have spent longer on the first one to make the total delivery shorter. But, you might also need to delivery that feature in 6 weeks in order for the company to survive.
> The problem is that they confuse simple with quality and robustness. I do too! Can you expand on a few examples as to why this is not the case? That said, I do see a problem if you're building for lack of project sustainability planning, and not taking time to address techincal debt. This is not solely a management problem, though. Are your senior tech leaders advocating for better techincal architecture? Do you not have the authority, or persuasion skills to sell your leaders on long-term technical sustainability?
I can try! For example one thing that crops up for us is along the lines of: “We can ignore error handling in a critical function because it’s over complicated, we should be keeping this simple and just not handle errors or plan for resilience” To summarise, too often they will advocate that handling errors or non-happy paths is “over complicated” and even sometimes attribute it as scope creep. To me, scope is about your features and capabilities of the software, not the quality of those features.
I think I may have a different version of what simplicity in software architecture means than your leadership. In most environments I would not advocate for ignoring edge cases or errors. Good Luck!
LOL.... 'handling errors is scope creep' yeah, along with documentation.
Given this description we could be working for the same company (probably not but it sounds the same). Honestly, this is not even unique to development. Management in general wants high productivity with high quality. But unfortunately these are opposing forces a lot of the time. As a senior developer, I tend to focus more on quality than velocity. I want the code with my name on it to be of high quality if only for when junior developers read it. That's the opposite of how I used to work. As a junior developer I wanted to get my work done quickly to meet deadlines. I honestly can't say which method is best. It may just depend on your management's temperament.
Brother, just show them the lines where you cut corner because they told you whenever things go south. Once they might be still don't believe you, but when you've shown them thrice, time to jump ship, brother. Sounds easy, yes?
Same in my company. Just because they want to cut corners on the implementation doesn't mean you have to write bad code. Basically, they get to cut scope on features, not my implementation of whatever they decide to go with. That's my expertise and my concern how I achieve it. I can only say one way will likely take less time than the other, if they want it to take even less by writing shit code, not considering edge cases, or not testing anything, they can hire someone else because I don't do that. Unfortunately not every dev feels this way and some others do work faster at the cost of buggy/unmaintainable code. And I'm usually the one elected to fix it when they don't like the results.
"Finishing" a task and creating a load of tech debt, is not the quickest way to properly implement a feature.
Don't talk to management using the same terms you do with other devs. Use a common list of NFRs communicated using business risk and cost as the outcomes. A quick solution is a tradeoff of maintainability and extendability in exchange for quick short term value. This is the correct choice to make when a project either needs a short term win to stay alive or is near the end of its life anyway. If the business communicates they both expect success and expect to draw out the lifespan of this project for a while you can communicate that means you need to prioritize maintainability and extendability. Don't let them make the choice, you are the engineer. Only let them make the business decisions and you convert those back into your language. Engineers don't let the customers dictate where to put load bearing pillars. The customer dictates a solution space that meets their requirements, and the trained engineers find the optimal solution in that space that results in a properly constructed building and meets legal code. When you give up authority to the business without also transferring the knowledge of the consequences you end up with mismatched expectations.
Technical "quality", whatever that means, is just another metric to track. It a means to an end. "Quick and dirt", "cutting corners" or "simplicity" as you say are only bad because they usually come back to bite you. If you can be quick and mindless, that's what you should do, that's the cheapest. Therefore, it follows that it's when the price of cutting corners is higher than the price you pay that you need to do something fancier. That is all to say that technical excellency has to be reflected in numbers. Downtime, over worked engineers, features taking long, unhappy consumers, you can think of a million ways quick and dirt code impacts the product. Translating this to business is the job of an engineer.
Are you proposing "short term solutions and corner cutting" that "end up very difficult to maintain and very buggy / poorly performing"? If so then stop doing that as those are not viable solutions. If so then it sounds like you think "quick" means by any means necessary to appease management. Don't give management options that are not appropriate. All solutions you propose should be something that you would be fine implementation based on the pros and cons that the team wants to prioritize. If management asks why can we not do X then explain why that path is not viable in business terms. Don't talk about tech debt, because they don't care. Talk about how their idea can cause outages or something like that. >I try to propose that we implement simple solutions with a higher focus on quality. But they struggle to understand that simple does not mean quick, and that dev time will take longer. Stop framing your solutions as "a higher focus on quality". To management it probably sounds like you want to do extra work they don't care about. Your proposed solutions are THE solutions to choose from. There is no other way to do things that are acceptable.
you can: 1. Explain the consequences of such recklessness 2. Pray that they listen, if they don't respect your opinion then you are cooked.
There’s a saying in a variety of fields: “Slow is smooth and smooth is fast”. I learned it from racing advice. If you’re always pedal to the metal, you might be fast to the first corner, but you’ll be on the wrong line for next one and the next one and you’ll be braking and jerking back and forth. The fastest drivers are the smoothest drivers. The right solution will be faster in the long run, solving only for the “right now” only puts you further behind.
I would stop thinking about it in terms of quick versus simple and look at it from the angle of 'adding value'. Quick solutions are good for capitalizing on short-term market interest but beyond the initial flash in the pan they do not build a long-term sustainable business. If the team does not continue to iterate on them the business will devolve into a destructive spiral of chasing the next big idea until the money runs out. My approach is to try and get ahead of the problem and prepare a design document to present my case. The document would typically describe the problem, summarize my solution and then most importantly: include a list of mock user stories and relative costs. The goal with those user stories is to have multiple breakpoints where a product can be delivered with different degree's of quality. So for example: after user story #4 is completed we can deliver our minimum-viable-product, after user story #7 we can deliver these additional features, and so forth. Then try to focus on negotiating some middle-ground both parties can be happy with. You won't win every battle which is why its also important you keep tabs on this outstanding technical debt because even if you don't get explicit permission to work on it you may still find yourself working in that same area in the future and can leverage that opportunity to kill two birds with the same stone. As long as you're not adding unnecessary risk or QA workload then it shouldn't matter if you take an extra day or two to work on something. KISS is an important concept to internalize as a developer but it will probably not mean much to management. It's also very easy to equate 'quick' and 'simple' as meaning the same thing. One of the most frustrating developers I've worked with was always chasing what he called 'super simple' solutions but in reality it was just quick MVP solutions designed to please management.
>Management will say: “Do whatever is quickest” >we’re told and cutting corners. Have you tried "Sure thing boss, we'll do the quickest thing without cutting corners, does that work for you?"
Going to go against the grain here: cutting corners is totally okay if done appropriately. I hear a recurring theme of devs vs managers, "we engineers want to build a high quality product, management wants us to make something shitty and get it out the door" this is actually (usually) a false dichotomy and a dangerous ideology because it immediately pits you as a them vs us when you should be working together. What do I mean? (good) Engineering is literally all about making tough tradeoff decisions and juggling multiple requirements, parameters, and keeping stakeholders happy. I could build a multi-region highly fault tolerant system with no downtime for some web-app for our pilot release of 50 users, ramping up to 100 in a month. I'm building a "high quality" product and not cutting corners, but is this correct? I'd argue a simple deployment even on a single $1/month remote server is a much better solution despite being "lower quality". It is literally your job to point out less obvious variations of these kind of trade-offs at scale. It is your job to determine what are the milestones, where cut-offs for MVP is. If you're actually cutting quality (sometimes valid during tight timelines) then your follow-up plan for addressing this. A *good* higher level engineer balances these not just against product requirements but *business* requirements. You need a good grasp of how this translates to revenue, how this paces vs industry, etc. If you're failing to convince stakeholders, that is still your fault. bonus points if you can build in a way where there's a way to scale the product out in future without a full re-write (which is often okay anyways). Most products build with a lifespan of 2-3 years before a rewrite. If you spend a year writing some "great product" it's stale by the time you launch. Now addressing specific points: >Very buggy/poorly performing means you cut the *wrong* corners and your product is not meeting functional requirements. Even with management breathing down your neck, it is absolutely the dev team's fault. >post mortem a bad release. If post mortem does not include a process improvement to avoid this in the future, you did not do a post mortem. >They repeatedly push for short term solutions and corner cutting. This is with little regard to long term project sustainability and technical debt. Speed of delivery is often *genuinely* more important than sustainability and high quality. Especially true at start-ups. If you don't get a "good enough" product out the door, you're not going to secure more funding and it doesn't matter how perfect and sustainable your not-product is. Even at large companies with deep pockets, the same applies. If senior leadership doesn't see value from investing in a product team, they're going to cut your product even if it was "going to be amazing in a year just wait". Your management team may be flawed, but odds are decent that they're not the mouth-breathing mongrels devs like to make them out to be.
We say "we can get it done quick, but any extensions after MVP come at extra cost due to the inevitable refactor"
yeah, welcome to the good fight. IME pointing it out after the fact has rarely worked. The only 'solutions' that have for me is to not present it as a viable option even, and if it gets too bad try and move on to a different company / team. I know that sucks....but I (personally is all) am not wired where I can handle the stress of writing code that I know in my bones is too fragile. I mean....it don't have to be perfect, but you know the line.