4 ms·

The saddest thing is that some bosses want throwaway code. I had a short stint once in a company where the owner wanted the web service rewritten from scratch

The saddest thing is that some bosses want throwaway code. I had a short stint once in a company where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion. He would hire a 5000 LoC per week hero on the spot.

andai 3y ago
Tangential but I was doing a web app for a client and gave a time estimate, which accounted for doing things properly (i.e. learning a frontend framework first). He asked "can you do it faster" and I agreed, thinking I'll make a throwaway version first and fix it later. Needless to say the project was a disaster, rapidly became unmaintainable. That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy.
- deleted 3y ago
  [deleted]
- nine_zeros 3y ago
  > That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy. And I learned that doing it my way will get me fired because the manager has asked to do faster. The way I have learned to get around this is by making the manager publicly document the request to go faster. If they don't document, I don't see or act on it. Once they document it, I happily go faster and let it all crash and burn. Then when they inevitably try to blame me, I point at the public documentation of the request to go faster and let the blame fall on the person responsible.
  - jareklupinski 3y ago
    that's great for covering your a, but the project will still fail and no one will get value / praise for all that time spent if time is the only actual concern for the project's success, a good approach is to explicitly re-scope the feature list and start asking managers things like: "do we really need feature X to release? can feature Y wait until after beta? did the request for feature Z come from a user or a stakeholder?" document all that too of course ;) but then at least there is a chance for safety _and_ success
    - nine_zeros 3y ago
      > that's great for covering your a, but the project will still fail and no one will get value / praise for all that time spent Yes the project will fail. But if my manager only cares about speed, why should I care about anything more? Why should an engineer be responsible for a manager's poor decisions?
      - CapstanRoller 3y ago
        >Why should an engineer be responsible for a manager's poor decisions? Because the corporate hierarchy demands it. Front-line workers are expendable, much like front-line soldiers. Corporations are not democracies, and neither are militaries. If your job is to write and commit code, you are the corporate equivalent of infantry. In short: a grunt.
        nine_zeros 3y ago
        > your job is to write and commit code, you are the corporate equivalent of infantry. In short: a grunt. And if I am being treated as a grunt, I will act like a grunt aka I don't care more than my bosses. I will even abandon ship at the sign of incompetence and point out the incompetence to others.
  - jonathanlydall 3y ago
    This sounds like possible malicious compliance. Regardless, it’s an important life skill to learn that it’s generally not enough to ask people to do what you want, you need them to actually “buy in” to what you want, and then they’ll actually care enough to at least try make it happen. This applies to managers and their employees, or also when trying to get on the ground employees to adopt a product initially sold to their manager/execs.
    - nine_zeros 3y ago
      "Buy in" is what you use for people acting in good faith. But managers aren't acting in good faith. They just want it done so that they look good to their own bosses. They don't actually care about the product/service. Their ask to "go faster" is a bad faith argument where there is no real need to go faster except for the manager to look good. I don't feel the need to get "buy in" for bad faith managers.
      - cjaybo 3y ago
        > but managers aren’t acting in good faith An overly broad statement which, my experience, is not true. Managers come in many shapes. Although, I suppose ironically, if you act in bad faith as a response to this perception, then I think that perception will quickly become true.
        gremlinunderway 3y ago
        Why is asking for requests to be in writing an "act of bad faith"? Literally cna't see a single outcome that would be an act of bad faith here. If the project fails, and the manager tries to blame it on you, they are de facto acting out of bad faith given the request. Documenting it just identifies this. If the project succeeds or fails, but no one blames you, then the documented request is just there for the record.
