4 ms·

Producing whatever god-forsaken clusterfuck is required to get the product out before the holiday rush only serves business goals in a very unlucky or very badl

Producing whatever god-forsaken clusterfuck is required to get the product out before the holiday rush only serves business goals in a very unlucky or very badly run business. A properly run business cares about selling products tomorrow but also cares about selling products next year. A properly run business therefore invests time in quality engineering so that the products they build now still work next year, or can be easily modified to fit whatever next year's requirements are. It's just good sense. Rushing out a horrible bodge job is only okay if you don't plan to be in business after the holiday rush, or at least not the same business. Otherwise, if you're doing the minimum viable work to keep the company ticking over from day to day, you'll usually find that the quickest way to do it today makes for more work tomorrow when you have to undo whatever horrible kludge made it work. There's a quote I like from Dave Thomas, one of the original codifiers of "Agile": When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier.

tootie 10y ago
If that cluster is profitable it serves business just fine. If you can prove poor system quality is costing money, explain that to management and they'll authorize spending resources on reactors.
- flukus 10y ago
  Sometimes it just appears profitable. It may be adding all kinds of costs that can't be tracked. If it's a public release then it may be doing long term harm to the companies reputation.
  - couchand 10y ago
    OMG this. Technical debt amounts to an externality put on engineering by management, and it's all too easy for most to ignore the complaints of engineers. The solution is not (as others have proposed in comments here) to "just do the work" as that serves to bury ever deeper the cost being imposed on the future of the organization.
