Comment by tempodox
2 years ago
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.
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.
> 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.
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.
3 replies →
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
3 replies →
> 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.
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.
> 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
“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/
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.
That is a great example. By not taking account of risk on the front end by embracing change, the system gets progressively more expensive to maintain (extended support contracts) and the risk of eventual inevitable change grows higher. Further, the system becomes progressively less valuable compared with newer systems.
1 reply →
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.
But you can’t have the technical foundation later because you’ve already built on something else.
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.
2 replies →