Comment by parenthephobia | Hacker News Reader

Comment by parenthephobia | Hacker News Reader

Parent Full thread

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.

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.

> 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.

>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.

I think we might've misunderstood each other because I agree on all your points, plus I think I never constrasted deadlines with good results.

That's the keyword indeed -- good software. Not amazing.

What I kind of got from your previous comment was that if you resist being micromanaged, you're not a good professional. Apologies, it seems I misunderstood.

IMO a good professional has to also know to hold their ground here and there. Nobody respects a bottom-licker who bows down at every request, that's basic human nature and no formal processes can nullify us reacting animal-like in these situations sometimes. I find that when I argue with my superiors that I am given too unrealistic of a deadline and argument myself well, their respect for me actually grows and they start trusting me more and pester me less. One of them told me "I love it that you don't bullshit your way out of meetings where you have to make a tough sell" and I think that sums up my approach best.

TL;DR -- if both sides are willing to compromise to find the best value for the programmer's time and managers do NOT relentlessly insist you do things in the shortest time possible, then things go really well.

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.

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com