ebiester 3y ago
It depends on “when” along the timeline of the project. If we don’t know if anyone will want the product, the quality of the product is less valuable than validation of product market fit. Later, I care much more about avoiding accidental complexity and having a great technical foundation.
- tilne 3y ago
  But you can’t have the technical foundation later because you’ve already built on something else.
  - jen20 3y ago
    Sure you can - you just have to be willing to throw what you have away. If the outcome of that is having to rewrite one of five experiments because it is a hit, that is a _great success_, not a failure.
    - tempodox 3y ago
      But only in theory. In practice you would never get the time to rewrite what “already works”. And objectively, even with the best intentions, every rewrite comes with its own kinds of risks.
      - jen20 3y ago
        Perhaps not at the kind of shop that deserves to go out of business. I do this literally every day from function snippets to entire systems.
adolph 3y ago
> where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion This sounds like an improvement over the opposite, a code base that is rarely touched and uses eol frameworks. Software is a living thing and if you don’t act as a ruthless gardener you wind up a museum curator with 1990s DEC hardware running in the 2010’s. The right balance of staying current and not reinventing the wheel is not trivial.
- hnfong 3y ago
  If you choose the right frameworks which have sufficient momentum to last you say 10 years, you don't have to put yourself in the dilemma. And yes, 10 years is quite possible these days. Besides the infamous Javascript framework churn, things are moving quite a bit slower in recent years.
  - kagevf 3y ago
    > Besides the infamous Javascript framework churn reactjs came out in 2013, so it meets the 10y metric, but it has some internal churn, such as classes, hooks, etc
  - adolph 3y ago
    “If you choose the right frameworks” is a big if. Even within a framework, there is versioning and dependency management to account for. Consider the log4j vulnerability. The cost and risk of patching something untouched for 10 years is higher than something touched more recently. In part, this is due to the risks inherent to change have been spread out over 10 years instead of backloaded to the end. Practicing mitigating risks by proactively taking them has value of its own. The parable of ergodic cakes shows this.[0] What % of cakes will fail if 10 people each bake one, versus one person baking 10 over time? https://luca-dellanna.com/what-is-ergodicity/ https://luca-dellanna.com/what-is-ergodicity/
- bitwize 3y ago
  Hey, if the 1990s DEC hardware still works, and it'd be more expensive to change it... There are PDP-11s running nuclear plants today with support contracts to keep them running until 2050. PDP-11s.

andai 3y ago

Tangential but I was doing a web app for a client and gave a time estimate, which accounted for doing things properly (i.e. learning a frontend framework first). He asked "can you do it faster" and I agreed, thinking I'll make a throwaway version first and fix it later. Needless to say the project was a disaster, rapidly became unmaintainable. That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy.

deleted 3y ago
[deleted]
nine_zeros 3y ago
> That's how I learned my job isn't to do what the client asks, it's to make sure their project succeeds even if it means making them (temporarily) unhappy. And I learned that doing it my way will get me fired because the manager has asked to do faster. The way I have learned to get around this is by making the manager publicly document the request to go faster. If they don't document, I don't see or act on it. Once they document it, I happily go faster and let it all crash and burn. Then when they inevitably try to blame me, I point at the public documentation of the request to go faster and let the blame fall on the person responsible.
- jareklupinski 3y ago
  that's great for covering your a, but the project will still fail and no one will get value / praise for all that time spent if time is the only actual concern for the project's success, a good approach is to explicitly re-scope the feature list and start asking managers things like: "do we really need feature X to release? can feature Y wait until after beta? did the request for feature Z come from a user or a stakeholder?" document all that too of course ;) but then at least there is a chance for safety _and_ success
  - nine_zeros 3y ago
    > that's great for covering your a, but the project will still fail and no one will get value / praise for all that time spent Yes the project will fail. But if my manager only cares about speed, why should I care about anything more? Why should an engineer be responsible for a manager's poor decisions?
    - CapstanRoller 3y ago
      >Why should an engineer be responsible for a manager's poor decisions? Because the corporate hierarchy demands it. Front-line workers are expendable, much like front-line soldiers. Corporations are not democracies, and neither are militaries. If your job is to write and commit code, you are the corporate equivalent of infantry. In short: a grunt.
      - nine_zeros 3y ago
        > your job is to write and commit code, you are the corporate equivalent of infantry. In short: a grunt. And if I am being treated as a grunt, I will act like a grunt aka I don't care more than my bosses. I will even abandon ship at the sign of incompetence and point out the incompetence to others.
