Hacker News Reader

Comment by AbrahamParangi | Hacker News Reader

No offense intended to the author, but it sounds like they've mistaken the purpose of their job. For most engineers, their job is not to produce exceptionally wonderful engineering.

It is to produce whatever god-forsaken clusterfuck is required to get the product out before the holiday rush. Or more generally to do whatever the business needs to do in order to keep making enough money to continue existing.

If engineering doesn't directly serve business goals, maybe that business doesn't really need that engineering department.

View on HN

> If engineering doesn't directly serve business goals, maybe that business doesn't really need that engineering department.

This is the hardest lesson to learn for fresh young engineers. Their job isn't to create wonderful new designs, it's to serve the needs of their company - which may involve creating wonderful new designs, if they're lucky, but it may not.

It's not a «job» churning bad code, it's you churning bad code. If you are good engineer, your code is good.

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.

It turns out that technical bebt will become a business liability at some stage of its evolution.

There are multiple historical examples to draw from.

I think the better case here is where business and engineering can talk in meaningful terms about the difference between technical debt and longer-term simplicity and productivity of a system.

> It is to produce whatever god-forsaken clusterfuck is required to get the product out before the holiday rush. Or more generally to do whatever the business needs to do in order to keep making enough money to continue existing. If engineering doesn't directly serve business goals, maybe that business doesn't really need that engineering department.

Painfully true

It's really sad if you don't strive to excel at your craft. Though I understand that most of the craftsmen don't care about their work, they care about bringing home a good living.

There's a huge difference between excelling at your craft and caring about your work.

As a software developer for a commercial organisation, the work is to make profitable software. Profitable does not mean the same thing as elegant.

There is a huge amount of skill involved in creating profitable software, because it involves a huge number of judgement calls about what matters, and what will produce the most bang for the least buck.

Creating beautiful, elegant, software is easy when there are no time constraints. Beautiful, elegant software is wonderful stuff when it's part of a non-commercial open-source project that we all use and depend on.

That's not the stuff most of us write. We write code that's part of a product that a limited range of customers will run, paid for by a limited budget. We very much need to be good at our work, which may well involve writing shitty code quickly if that's the most profitable thing to do.

Caring about our work is not the same thing as writing elegant code.

Some domains don't need maintainable code. If you're near the end of the development cycle for a video game, and you need to ship before some date, it doesn't matter if what you write is a cluster fuck. Most of the code is gonna get thrown out anyway, what matters is that the game is in the stores on time...

It may not be the posters desire to excel...just the reality of what's possible in their current job.

I suppose their are job choices you can make the open up more possibilities, but that brings other factors into play, not all of which are easy choices (salary, where to live, career stability, etc).

> just the reality of what's possible in their current job.

Reality is maleable, albeit it's not an easy thing to do, that's a fact.

The real question is if you are willing to change your reality -- or are you a coffee-addicted slouch who is always too tired to try and change anything and just wants to go home for a proper sleep after yet another soul-draining workday.

Apologies for being a bit extreme. IMO it helps illustrate my point a little better. No offense is meant to you or anyone else reading this.

No offense taken. I've been where that poster has been though. "If you are willing to change your reality" isn't always as easy as it sounds. I could have easily escaped, for example, if I moved away to a different city. But, I didn't want to uproot my children.

I did eventually escape, but there really wasn't a safe way to do so quickly.

Reply on news.ycombinator.com