4 ms·

In my opinion, the only true solution is to slow down “velocity” in development teams. If the developers are to be held responsible for producing good, secure c

In my opinion, the only true solution is to slow down “velocity” in development teams. If the developers are to be held responsible for producing good, secure code, Only the developers can decide when a feature is ready, not the business. If the business wants to dictate deadlines, the business is responsible for security. Edit: I should say development team to include qa, but we don’t have those anymore at most places.

albertopv 2y ago
> Only the developers can decide when a feature is ready It's the business that pays the wages. Also, time to market is most important (for everyone but Apple), coming later with a better product often doesn't mean a viable business. Problem is almost nobody is promoted for maintaining or improving an existing product, no C-level is interested in tech debt management/reduction, anywhere.
- freilanzer 2y ago
  > It's the business that pays the wages. It's the developers who do the work.
  - Lutger 2y ago
    Everybody does the work. For an enterprise, its administration or HR who actually pay the wages. The business certainly doesn't, they think up the model and the features, the business problems. I find this whole thing very confusing, there are no factions actually and everybody contributes, and has more or less the same outcomes as their ultimate interest. Maybe not the shareholders. Those truly don't do any work at all, but extract value out of the work done by those who are paid a wage. They only bring in capital. The real reason developers should be able to mandate when something is 'good enough' is because it is their expertise, just as 'the business' decides what features should be build (those that solve a business problem). Just like a medical doctor decides on the treatment and not the manager of the hospital. While pumping out features or 'solving business problems' brings in the money, security risks can, at its worst, instantly terminate the whole business. But developers don't want the company to go bankrupt because they spend a year eliminating every risk. Similarly product people won't like their company to die because they squeezed out an extra hour or two out of the sprint by avoiding any security work. A serious enterprise is, or should be, concerned with risks as well as 'velocity'.
rco8786 2y ago
TBH, I think this way of thinking is part of the problem. It's not "developers vs the business". Developers are part of the business.
- ASalazarMX 2y ago
  Developers vs marketers? Vs product managers? Vs CEOs? They might be part of the business, but they usually have little authority regarding business decisions. Most developers are just told what the business wants.
  - rco8786 2y ago
    > they usually have little authority regarding business decisions. Sorry I didn't fully explain my thought. I agree with this. I don't think it's just developers that have a "developers vs business" mindset. The C-suite does also. In most companies, they look at the engineering org as a tool to be used and not as a partner in the business. The result being negligent behavior toward things like security.
mhitza 2y ago
Velocity slows down already with time on all projects (I have yet to see a project where this is not true). Managers and higher ups might like to pretend this phenomenon doesn't exist, and could pressure the teams to deliver "something" earlier because of their naturally slowed down velocity, which result in prod issues. I've also been on the other end, where developers felt self inflicted pressure to deliver, because they saw how much they've slowed down.

albertopv 2y ago

> Only the developers can decide when a feature is ready It's the business that pays the wages. Also, time to market is most important (for everyone but Apple), coming later with a better product often doesn't mean a viable business. Problem is almost nobody is promoted for maintaining or improving an existing product, no C-level is interested in tech debt management/reduction, anywhere.

freilanzer 2y ago
> It's the business that pays the wages. It's the developers who do the work.
- Lutger 2y ago
  Everybody does the work. For an enterprise, its administration or HR who actually pay the wages. The business certainly doesn't, they think up the model and the features, the business problems. I find this whole thing very confusing, there are no factions actually and everybody contributes, and has more or less the same outcomes as their ultimate interest. Maybe not the shareholders. Those truly don't do any work at all, but extract value out of the work done by those who are paid a wage. They only bring in capital. The real reason developers should be able to mandate when something is 'good enough' is because it is their expertise, just as 'the business' decides what features should be build (those that solve a business problem). Just like a medical doctor decides on the treatment and not the manager of the hospital. While pumping out features or 'solving business problems' brings in the money, security risks can, at its worst, instantly terminate the whole business. But developers don't want the company to go bankrupt because they spend a year eliminating every risk. Similarly product people won't like their company to die because they squeezed out an extra hour or two out of the sprint by avoiding any security work. A serious enterprise is, or should be, concerned with risks as well as 'velocity'.

rco8786 2y ago

TBH, I think this way of thinking is part of the problem. It's not "developers vs the business". Developers are part of the business.

ASalazarMX 2y ago
Developers vs marketers? Vs product managers? Vs CEOs? They might be part of the business, but they usually have little authority regarding business decisions. Most developers are just told what the business wants.
- rco8786 2y ago
  > they usually have little authority regarding business decisions. Sorry I didn't fully explain my thought. I agree with this. I don't think it's just developers that have a "developers vs business" mindset. The C-suite does also. In most companies, they look at the engineering org as a tool to be used and not as a partner in the business. The result being negligent behavior toward things like security.

mhitza 2y ago

Velocity slows down already with time on all projects (I have yet to see a project where this is not true). Managers and higher ups might like to pretend this phenomenon doesn't exist, and could pressure the teams to deliver "something" earlier because of their naturally slowed down velocity, which result in prod issues. I've also been on the other end, where developers felt self inflicted pressure to deliver, because they saw how much they've slowed down.