[HN Gopher] Throwing away 10 months of work after 2 months on th...
___________________________________________________________________
Throwing away 10 months of work after 2 months on the job
Author : promiseofbeans
Score : 121 points
Date : 2023-08-17 20:48 UTC (1 days ago)
(HTM) web link (www.dancowell.com)
(TXT) w3m dump (www.dancowell.com)
| translucyd wrote:
| As a mid-seniority developer, I'm just now starting to grasp the
| harsh reality of a full refactor. We always think we can improve
| the speed and code of a website but, man, that's really though.
|
| I always remember the "let's throw away Windows ME codebase for
| NT" scenario. Sometimes giving up is better I suppose.
| mariusmg wrote:
| >"let's throw away Windows ME codebase for NT"
|
| Well the Windows 9x codebase was always mean to be ,
| eventually, thrown away. It existed only to be able to run the
| OS on very low hardware (eg Win95 run even on 4 MB of RAM).
| willsmith72 wrote:
| This is why we have the strangler pattern, it's not just for
| backend apps. Start small, tackle the biggest risks first,
| deliver incremental value.
| ericmcer wrote:
| I have been part of 2-3 strangler refactors... I don't think
| we ever reached the turn off the old app part.
| tnorthcutt wrote:
| Did you end up with a net improvement, though?
| willsmith72 wrote:
| Me too, but I don't see that as a failure. Sometimes it's a
| case of 80/20, and refactoring that 20% might just never be
| worth the effort.
| kjkjadksj wrote:
| Certain websites are so overbuilt though that theres plenty of
| low hanging fruit. I'd say a very healthy majority of the
| websites I visit could replace whatever bulky mess they have
| with static html and still serve me their content and ads. Then
| the website would probably be orders of magnitude more
| performant refactored in html.
| specproc wrote:
| Reading this sort of stuff makes me reevaluate my life choices.
| e28eta wrote:
| I don't have much experience with frontend frameworks /
| libraries, but I really dislike the way this article presents
| React as the silver bullet.
|
| Maybe it is factually accurate that Angular was the wrong choice
| for e-commerce (at the time?). I don't know. Without SSR, was
| there really nothing feasible they could do to reduce the page
| load time? Did Angular make tradeoffs that are better for a
| large, interactive web application; and you want a different set
| of tradeoffs for ecomm use cases? Or were they just stuck with
| the wrong tech at the wrong time: complicated enough that it's
| too slow in Angular, and the project hadn't caught up to them
| yet?
|
| That JS bundle was doing _something_ (probably lots of
| somethings). How many features did the React rewrite drop? Could
| you have removed those features from the old codebase, or would
| that have been politically infeasible at the company? ("no, don't
| delete that" vs "yeah, we can live without that, you don't need
| to implement it" -> author gets to add a Loss Aversion sidebar).
| Are there still items in the backlog to re-implement missing
| features (that the team intends to complete)?
|
| Development effort compared between stop-the-world rewrites (in
| order to hit their 7 week "really big shopping event") vs rewrite
| following ongoing feature development and the painful merges
| mentioned in the article. Obviously business appetite changed for
| a stop-the-world rewrite, but could that have been identified
| earlier?
|
| Changing requirements: did the Angular upgrade start with "we
| need SSR" as a top requirement? It seems more likely that there
| were a bunch of benefits / requirements for a technology upgrade,
| and over the previous 10 months they'd discovered SSR as a
| blocker. Erasing the other improvements makes the 10 months vs 7
| weeks sound very impressive, but seems disingenuous.
|
| Maybe my expectations are off for a blog post format.
| lemper wrote:
| 168 mb of bundled js? they must've written a fully functioning
| unix-like kernel too, yeah? or embedded Taylor Swift's 7th album.
| otherwise, I don't know how the number is as high as that.
| Raed667 wrote:
| I imagine it is not pure js code but a lot of embedded svgs and
| inlined assets and styles.
| ransackdev wrote:
| Apparently you've never had to shed file size from a multiple
| megabyte react bundle shat out by webpacker
| andrewmcwatters wrote:
| I wonder how many of the top npm downloaded modules you could
| fit into an amalgam vendor minified build before you hit 168
| MB.
| baz00 wrote:
| All malware infested varieties of is-true for certain!
| [deleted]
| translucyd wrote:
| LoL
| indy wrote:
| Surprising that at the point when it crossed 100mb there was
| no-one on the team who raised any concerns. Perhaps this was a
| case of boiling the frog?
| warp wrote:
| What I understood from the post was that it was only 168mb
| because tree-shaking didn't work on whatever version had
| support for server-side rendering. With working tree-shaking
| the bundle these developers were working with during
| development would be considerably smaller.
| pault wrote:
| Probably bundling the server side dependencies into the
| client. I've also seen this happen when people add
| uncompressed 4k png images and the build tool is configured
| to inline all static assets. Obviously there was a lack of
| domain knowledge in the company or this wouldn't have
| happened.
| afavour wrote:
| Wouldn't be at all surprised if no one was paying attention.
| Chrome on a top spec MacBook can chew through 100MB of JS
| without thinking about it. Someone on an old machine is
| screwed but hey, "works on my machine"...
| [deleted]
| Cthulhu_ wrote:
| If it's not like... large language bundles or images or
| whatnot, I suspect it might be a lack of technical oversight
| and everyone just adding their favorite library.
| baz00 wrote:
| This stinks of no-one-knows-what-the-fuck-they-are-doing-itis,
| a common problem in the software engineering community. When
| mixed with a deadly dose of sunk-cost-fallacy-itis and project-
| death-march-itis, the only way out is adding more JavaScript
| until it creates a singularity from the accumulated mas and
| sucks the project into oblivion.
|
| Trying to fight one of these off now. We don't need a fancy
| shit ass UI. We just need stuff that works and is simple. But
| plenty of one-trick pony developers and architects who build
| complicated mechanisms out of piles of nodejs and microservices
| which merely consume time, energy and attention and delivery
| sweet fuck all ROI.
| peteradio wrote:
| > no-one-knows-what-the-fuck-they-are-doing-itis
|
| This is so funny. I feel like in the old days it would be
| called out without remorse, like an old hand putting down a
| maimed horse. Nowadays you have to tapdance around the issue
| to such a degree that you look insane to try, people will
| just spout jargon longer than a ducks dick and your manager
| will sucker down.
| baz00 wrote:
| I've long given up on tact and politics. You say what it
| is. If someone doesn't like that, move the fuck on.
| mistrial9 wrote:
| be sure to mock people with +20 years software design and
| development experience, too...
| baz00 wrote:
| Some of the people I am mocking do have that.
|
| Also I mock myself regularly :)
| weaksauce wrote:
| I think it smells of the common trend in javascript to grab
| any old package and use it if it scratches an itch. look at
| lpad(and that debacle). back when i was doing compiled stuff
| (well even now in scripted land) you'd look hard at whether
| or not you needed that dependency since every dependency is a
| liability. and of course you'd manage the dependencies by
| hand.
|
| kidsthesedaysgetoffmylawn
| baz00 wrote:
| That's most modern software development though. Drag any
| old shit off the internet, dependencies, malware and
| incompetence included, then execute it as some arbitrary
| user with full access to your mission critical data and an
| outbound network connection. Maybe if you're big enough to
| have a security or compliance guy they will at most want
| you to buy in something that does a half assed attempt at
| tracking dependencies after it's too late or intercepts
| traffic pointlessly on the way out crippling your business
| inconveniently sometimes.
|
| I tend to just use whatever Debian ships with package-wise
| when I'm doing something for my own purposes. People laugh
| at me. Their funeral.
| duxup wrote:
| I gotta think it was more than just JS? Some non JS assets and
| etc maybe?
| kragen wrote:
| a fully functioning unix-like kernel is more like 0.03
| megabytes
|
| remember the pdp-11 was a 16-bit machine, and there's also c64
| lunix, etc.
| tiffanyh wrote:
| > *"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).
| alfalfasprout wrote:
| In 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 wrote:
| Its 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.
| zem wrote:
| a 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 wrote:
| Absolutely
| milesvp wrote:
| you 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.
| oplaadpunt wrote:
| While the 168mb is ridiculous, I'm more facinated by the choice
| to depend on an unimplemented feature from a group/company they
| had no control over or contracts with. I would hesitate to depend
| on things which haven't been released for a few months/years. I
| realize the web moves fast and some might prefer working with new
| technology, but this sounds so weird to me.
| [deleted]
| thefaux wrote:
| I once led a project that had an android app years ago. Someone
| on the team brought in guava for a small number of helper
| utilities. This made our apk exceed the method limit which
| required some partitioning (forget the details) that increased
| the time to push the app from like 15 seconds (which was still
| way too long) to a minute (which I found unbearable).
|
| One day I ripped out guava, handwrote the parts we were using and
| got our apk size safely within the method count limit. The
| project still failed horribly though but for other reasons :)
| bigmanwalter wrote:
| All this to get a feature that was already prevalent 15 years ago
| in oldschool PHP applications.
| translucyd wrote:
| I feel sometimes that we are running in circles in front end
| development. We had a good thing: Then we burned, step on it,
| and then recreated it because it was the best way to do things
| in the end of the day. :(
| kjkjadksj wrote:
| I feel like this is the inevitability of more and more
| tooling being released. Eventually there will be so much
| tooling that its hard to even work effectively as the signal
| to noise ratio plummets over time.
| [deleted]
| hinkley wrote:
| You should feel that all the time.
|
| But it's not a circle, it's an arc. If it were a circle,
| running as fast as you can in one direction would bring you
| back around to the former. Instead we hit the end of the
| swing and backpedal until we remember why we were going this
| direction in the first place.
| ericmcer wrote:
| You should really try something like NextJs, all the
| nightmarish parts of FE development are abstracted away. It
| makes me hopeful for a future where all the config files and
| tools are invisible and you just develop applications. All
| the TS, HMR, SSR, etc. is invisible to you and managing it is
| the responsibility of the people developing the frameworks.
| fHr wrote:
| front end is such a shit show these days endless and then
| stuff runs for 1 month stable and instead of adresing real
| issues they come up with another rewrite.
| joshstrange wrote:
| Spoken like someone who doesn't need and/or understand SPA-
| style features. Look I get it, I've been developing with PHP
| for close to 2 decades but let's not pretend that PHP+jQuery
| (or whatever you are using for frontend interaction) is
| anywhere near as powerful as a SPA+SSR. And yes, not every site
| needs to be a SPA but there are some sites where that
| absolutely is the right call and pairing it with SSR can get
| you "the best of both worlds".
| jensensbutton wrote:
| This is a weird comparison. You can use PHP to power an SPA
| with SSR. It's not an either or.
| joshstrange wrote:
| I never said it either/or, in fact I'm using PHP to power
| an SPA right now. I was saying that pretending that PHP
| alone was sufficient (for both customers or dev speed) was
| silly.
| esskay wrote:
| If you're building an SPA for an Ecommerce site you've
| seriously misunderstood the web.
|
| These days you can slap together a very capable PHP based
| Ecom solution using Livewire for those sections that need
| interactivity.
|
| People really need to realise just how detremental to the
| user experience it is to have mountains of JS being needed
| just for an ecommerce site.
| Aloha wrote:
| Who _does_ need an SPA?
| soperj wrote:
| People who sell advertising for a living.
| gortok wrote:
| This is a joke, right?
| soperj wrote:
| No. From what I can tell the whole reason for a SPA is so
| that people don't leave your site. You throw away a lot
| of good things (like urls to content) so that you can
| push more ads at people.
| gortok wrote:
| Ah, I see your argument; SPAs are a preferred way to
| 'suck folks in' to a page and just have them stay there
| since they can't navigate in and out to the specific
| piece of content they want with URLs.
|
| That about sums up everything wrong with our industry.
| Engagement over usefulness.
| em-bee wrote:
| everything i built in the past few years only needed a
| generic CRUD backend, if it needed a backend at all. there
| is no application specific code in the backend, and the
| latest app i am working on is completely static as far as
| the backend is concerned. it could even be served locally
| via file://
|
| all the application and interface logic is in the browser.
| this is only possible thanks to SPA.
| brtkdotse wrote:
| Do you persist any data? Where does business logic
| reside? How do you validate inputs?
| em-bee wrote:
| with a backend, data persistence is simply CRUD. for the
| backendless app, it's all in localstorage, and it can be
| downloaded into a file as backup. all the logic is in the
| browser, just like any desktop application. you should
| not need a server to manage personal data that is stored
| on your computer.
|
| of course it is a tradeoff. if the user wanted to save
| their data outside the browser every few minutes then
| that would not be practical or if there is to much new
| data being generated so it doesn't fit into localstorage.
| i'd either need a server (even if running locally) that
| can save that data without user intervention or i should
| not use the browser as a development platform. in such
| cases a browser based SPA would have been the wrong
| choice. maybe electron, or a traditional desktop
| framework
| marcosdumay wrote:
| Well, not long ago I made an in-browser WYSIWYG mouse-based
| diagram designer. I redefined a huge share of the default
| browser behavior.
|
| It was also the first SPA I made, in a career of decades. I
| also think I do not regularly use anything that benefits
| from being an SPA (I don't regularly use that diagram
| designer either).
| moritzwarhier wrote:
| People/stakeholders who want use the browser as an
| application platform.
|
| Think data analysis tools, Intranet tools, e-commerce, and
| a host of B2B stuff?
|
| I know, it all starts with a filterable list or a shopping
| basket, where page reloads or ajax "sprinkles" (regardless
| of what they're loading, HTML or JSON) are absolutely OK.
|
| Especially the fully old-school approach with the page
| reloads - it can work and scale for simple and predictable
| requirements.
|
| Until it doesn't - the first page with 5 interdependent
| autocomplete inputs takes weeks to develop and fix, the
| modals can't have routes without piles of jQuery hacks, and
| so on and ao forth
| afavour wrote:
| Excuse me while I go to my screaming room to imagine Google
| Maps as an MPA.
| dullcrisp wrote:
| You don't remember MapQuest?
| flimsypremise wrote:
| 15 years ago a frontend build was not a thing. You managed what
| few javascript and CSS dependencies you had via the order of
| the script and style tags in the header. Now a frontend build
| is a baked in requirement of any user-facing application, so
| whatever you end up doing in whatever language, you already
| have that one build to manage. If you choose to build your
| application in anything other than JS/TS, you are effectively
| adding an additional build to the project, with all of the
| associate overhead. If you stick with one language and one
| build, you are eliminating large swaths of unnecessary
| complexity right off the bat. Not to mention that you don't
| have to hire for the additional language for the dev team.
|
| Unless there is a legacy system driving the requirements in a
| different direction, my default application architecture is
| always going to be server-side React at this point.
| breckenedge wrote:
| > Not to mention that you don't have to hire for the
| additional language for the dev team.
|
| Or maybe hire people who can code in more than one framework.
| bakuninsbart wrote:
| User facing in what way? There seem to still be a ton of new
| RoR or Django projects without react/ or angular out there.
| willsmith72 wrote:
| 168mb holy crap!
|
| I'm glad he got to the real issue at the end. Doing a full big
| bang rewrite with no deliverables for 8 months. A classic
| waterfall project.
|
| Maybe the react rewrite was the right call at that moment in
| time, but there were a serious of huge mistakes that led them
| there.
| inetknght wrote:
| > _Doing a full big bang rewrite with no deliverables for 8
| months. A classic waterfall project._
|
| I've seen the same thing for agile projects too.
| willsmith72 wrote:
| I can't really see how that could be classified as agile.
| Using an "agile" methodology maybe
| teg4n_ wrote:
| God. I wish my team did this. So much sunk cost.
| ChrisMarshallNY wrote:
| I tossed about 18 months' worth of work on the frontend for our
| upcoming app, and started over.
|
| It's been about eight months since, and the new app is _really
| good_. It will be a hundred times better than what we had.
|
| Since we didn't do the MVP thing (which pretty much forces a
| "sunk cost"), we could do this.
| Cthulhu_ wrote:
| At my previous job, my assignment was to rebuild a front-end 10
| years in the making; the company had lost (idk if they fired
| him or he moved on, I suspect the latter as he was one of the
| founders) their previous developer, who was both not a very
| good developer and very productive.
|
| But yeah, when I joined that software had been built for over 8
| years, using technology and practices from the 2000s (think
| AJAX where X is XML, a PHP back-end that concatenaded XML tags,
| and a Dojo front-end), and my goal was to rebuild it.
|
| I spent 2.5 years there, using Go as back-end so it's all
| integrated (one issue was that the PHP runtime they had at
| customers couldn't be updated because RHEL didn't have a newer
| version in the repos), React as front-end, etc etc. But there
| was just too much functionality to rebuild, and they didn't /
| couldn't find other people to hire (until I quit, because of
| course).
|
| In hindsight, while PHP wasn't really my thing, I should've
| focused on improving the existing codebase and then only
| incrementally improve and replace things in-place. I mean at
| the same time, I knew a full rebuild of that was a Bad Idea,
| but that's what they wanted and I wanted to do stuff in Go as
| well so I didn't challenge it too hard.
|
| But yeah, I could've easily made the back-end twice as fast
| with at worst a week or two of work; half the back-end's
| processing time and memory usage was because they took that
| concatenated XML, parsed it, and converted it into JSON.
| Because at some point the previous author realized JSON is the
| new cool kid on the block.
| ninepoints wrote:
| So there was a measurable problem (large bundle size) that they
| sought out to fix (in addition to upfront loading time). The
| first thing to do would have been to _not_ engage in SSR, or
| Angular 2, or any other big architectural change without first
| checking if actually properly slimming the bundle would have
| helped first. Next, how do you proceed till almost ship without
| actually solving one of the core initial problems you set out to
| fix? Before porting the universe, it seems like you should at
| least remove that risk or convince yourself you know how to do
| it. I'm going to go on a limb and also completely disagree with
| the conclusion that a React rewrite was the right thing to do. My
| experience is that engineer morale isn't maintained by staying in
| framework and rework hell - instead, morale increases when
| engineers have opportunities to deliver high-value experiences to
| users. Not shipping is a common and understandable reason for
| engineers to leave, and if your employees are hankering to leave
| because the tech they use isn't the current flavor-of-the-month,
| you may need to reassess your cultural values screened during the
| hiring process.
| Raed667 wrote:
| I've seen projects devolve like this when everyone is tasked
| with a part of app logic (the checkout page, the cart, etc..)
| but no-one is responsible or accountable for the sum of the
| parts.
|
| Oh you want to rework on the routing or tooling or anything
| like that impacts other parts of the app? Good luck getting 5
| teams to sit down and agree.
| stavros wrote:
| Other commenters here are focusing on the bundle size or the
| choice of framework, but I'm really surprised by the stack: It's
| an ecommerce app, why do you need a SPA for it? I really think
| people have just forgotten how quick and easy it was to write SSR
| code that has a bit of interactivity on the frontend as-needed,
| and has gone full in on SPA all the things.
|
| I wonder how long it would have taken them to write with plain
| HTML served by simple views.
| caleblloyd wrote:
| Sometimes I think the best thing an eCommerce Company could do
| is move their home-rolled eCommerce app to Shopify /
| BigCommerce / some other eCommerce SaaS. I imagine that 8
| months of getting to know a true eCommerce platform and
| purpose-building plugins would result in a pretty reliable
| eCommerce app. Especially if you never have to worry about if
| your Cart, Check-Out page, or PayPal/Google Pay/Apple Pay
| plugin is going to break on every update.
| simonw wrote:
| I gotta admit, I was reading through this article thinking "and
| so you rewrote it in boring old HTML, right. Right...?"
| stavros wrote:
| Yeah, I did get a bit dismayed at "so we rewrote it and kept
| all the complexity, but used a framework that had the
| critical feature the old one didn't".
| BbzzbB wrote:
| > I don't understand the 'techo side' of the story Dan, but the
| leadership is key, well done mate.
|
| I find this comment by user "Dad" very endearing.
| CobrastanJorji wrote:
| I gotta say, I sympathize with their "goes against every
| instinct" plight. If I had joined a team 2 months ago, and they'd
| been working on something for a year, and I was thinking "we
| should scrap this and start it over from scratch," I'd be really,
| really suspicious of my own thinking. Scrap and start over is
| such a tantalizing programmer thought for something that seems
| complicated and broken, and you'll almost always want to do it,
| and it's almost always the wrong call. Glad it was the right call
| here.
| alfalfasprout wrote:
| You see both sides of the coin often-- people are often too
| quick to go for a rewrite. But then you also often see the
| "rewrites are almost never a good idea" camp that dismisses the
| benefits too quickly.
|
| The reality is rewrites are often appropriate but they need to:
| 1. Have a clear tangible benefit (or ideally many benefits) 2.
| Be as tightly scoped as possible to achieve the above benefits.
| Rewriting everything at once is a horrible idea in all but the
| most egregious cases. 3. Be as incrementalized as possible.
| yxre wrote:
| Expanding on your first criteria. The technology stack is
| fundamentally wrong is a good reason for a re-write. Language
| too slow. Doesn't handle the workload well. Other stacks have
| a better ecosystem.
|
| Re-writes are also needed when the architecture doesn't match
| the problem space well. This can be incrementally done.
| Single threaded loops instead of using parallel-safe
| constructs like tasks and jobs.
| Buttons840 wrote:
| The best systems I've created came from iteratively
| experimenting with the language / API / whatever. Build
| something for the sake of learning, throw it away, build
| another experiment to learn, throw it away, take a shot at
| the real thing, throw it away, etc. It starts to feel like if
| you rewrite and think about the problem enough you'll
| eventually reach a point where you can write or rewrite the
| whole system in a week. Which leads me to conclude:
|
| Systems that can be rewritten, do not need to be rewritten.
| Systems that cannot be rewritten, need to be rewritten.
|
| It's not quite true (not in all circumstances), but it's
| close. I think most enterprise / pile-of-business-rules
| software falls into the latter category, those systems cannot
| be rewritten, but they need to be.
| dabbz wrote:
| Was it though? I mean, the goal was SSR, but if they had a
| fully functioning site sans SSR, why not ship now, then deploy
| SSR whenever it gets baked into Angular?
|
| They were using Angular's dependency block them when I don't
| think they really needed to be blocked to ship a product.
| notnmeyer wrote:
| it was the right call.
|
| > The relaunch of our ecommerce website had one goal: deliver
| blazing fast performance with Server-Side Rendering.
|
| you're suggesting they ship a rewrite that doesn't do the one
| thing they're rewriting for? at the time they also didn't
| know when ssr support would be available.
|
| they switched and shipped ssr support faster than it would
| have been available otherwise.
| brudgers wrote:
| That the project was supposed to ship in three months is an
| important part of the author's specific experience.
|
| That they gave the project another two months is another
| important part of the experience.
|
| So the specific project was clearly a failure. They weren't
| talking about rewriting working code, let alone code that was
| making money.
|
| To me, it looks like it took a lot to violate the never-start-
| over-prime-directive-for-progress in creative work.
| chillax2 wrote:
| Something doesn't really add up with the timelines in this story.
| I launched my own Angular2 site with SSR in the summer of 2017.
|
| There were some rough edges, but it only took me a few days of
| hacking to get it working. Thankfully, the ecosystem is much
| better today
| Cthulhu_ wrote:
| I think the difference might be that you knew what you wanted
| to build. That's usually the bigger issue in projects like
| this.
|
| The other thing I can think of is that small teams or
| individuals can often outpace larger teams, at least when it
| comes to pure software development - in practice, a team
| handles things like 3rd party integrations, customer feedback,
| stakeholder management, demos, etc as well.
| _gabe_ wrote:
| I'm really curious what this article would look like if it was
| written from the perspective of one of the "boots on the ground"
| developers that spent 8 months on the original PoC, rewrote it in
| the 7 weeks, and is still maintaining it today.
| pierat wrote:
| The difference here is this person risked their job directly to
| do this.
|
| You need help if a lot of money to be able to make wagers like
| this. And I see no reason to risk my personal livelihood over bad
| corporate decisions.
|
| I guess that's the difference between what I do and the crazy
| startup world.
| tonyedgecombe wrote:
| I know most managers wouldn't agree but I think having fuck you
| money is good for the employer as well as the employee.
| bandergirl wrote:
| What to do when your 3 years of work is already written in Shitty
| React(tm)?
|
| I've been suggesting codebases cleanups but we only do it when
| the clients complains about severe bugs (which, hear hear, are
| due to our known core issues)
| ibejoeb wrote:
| > The company's first website was an AngularJS single-page
| application. AngularJS didn't support server-side rendering, so
| the website was slow to render on first load, but snappy once
| everything had downloaded.
|
| That sounds like a pretty decent concession. I wonder if it was
| ever even a real problem. I'll bet the real problem is that
| nobody was willing to call it done.
| albert_e wrote:
| He mentions that this is not a good UX in ecommerce space.
|
| I think I agree.
|
| If I have a choice between buying stuff on Amazon.com and
| Walmart.com -- and if one of the two gives me sluggish UX
| everytime I start my user journey. The other competitor site
| would eventually become my default go to and get all my money
| (everything lese being equal).
|
| Brands are built at touchpoints -- according to my marketing
| prof -- and I believe it rings true.
___________________________________________________________________
(page generated 2023-08-18 23:01 UTC)