- dosethree 10y ago
  The cost of technical debt is obviously much harder to quantify than the value of new features (though most companies don't even do that well), so most people don't try and that's why we end up constantly prioritizing features over paying down technical debt. However, tasks that improve engineer productivity, like speeding up the test suite, or adding automated tests, removing unneeded code, a badly needed refactor on a critical piece of code can not only makes new features quicker to develop, but also makes the technical improvements quicker to develop. Features have the opposite effect.
cookiecaper 10y ago
I think the use of "god-forsaken clusterfuck" was hyperbole, but frankly, if you're working on software that's necessary to enable the holiday rush, doing whatever you have to do to get it out on time and then redoing the whole thing over the next 4-6 months is probably still the cost-effective solution. Engineering exists in corporate contexts to serve the purposes of the organization. If you believe that the entire focus of any engineering project should be crafting theoretically-robust software, you're either going to have retire early and pick it up as a personal hobby or go into academia.
- pdimitar 10y ago
  > you're either going to have retire early and pick it up as a personal hobby or go into academia. That's a strawman crafted by introducing a false extreme dichotomy. I don't think anyone claims they want to produce "theoretically-robust software". 99% of all programmers I've ever met and spoke with in real (or virtually), agree there's no such thing. What's discussed here (which admittedly is off on a tangent derived from the OP) is questioning the value of rushed software. There's a balance to be struck there and bending over to the managers and always trying to squeeze more in less time is always ending up in flames. I still don't get it why so many people, probably you included, have trouble understanding this very simple (and well documented in the recent history) truth.
  - cookiecaper 10y ago
    >I still don't get it why so many people, probably you included, have trouble understanding this very simple (and well documented in the recent history) truth. I think the problem is you're conflating a recognition that software needs to get done and shipped with the surrender of good craft. Good craft _necessarily includes_ a recognition that your purpose of an employee is not to write beautiful software, and then to move on to make something good within reasonable time constraints anyway. Not perfect, not without warts or things to improve, but good. When your chain of command knows you understand your job is to serve the company and not to indulge in impractical engineering excesses, they'll trust you much more and be more willing to give you the freedom you need to do something well. Balking any time they ask for a timeline is not the way to establish this.
nradov 10y ago
None of that matters if you're bankrupt because your competitor shipped first (or promised to ship first) and captured the market. In the real world businesses often get boxed into making short-term decisions that hurt their long-term prospects due to lack of time and capital.
- pkolaczk 10y ago
  Not so fast. The first mover advantage is often severely overestimated. There are many examples of companies which failed despite being the first to deliver. Apple was not the first company to invent a smartphone. Facebook was not the first company to create a social-network portal. Google was not the first company to create a search engine. A competitor shipping crap first is not a big threat, unless you compete in making crap.
  - akamaka 10y ago
    Friendster and MySpace are both great examples of this. Both were the number one social media network at some point, and both were heavily burdened (if not killed) by technical debt. In the case of Friendster, the poor scalability engineering often made the site nearly unusable, and at MySpace, an enormous engineering team struggled to release new features while Facebook rapidly launched innovation after innovation.

tootie 10y ago

If that cluster is profitable it serves business just fine. If you can prove poor system quality is costing money, explain that to management and they'll authorize spending resources on reactors.

flukus 10y ago
Sometimes it just appears profitable. It may be adding all kinds of costs that can't be tracked. If it's a public release then it may be doing long term harm to the companies reputation.
- couchand 10y ago
  OMG this. Technical debt amounts to an externality put on engineering by management, and it's all too easy for most to ignore the complaints of engineers. The solution is not (as others have proposed in comments here) to "just do the work" as that serves to bury ever deeper the cost being imposed on the future of the organization.
dosethree 10y ago
The cost of technical debt is obviously much harder to quantify than the value of new features (though most companies don't even do that well), so most people don't try and that's why we end up constantly prioritizing features over paying down technical debt. However, tasks that improve engineer productivity, like speeding up the test suite, or adding automated tests, removing unneeded code, a badly needed refactor on a critical piece of code can not only makes new features quicker to develop, but also makes the technical improvements quicker to develop. Features have the opposite effect.

cookiecaper 10y ago

I think the use of "god-forsaken clusterfuck" was hyperbole, but frankly, if you're working on software that's necessary to enable the holiday rush, doing whatever you have to do to get it out on time and then redoing the whole thing over the next 4-6 months is probably still the cost-effective solution. Engineering exists in corporate contexts to serve the purposes of the organization. If you believe that the entire focus of any engineering project should be crafting theoretically-robust software, you're either going to have retire early and pick it up as a personal hobby or go into academia.

pdimitar 10y ago
> you're either going to have retire early and pick it up as a personal hobby or go into academia. That's a strawman crafted by introducing a false extreme dichotomy. I don't think anyone claims they want to produce "theoretically-robust software". 99% of all programmers I've ever met and spoke with in real (or virtually), agree there's no such thing. What's discussed here (which admittedly is off on a tangent derived from the OP) is questioning the value of rushed software. There's a balance to be struck there and bending over to the managers and always trying to squeeze more in less time is always ending up in flames. I still don't get it why so many people, probably you included, have trouble understanding this very simple (and well documented in the recent history) truth.
- cookiecaper 10y ago
  >I still don't get it why so many people, probably you included, have trouble understanding this very simple (and well documented in the recent history) truth. I think the problem is you're conflating a recognition that software needs to get done and shipped with the surrender of good craft. Good craft _necessarily includes_ a recognition that your purpose of an employee is not to write beautiful software, and then to move on to make something good within reasonable time constraints anyway. Not perfect, not without warts or things to improve, but good. When your chain of command knows you understand your job is to serve the company and not to indulge in impractical engineering excesses, they'll trust you much more and be more willing to give you the freedom you need to do something well. Balking any time they ask for a timeline is not the way to establish this.

nradov 10y ago

None of that matters if you're bankrupt because your competitor shipped first (or promised to ship first) and captured the market. In the real world businesses often get boxed into making short-term decisions that hurt their long-term prospects due to lack of time and capital.

pkolaczk 10y ago
Not so fast. The first mover advantage is often severely overestimated. There are many examples of companies which failed despite being the first to deliver. Apple was not the first company to invent a smartphone. Facebook was not the first company to create a social-network portal. Google was not the first company to create a search engine. A competitor shipping crap first is not a big threat, unless you compete in making crap.
- akamaka 10y ago
  Friendster and MySpace are both great examples of this. Both were the number one social media network at some point, and both were heavily burdened (if not killed) by technical debt. In the case of Friendster, the poor scalability engineering often made the site nearly unusable, and at MySpace, an enormous engineering team struggled to release new features while Facebook rapidly launched innovation after innovation.