3 ms·
> *"We delivered the new version of the site after 7 weeks" I know everyone is focusing on 168MB, but ... The bigger issue that needs to be addressed for this
by tiffanyh 3y ago
> *"We delivered the new version of the site after 7 weeks"
I know everyone is focusing on 168MB, but ...
The bigger issue that needs to be addressed for this leader is - why did the previous project take 10-months, when that same team was able to deliver an entirely new rewrite version in just 7-weeks (without all the code bloat as well).
- zem 3y agoa large part of why it took 7 weeks was the work they had done over the last 10 months to gather requirements and translate them to code. the exact form of the code is merely the last stage in the process - i wager it would have taken them considerably longer than 7 weeks if they were starting the react site from scratch.
- Tteriffic 3y agoAbsolutely
- milesvp 3y agoyou are certainly correct. But there is a sentence that stood out to me, one where he said that devs needed to wait up to a minute to see their changes. I’ve personally felt the slog of writing code that takes easily 2 minutes to see changes, compile, flash unit, connect via bluetooth see if change shows what’s expected in some blackbox app. It’s maddening, and slows things way down, trying to keep the thought of what you were trying to do for that long is difficult and leads to lots of wasted tests. I largely suspect it’s an exponential function and the longer the feedback the exponentially longer the code takes to write. 1 minute is a long time, and I could see if you could get that loop under 10 seconds you could shave off months of dev time. Hell, I just recently changed a test timeout I was working with from 2 seconds to 1 second, and my morale improved in ways that surprised me even knowing all this.
- alfalfasprout 3y agoIn fairness, rewrites can be quite a bit faster than an earlier incarnation. By that point you've identified key gotchas, can simplify quite a few things, etc.
- asdff 3y agoIts not surprising honestly. There's a point in a codebase's life where it grows to this size that's hard to put all the moving parts into your head. Bloated, corrupted, every change takes careful caution to make sure it doesn't affect some other part downstream. You might know certain parts are not optimal or efficient, but you don't have the time to stop iterating on other tasks and fix these inefficiencies, let alone revise all the other built on parts that depend on this sub optimal component. A clean slate on the other hand is a lot easier. There's no vestigial pieces. No dependencies on hastily written functions you never got the time to rewrite the right way. You aren't locked into some version of a library from three years ago, you can use all the latest tooling.The shorter the codebase is in total, the easier it is to grasp the scope of how it all works together and move faster, knowing where other things should fit in a much simpler mental model.
- austhrow743 3y agoIt seems like a significant portion of that 10 months was spent refreshing the angular 2 repo hoping to see a change.
- TX81Z 3y agoThey literally picked the wrong tool for the job. The the tool they picked did not have the feature they needed. That is an utterly moronic decision.
- mst 3y agoWhy does -he- need to address the poor decisions of the person who was in charge before he joined?