- jonathanlydall 3y ago
  This sounds like possible malicious compliance. Regardless, it’s an important life skill to learn that it’s generally not enough to ask people to do what you want, you need them to actually “buy in” to what you want, and then they’ll actually care enough to at least try make it happen. This applies to managers and their employees, or also when trying to get on the ground employees to adopt a product initially sold to their manager/execs.
  - nine_zeros 3y ago
    "Buy in" is what you use for people acting in good faith. But managers aren't acting in good faith. They just want it done so that they look good to their own bosses. They don't actually care about the product/service. Their ask to "go faster" is a bad faith argument where there is no real need to go faster except for the manager to look good. I don't feel the need to get "buy in" for bad faith managers.
    - cjaybo 3y ago
      > but managers aren’t acting in good faith An overly broad statement which, my experience, is not true. Managers come in many shapes. Although, I suppose ironically, if you act in bad faith as a response to this perception, then I think that perception will quickly become true.
      - gremlinunderway 3y ago
        Why is asking for requests to be in writing an "act of bad faith"? Literally cna't see a single outcome that would be an act of bad faith here. If the project fails, and the manager tries to blame it on you, they are de facto acting out of bad faith given the request. Documenting it just identifies this. If the project succeeds or fails, but no one blames you, then the documented request is just there for the record.

ebiester 3y ago

It depends on “when” along the timeline of the project. If we don’t know if anyone will want the product, the quality of the product is less valuable than validation of product market fit. Later, I care much more about avoiding accidental complexity and having a great technical foundation.

tilne 3y ago
But you can’t have the technical foundation later because you’ve already built on something else.
- jen20 3y ago
  Sure you can - you just have to be willing to throw what you have away. If the outcome of that is having to rewrite one of five experiments because it is a hit, that is a _great success_, not a failure.
  - tempodox 3y ago
    But only in theory. In practice you would never get the time to rewrite what “already works”. And objectively, even with the best intentions, every rewrite comes with its own kinds of risks.
    - jen20 3y ago
      Perhaps not at the kind of shop that deserves to go out of business. I do this literally every day from function snippets to entire systems.

adolph 3y ago

> where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion This sounds like an improvement over the opposite, a code base that is rarely touched and uses eol frameworks. Software is a living thing and if you don’t act as a ruthless gardener you wind up a museum curator with 1990s DEC hardware running in the 2010’s. The right balance of staying current and not reinventing the wheel is not trivial.

hnfong 3y ago
If you choose the right frameworks which have sufficient momentum to last you say 10 years, you don't have to put yourself in the dilemma. And yes, 10 years is quite possible these days. Besides the infamous Javascript framework churn, things are moving quite a bit slower in recent years.
- kagevf 3y ago
  > Besides the infamous Javascript framework churn reactjs came out in 2013, so it meets the 10y metric, but it has some internal churn, such as classes, hooks, etc
- adolph 3y ago
  “If you choose the right frameworks” is a big if. Even within a framework, there is versioning and dependency management to account for. Consider the log4j vulnerability. The cost and risk of patching something untouched for 10 years is higher than something touched more recently. In part, this is due to the risks inherent to change have been spread out over 10 years instead of backloaded to the end. Practicing mitigating risks by proactively taking them has value of its own. The parable of ergodic cakes shows this.[0] What % of cakes will fail if 10 people each bake one, versus one person baking 10 over time? https://luca-dellanna.com/what-is-ergodicity/ https://luca-dellanna.com/what-is-ergodicity/
bitwize 3y ago
Hey, if the 1990s DEC hardware still works, and it'd be more expensive to change it... There are PDP-11s running nuclear plants today with support contracts to keep them running until 2050. PDP-11s.